Comprendre les agents d’IA : l’appel d’outils, MCP et la boucle d’agent.
Comment l’appel d’outils, MCP et le cycle de l’agent s’intègrent dans l’architecture réelle des agents d’IA, en partant du LLM enrichi et en omettant les termes à la mode.
Sources: Tool Calling vs MCP: How AI Agents Actually Use Tools
Lorsque les gens commencent à explorer les agents d’IA, quelques termes récurrents apparaissent partout :
Agents. Outils. Appels de fonction. MCP. Contexte. Mémoire.
À première vue, il s’agit d’un ensemble de technologies sans lien entre elles.
Cependant, en prenant le temps d’analyser comment sont construits les véritables systèmes agents, en particulier en examinant les documents techniques d’Anthropic sur les agents et le MCP, une architecture beaucoup plus simple se révèle.
Cet article décrit cette architecture sous un angle pratique, destiné aux développeurs.
Qu’est-ce qui fait réellement d’un système d’IA un agent ?
User
↓
LLM
↓
Response
Ici, le modèle ne fait que recevoir des entrées et produire des sorties.
Mais de nombreuses tâches réelles ne peuvent pas être résolues uniquement par la génération de texte.
Prenons cette demande comme exemple :
« Consultez ce dépôt GitHub pour identifier les problèmes en cours, explorez celui qui est le plus important, et faites un résumé de ce qui doit encore être corrigé. »
Pour gérer une telle situation, le système doit :
- Comprendre la demande.
- Décider des informations nécessaires.
- Sélectionner un outil approprié.
- Exécuter l’outil.
- Examiner le résultat.
- Décider de la prochaine étape à suivre.
- Possiblement appeler un autre outil.
- Produire la réponse finale.
C’est précisément ici que le concept de système agent devient utile.
Anthropic établit une distinction claire entre les flux de travail et les agents.
LLM → Step 1 → Step 2 → Step 3 → Answer
Un agent, quant à lui, détermine par lui-même quels actions et outils utiliser :
┌──────────────┐
│ LLM │
└──────┬───────┘
│
choose action
↓
Tool
↓
Result
│
└──────────→ LLM
│
choose next action
Le détail crucial n’est pas seulement le fait qu’un LLM soit impliqué à un moment donné du processus.
C’est plutôt que l’LLM lui-même a une influence sur la façon dont le processus est structuré.
Anthropic présente les agents comme des systèmes dans lesquels l’LLM dirige activement son propre flux de travail et l’utilisation des outils, tandis que les flux de travail reposent sur une logique d’orchestration définie à l’avance par le développeur.
L’LLM augmenté
Une idée particulièrement utile tirée des documents d’Anthropic est le concept de LLM augmenté.
Au lieu d’envisager un LLM simplement comme :
LLM → Text
on peut l’envisager comme :
┌─────────────┐
│ LLM │
└──────┬──────┘
│
┌────────────┼────────────┐
↓ ↓ ↓
Retrieval Tools Memory
Dans cette perspective, l’LLM acquiert la capacité de dépasser ses propres paramètres d’entraînement pour interagir avec des informations et des capacités externes.
Anthropic décrit la récupération d’informations, l’accès aux outils et la mémoire comme des formes d’amélioration qui transforment un simple LLM en élément de base pour construire des systèmes agents plus performants.
Cela est important car cela précise que le modèle lui-même ne se transforme pas magiquement en un système logiciel complet.
C’est l’application qui entoure le modèle qui fournit ces capacités supplémentaires.
Qu’est-ce que l’appel d’outil ?
Imaginez donner à un LLM accès à un outil tel que :
get_weather(city)
Un utilisateur demande alors :
"Quel temps fait-il à Colombo ?"
Au lieu de répondre immédiatement, le modèle peut répondre en demandant d’appeler la fonction :
{
"name": "get_weather",
"arguments": {
"city": "Colombo"
}
}
C’est l’application environnante qui exécute réellement cette fonction.
Cette exécution pourrait retourner quelque chose comme :
{
"temperature": 29,
"condition": "Partly cloudy"
}
Ce résultat est renvoyé dans la fenêtre de contexte du modèle.
De là, le modèle peut générer une réponse telle que :
« Il fait actuellement 29°C et il y a du nuage partiel à Colombo. »
Le détail crucial ici est :
Le LLM ne décide que s’il faut appeler un outil. C’est l’application qui le met réellement en œuvre.
Le modèle n’établit jamais de connexion directe avec le service météorologique lui-même.
L’appel d’outils n’est pas MCP
C’est sans doute la distinction la plus importante à comprendre dans tout ce domaine.
L’appel d’outils et MCP traitent deux problèmes différents.
L’appel d’outils concerne fondamentalement l’échange entre :
LLM
↓
Tool request
↓
Application
↓
Tool result
MCP, en revanche, est un protocole conçu pour standardiser la manière dont les applications d’IA se connectent à des outils externes, à des sources de données et au contexte.
Anthropic a publié MCP en novembre 2024 en tant que norme ouverte visant à relier les assistants d’IA aux systèmes où se trouvent réellement les données et les outils.
D’après la documentation d’Anthropic elle-même, MCP standardise la façon dont les applications fournissent du contexte aux LLM, et l’analogie qu’ils utilisent est celle d’un port USB-C pour les applications d’IA.
En résumé :
Tool Calling
↓
How an LLM requests an action
MCP
↓
How AI applications can standardize connections
to external tools and data
En d’autres termes, ces deux concepts se complètent plutôt que de concurrencer.
Qu’ajoute réellement MCP
Imaginez une application d’IA qui doit accéder à :
- GitHub
- PostgreSQL
- Google Drive
- Slack
- le système de fichiers local
- les API internes de l’entreprise
Sans un protocole commun, chacune de ces connexions pourrait nécessiter son propre câblage personnalisé. Vous pourriez facilement aboutir à une configuration comme celle-ci :
AI Application
├── Custom GitHub integration
├── Custom Slack integration
├── Custom PostgreSQL integration
├── Custom filesystem integration
└── Custom internal API integration
MCP intervient en définissant un protocole standardisé qui se situe entre l’application d’intelligence artificielle et tous les systèmes externes qui fournissent des fonctionnalités. Conceptuellement, cela ressemble à ceci :
AI Application
│
MCP Client(s)
│
┌───────────────┼────────────────┐
↓ ↓ ↓
MCP Server MCP Server MCP Server
GitHub Database Files
│ │ │
↓ ↓ ↓
GitHub API PostgreSQL Filesystem
Avec cette organisation, l’application d’intelligence artificielle n’a plus besoin de connaissances approfondies et individuelles de chaque système backend. Au lieu de cela, les serveurs MCP exposent leurs fonctionnalités via une couche de protocole commune.
L’architecture MCP
MCP est basé sur un modèle client-hôte-serveur. Au niveau global, cela ressemble à ceci :
┌─────────────────────────────────────┐
│ HOST │
│ │
│ AI Application │
│ │
│ ┌──────────────────────────┐ │
│ │ MCP Client │ │
│ └────────────┬─────────────┘ │
└─────────────────┼───────────────────┘
│
│ MCP
↓
┌──────────────────┐
│ MCP Server │
│ │
│ Tools │
│ Resources │
│ Prompts │
└────────┬─────────┘
│
↓
External System
Les rôles principaux dans cette architecture sont décrits ci-dessous.
Hôte
L’hôte est l’application d’intelligence artificielle chargée d’orchestrer toute l’interaction. Il peut s’agir de quelque chose comme :
- un assistant de codage basé sur l’IA
- une application d’IA pour ordinateur de bureau
- un outil destiné aux développeurs
- une application d’agent conçue sur mesure
Client MCP
Le client MCP se trouve à l’intérieur de l’hôte et est responsable de maintenir la connexion avec un serveur MCP active et fonctionnelle.
Serveur MCP
Un serveur MCP n’est rien de plus qu’un programme qui expose des fonctionnalités via le protocole MCP. Il peut mettre à disposition des capacités liées à des éléments tels que :
GitHub
Databases
Files
Cloud services
Internal systems
Development environments
Il est important de noter que le serveur MCP lui-même n’a pas besoin d’être un agent ni de contenir de raisonnement par intelligence artificielle. Sa fonction consiste simplement à rendre certaines capacités accessibles.
MCP offre plus que des outils
Un point qui peut facilement induire en erreur est de penser que MCP n’est rien de plus qu’un « protocole d’appel d’outils ». En réalité, MCP définit plusieurs primitives distinctes en dehors des outils.
Outils
Il s’agit d’actions que un modèle est capable d’invoquer, telles que :
create_issue()
search_repository()
query_database()
send_message()
Ressources
Les ressources sont des éléments d’information que une application peut récupérer et transmettre au modèle en tant que contexte, par exemple :
file://project/README.md
database://schema
Prompts
MCP peut également exposer des modèles de prompts réutilisables en tant que primitive distincte.
La documentation MCP d’Anthropic établit une distinction claire quant à qui contrôle chacun de ces éléments : les outils sont contrôlés par le modèle, les ressources par l’application, et les prompts par l’utilisateur. Cet encadrement hiérarchisé de contrôle est ce qui fait de MCP bien plus qu’un simple mécanisme d’appel de fonctions sophistiqué.
Un exemple complet
Prenons une demande telle que :
« Montrez-moi les problèmes non résolus dans ce dépôt GitHub. »
User
│
│ "Show me the open issues"
↓
AI Application
│
↓
LLM
│
│ decides a GitHub tool is needed
↓
Tool Call
│
↓
MCP Client
│
│ MCP
↓
GitHub MCP Server
│
↓
GitHub API
│
↓
Issue Data
│
↓
MCP Client
│
↓
LLM
│
↓
Final Answer
Remarquez le nombre de couches distinctes impliquées ici. Le modèle détermine quelles informations il a besoin. L’application gère l’orchestration et l’exécution. MCP fournit le canal standardisé pour communiquer avec la capacité externe. Le service externe lui-même effectue le travail réel. Il s’agit de quatre responsabilités séparées, et non d’une seule étape combinée.
Où prend place Docker ?
On voit souvent des serveurs MCP emballés et distribués sous forme de conteneurs Docker, par exemple :
AI Application
│
│ stdio
↓
Docker Container
│
↓
MCP Server
│
↓
External Service
Il convient de préciser que Docker lui-même n’est pas MCP. Docker n’est qu’un moyen pratique pour emballer et exécuter un serveur MCP. Ce même serveur peut tout aussi facilement fonctionner en tant que processus local ordinaire ou être hébergé à distance en tant que service. Le protocole lui-même est entièrement indépendant de la manière dont vous choisissez de le déployer.
STDIO vs Streamable HTTP
MCP fonctionne via plus d’un mécanisme de transport.
Lorsque l’intégration est locale, un client MCP peut démarrer un serveur MCP en tant que processus indépendant et communiquer avec lui via STDIO.
Conceptuellement :
AI Application
│
│ stdin/stdout
↓
MCP Server Process
Dans les scénarios où le serveur est hébergé à distance, MCP s’appuie plutôt sur Streamable HTTP.
AI Application
│
│ HTTP
↓
Remote MCP Server
Cela permet à MCP de fonctionner correctement que les outils soient installés sur l’ordinateur d’un développeur ou qu’ils tournent en tant que service hébergé ailleurs.
MCP vs REST API
Une autre distinction importante concerne la manière dont MCP se compare à une API REST classique.
Une interaction avec une API REST se présente comme ceci :
Application
│
│ HTTP request
↓
REST API
│
↓
Data
Une interaction avec MCP se présente comme ceci :
AI Application
│
│ MCP
↓
MCP Server
│
↓
REST API / Database / Filesystem / Other system
Il est intéressant de noter qu’un serveur MCP peut appeler des API REST en arrière-plan.
Ainsi, MCP n’a pas pour but de remplacer REST.
Mieux vaut le comprendre comme une couche adaptée aux IA qui s’insère au-dessus des systèmes existants.
Pourquoi MCP est devenu intéressant
L’ampleur du problème d’intégration devient évidente lorsque l’on imagine plusieurs applications IA ayant chacune besoin de communiquer avec plusieurs outils externes.
Sans protocole commun, on se retrouve avec quelque chose comme ceci :
AI App A ───── Custom ───── GitHub
AI App A ───── Custom ───── Slack
AI App A ───── Custom ───── Database
AI App B ───── Custom ───── GitHub
AI App B ───── Custom ───── Slack
AI App B ───── Custom ───── Database
Chaque nouvelle combinaison d’application et d’outil peut nécessiter l’écriture de code d’intégration nouveau.
Un protocole commun transforme complètement cette situation :
MCP
│
┌────────────┼────────────┐
↓ ↓ ↓
GitHub Slack Database
MCP MCP MCP
Server Server Server
C’est essentiellement pour cette raison qu’Anthropic a publié MCP en tant que standard ouvert plutôt que de le considérer comme un outil conçu uniquement pour Claude.
Depuis, Anthropic a élargi MCP pour qu’il prenne en charge des serveurs distants et a intégré directement une connectivité MCP dans ses API et produits.
Mais disposer de plus d’outils ne rend pas automatiquement un agent meilleur
C’est là que les travaux ultérieurs d’ingénierie d’Anthropic deviennent vraiment intéressants.
Il est facile de penser :
Plus d’outils = agent plus performant.
Cette supposition ne tient pas la route en pratique.
Les recherches d’Anthropic sur la conception des outils montrent que les agents peuvent en réalité performer moins bien lorsqu’ils disposent de trop d’outils qui se chevauchent ou n’ont pas été soigneusement conçus.
Un outil bien conçu doit avoir un but unique et clair, fournir des informations utiles tout en évitant un encombrement inutile dans la fenêtre de contexte du modèle.
Par exemple, au lieu d’exposer trois appels séparés comme ceci :
list_users()
list_transactions()
list_notes()
il peut être plus efficace de donner à l’agent une capacité combinée telle que :
get_customer_context()
en supposant que cela correspond mieux à ce que l’agent tente réellement d’accomplir.
En d’autres termes, l’interface de l’outil devient elle-même partie de l’environnement dans lequel l’agent opère.
Les outils sont une interface pour l’agent
Cette observation souligne une idée plus large qui mérite d’être mise en évidence :
Les outils doivent être conçus en tenant compte de l’agent, et non simplement reconditionnés à partir d’une API existante.
Une API conventionnelle peut fonctionner parfaitement bien lorsque c’est un programme déterministe qui l’appelle.
Cependant, un agent piloté par un LLM fonctionne sous un ensemble de contraintes différent.
Il doit faire face à :
- une fenêtre de contexte limitée
- des sorties probabilistes
- des erreurs occasionnelles dans le choix du bon outil
- des erreurs occasionnelles lors de la génération des paramètres corrects
- de l’ambiguïté quant à ce qui est réellement demandé
Pour cette raison, la manière dont un outil est décrit est vraiment importante.
Considérez à quel point ceci est vague :
search(id)
par rapport à la clarté de ceci :
search_github_issues(
repository,
query,
state
)
Afin que le modèle utilise bien un outil, il doit savoir :
- ce que fait réellement l’outil
- quand c’est le bon outil à utiliser
- ce que représente chaque paramètre d’entrée
- quelle forme prend la sortie
- ce que l’outil ne peut pas faire
Les directives d’Anthropic concernant l’ingénierie des outils insistent sur une nomenclature précise, des descriptions claires, des paramètres bien spécifiés, des résultats utiles et une évaluation continue.
Le contexte devient un élément essentiel de l’ingénierie des agents
Anthropic a également mis en avant récemment l’idée de contexte juste à temps.
La manière naïve de gérer le contexte se présente comme suit :
Load everything
↓
Put everything into context
↓
Ask the LLM to reason
Cette approche rencontre rapidement des problèmes de scalabilité.
Un modèle plus durable se présente comme ceci :
Small amount of initial context
↓
Agent identifies what it needs
↓
Tool retrieves relevant information
↓
Relevant information enters context
↓
Agent continues
Au lieu de charger à l’avance tout ce dont le modèle pourrait avoir besoin, l’agent ne récupère des informations que lorsqu’il détermine qu’elles sont réellement nécessaires.
Anthropic présente cela comme un pas vers une gestion du contexte « juste à temps » pour les systèmes d’agents.
Cela rejoint directement le concept de MCP.
MCP fournit le chemin standardisé vers des capacités externes, tandis que l’agent lui-même décide quand récupérer quelque chose et exactement quoi récupérer.
Le cycle de l’agent
Lorsque vous assemblez tous ces éléments, l’architecture globale devient beaucoup plus compréhensible.
Une version simplifiée du cycle de l’agent ressemble à ceci :
┌──────────────┐
│ User │
└──────┬───────┘
↓
┌──────────────┐
│ LLM │
└──────┬───────┘
↓
Need a tool?
/ \
No Yes
↓ ↓
Answer Tool Call
↓
Tool/MCP
↓
Tool Result
│
└─────────┐
↓
LLM
│
┌──────────┴──────────┐
↓ ↓
Continue Answer
Ce cycle se trouve au centre d’une grande partie des systèmes agents en usage aujourd’hui.
Anthropic l’explique en termes extrêmement simples : un agent est essentiellement un LLM qui appelle des outils à l’intérieur d’un cycle, où les retours de l’environnement déterminent ce qu’il fera ensuite.
Le système qui entoure ce cycle peut devenir très complexe, mais le mécanisme de base reste simple.
Et les frameworks ?
Des frameworks comme LangGraph peuvent rendre la création de ces systèmes plus gérable en vous fournissant une structure dans laquelle travailler.
Néanmoins, il existe une précaution importante à garder à l’esprit.
Les conseils d’Anthropic consistent à comprendre ce qui se passe en dessous du framework : les appels directs aux LLM, les définitions des outils, la logique d’orchestration et les réponses générées, plutôt que de traiter le framework comme une boîte noire.
Un framework expose généralement des éléments tels que :
Agent
├── State
├── Nodes
├── Tools
├── Routing
└── Execution
Mais en dehors de cette abstraction, la mécanique réelle reste la suivante :
LLM
↓
Messages
↓
Tool calls
↓
Tool execution
↓
Tool results
↓
LLM
Comprendre ce flux de bas niveau rend le framework lui-même beaucoup plus facile à analyser, car on peut voir ce qu’il automatise au lieu de se contenter de croire qu’il fonctionne.
MCP ne remplace pas les frameworks d’agents
Il est important de préciser que ce sont des couches différentes au sein d’un système, et non des alternatives concurrentes.
Une pile simplifiée pourrait ressembler à ceci :
┌─────────────────────────────┐
│ User Interface │
├─────────────────────────────┤
│ Agent / Workflow │
├─────────────────────────────┤
│ LLM / Model API │
├─────────────────────────────┤
│ Tool Calling │
├─────────────────────────────┤
│ MCP │
├─────────────────────────────┤
│ External Tools / Systems │
└─────────────────────────────┘
Un cadre d’agent gère généralement des éléments tels que :
- l’état
- le flux d’exécution
- le routage
- les boucles
- les tentatives de répétition
- l’exécution d’outils
D’un autre côté, MCP standardise la manière dont on se connecte à des capacités externes.
L’appel d’outils fournit au modèle un mécanisme pour demander l’exécution d’une action.
Aucun de ces trois éléments ne peut remplacer les autres.
Quelques idées reçues courantes
« MCP est un modèle d’IA. »
C’est faux.
MCP n’est qu’un protocole, rien de plus.
Il n’a pas la capacité de générer du texte ou de raisonner par lui-même.
« MCP remplace les appels de fonctions. »
Cela aussi est faux.
En réalité, un serveur MCP peut exposer des outils, et une application d’IA présente ensuite ces outils au modèle via son mécanisme existant d’utilisation des outils.
"Le LLM appelle directement GitHub."
Généralement, non.
Le modèle ne produit qu’une demande d’utilisation d’un outil.
C’est l’application ainsi que l’infrastructure d’outils associée qui effectuent réellement l’opération.
">Tout serveur MCP a besoin de Docker."
Faux.
Docker n’est qu’un des moyens possibles de déployer un serveur.
MCP concerne la communication et l’exposition des capacités, et non la manière dont quelque chose est conteneurisé.
" Un serveur MCP est un agent d’IA."
Pas nécessairement.
Un serveur MCP peut simplement exposer des opérations simples et déterministes telles que :
search()
read()
create()
update()
delete()
"MCP n’est utile que pour GitHub."
Très loin de là.
MCP a été conçu comme un protocole polyvalent permettant de relier les applications d’IA à des données et des capacités externes. L’annonce initiale d’Anthropic indiquait déjà des intégrations avec des systèmes tels que GitHub, Slack, Google Drive, des bases de données et divers environnements de développement.
La leçon principale : l’ingénierie des agents n’est pas seulement de l’ingénierie de prompts
C’est sans doute le changement de perspective le plus important qui ressort de l’étude de ce matériel.
Créer des systèmes agents véritablement utiles ne relève pas simplement de :
Write a clever prompt
↓
Use a powerful model
↓
Get a smart agent
Plusieurs couches d’ingénierie distinctes sont impliquées :
Model
↓
Tool Selection
↓
Tool Definitions
↓
Tool Execution
↓
Context Management
↓
State / Memory
↓
Control / Guardrails
↓
Evaluation
Les écrits d’ingénierie d’Anthropic eux-mêmes privilégient de plus en plus cette vision plus large, au niveau du système, de ce qu’il faut réellement pour construire un agent.
À titre d’exemple, leurs travaux récents sur l’évaluation des agents se concentrent sur l’analyse du comportement à plusieurs étapes, de l’utilisation d’outils, des changements d’état et de l’adaptation au fil du temps, plutôt que sur le jugement de la qualité uniquement à partir du texte final généré.
Cela représente une approche nettement différente de la conception des applications d’IA.
La partie que je trouve la plus intéressante
La transition importante ici n’est pas vraiment :
Chatbot → Agent
C’est plus précisément :
LLM
↓
LLM + Tools
↓
LLM + Tools + External Context
↓
LLM + Tools + Context + Control Loop
↓
Agentic System
MCP s’insère dans cette progression en fournissant aux applications d’IA un moyen standardisé d’accéder à des capacités externes.
Le modèle fournit l’intelligence.
L’application fournit le contrôle.
Les outils fournissent les actions.
Les systèmes externes fournissent des informations et des capacités du monde réel.
MCP fournit la couche de connexion standardisée qui relie les applications d’IA à ces capacités.
Mon modèle mental actuel
Après avoir étudié les appels d’outils, MCP ainsi que les écrits plus larges d’Anthropic sur les systèmes agents, voici le schéma architectural le plus simple qui montre comment ces éléments s’assemblent :
USER
│
↓
┌─────────────┐
│ LLM │
│ │
│ Reasoning │
│ Decision │
└──────┬──────┘
│
Tool request
│
↓
┌─────────────────┐
│ Agent Runtime │
│ │
│ State │
│ Control Flow │
│ Tool Execution │
└────────┬────────┘
│
↓
MCP / Tools
│
┌────────────┼────────────┐
↓ ↓ ↓
GitHub Database Files
│ │ │
└────────────┼────────────┘
↓
Tool Results
│
↓
LLM
│
↓
USER
Le modèle, pris isolément, n’est pas l’agent dans son intégralité.
Aucun outil seul ne constitue non plus l’agent.
MCP non plus n’en fait pas partie.
Ce que l’on obtient réellement en tant qu’« agent » provient du système entourant le modèle, c’est-à-dire de la partie qui lui permet de raisonner, d’agir, d’observer ce qui se passe et de continuer à travailler vers un objectif.
Conclusion finale
Si vous souhaitez développer des agents IA, quatre concepts méritent d’être maîtrisés en profondeur :
1. Appels d’outils
Le modèle peut demander à l’application d’exécuter un outil spécifique.
2. Boucles d’agent
Le système peut raisonner à plusieurs reprises sur une situation, agir en conséquence, observer le résultat et poursuivre à partir de là.
3. MCP
Un protocole standardisé permettant de connecter les applications d’IA à des outils, des ressources et un contexte externes.
4. Ingénierie des outils
La qualité de vos outils, leurs descriptions, leurs paramètres, le contexte qu’ils restituent ainsi que la manière dont ils sont évalués peuvent influencer de façon significative les performances réelles d’un agent.
Peut-être la leçon la plus importante à retenir de la pratique d’ingénierie d’Anthropic est la suivante :
Ne rajoutez pas de complexité simplement parce que vous en avez la capacité.
Commencez par l’architecture la plus simple capable de résoudre le problème qui se pose. N’intégrez des workflows, d’autres agents, davantage d’outils, de la mémoire, des serveurs MCP ou d’autres composants que lorsque cela apporte un avantage concret.
L’objectif n’a jamais été de créer l’agent le plus sophistiqué possible.
L’objectif est de construire un système capable d’accomplir la tâche de manière fiable.