Outils, permissions et MCP : comment un agent de codage devient réel
Un modèle ne devient pas agent parce qu'il écrit mieux du code. Il devient agent lorsqu'il obtient une manière contrôlée d'agir sur son environnement.
Trois éléments doivent se rejoindre : une surface d'outils, un système de permissions et une couche d'intégration pour les capacités externes. Claw Code est utile parce que ces trois éléments apparaissent clairement dans son dépôt de parity.
Carte de la série
- Ce que Claw Code révèle sur l'architecture des agents de codage IA
- Pourquoi les agents de codage IA utilisent Rust et Python ensemble
- Outils, permissions et MCP : comment un agent de codage devient réel
- Hooks, plugins et sessions dans les agents de codage IA
- Clean-room rewrites et audits de parity pour les équipes d'agents IA
Un outil est une promesse
Dans un agent, un outil n'est pas un simple appel de fonction. C'est une promesse : l'agent peut faire quelque chose de concret et répétable. Lire des fichiers, les modifier, chercher, lancer un shell, récupérer le web, déléguer à un sous-agent ou inspecter une configuration.
Dès que le modèle possède ces capacités, l'utilisateur ne demande plus seulement des idées. Il attend des résultats. La couche d'outils définit donc la surface d'action réelle.
Les outils grossiers se cassent vite
Un seul outil shell pour tout faire paraît simple au début. Puis les permissions deviennent illisibles, les traces d'audit se brouillent, les erreurs sont difficiles à classer et les utilisateurs perdent confiance.
Le meilleur modèle est compositionnel : séparer lecture et écriture, actions locales et réseau, outils intégrés et extensions, actions risquées et actions simples.
Les permissions sont une expérience produit
Un agent qui lit les fichiers est utile. Un agent qui écrit est plus puissant. Un agent qui exécute le shell est encore plus utile et plus risqué.
Le système doit rendre visible ce qui sera lu, modifié, exécuté ou envoyé au réseau. Les permissions ne sont donc pas un verrou ajouté à la fin. Elles sont au centre de la supervision.
MCP comme bus de capacités
MCP donne une surface plus standard pour connecter documentation, issues, bases de données, monitoring, déploiement et outils internes. Sans cette surface, chaque intégration devient du code de colle spécifique.
Avec MCP, les capacités externes peuvent être gouvernées avec des frontières plus claires.
Conclusion
Outils, permissions et MCP doivent être conçus ensemble. Les outils disent ce que l'agent peut faire. Les permissions disent dans quelles conditions. MCP dit comment étendre cet ensemble.
C'est cette combinaison qui transforme un modèle capable de coder en système auquel on peut confier un vrai travail d'ingénierie.