Connecter un agent IA au protocole MCP

Deux parcours se rejoignent ici. D'un côté, les agents — qui ont besoin d'outils. De l'autre, le MCP — un protocole qui standardise la mise à disposition d'outils. Les brancher ensemble, c'est découpler définitivement un agent de son outillage : l'agent ne sait plus comment un outil est implémenté, il consulte un catalogue décrit par le protocole. Ce guide connecte un agent LangGraph à trois serveurs MCP via un client unique, montre comment les autres frameworks consomment MCP, et explique comment exposer un agent lui-même comme serveur MCP. Public visé : développeur ayant suivi le parcours agents et le parcours MCP, et voulant les réunir.

Ce que vous allez apprendre

Pourquoi connecter un agent au MCP plutôt que coder ses outils en dur.
Brancher un agent LangGraph sur plusieurs serveurs MCP.
Orchestrer trois serveurs MCP depuis un seul agent.
Comment PydanticAI et smolagents consomment MCP.
Exposer un agent lui-même comme serveur MCP.

Prérequis

Ce guide réunit deux parcours : Agents stateful avec LangGraph et Comprendre le MCP. Il vous faut :

Une instance Ollama avec le modèle qwen2.5.
Savoir créer un serveur MCP.
Python 3.10+.

Pourquoi connecter un agent au MCP

Dans les guides précédents, les outils d'un agent étaient des fonctions Python déclarées dans le code de l'agent. Cela marche, mais cela couple l'agent à ses outils : changer un outil, c'est modifier l'agent ; partager un outil entre deux agents, c'est dupliquer du code.

Le MCP — Model Context Protocol — casse ce couplage. Un outil vit dans un serveur MCP, un processus indépendant qui le décrit selon un protocole standard. L'agent, lui, est un client : il interroge le serveur, découvre les outils disponibles, les appelle. Il ne connaît ni le langage du serveur, ni l'implémentation de l'outil — seulement son contrat.

Le gain est net. Un même serveur MCP sert plusieurs agents. Ajouter une capacité à un agent ne touche plus son code : on branche un serveur de plus. L'agent et ses outils évoluent séparément — exactement la séparation que vise une bonne architecture.

Un client pour plusieurs serveurs

Côté agent, la connexion passe par un client MCP. Pour LangChain et LangGraph, c'est langchain-mcp-adapters : il connecte un ou plusieurs serveurs MCP et traduit leurs outils en outils LangChain, directement utilisables par un agent.

Sa classe centrale est MultiServerMCPClient : on lui passe une configuration, un serveur par entrée.

import os, sys
from langchain_mcp_adapters.client import MultiServerMCPClient

ICI = os.path.dirname(os.path.abspath(__file__))

CONFIG_SERVEURS = {
    "calcul": {
        "command": sys.executable,
        "args": [os.path.join(ICI, "serveur_calcul.py")],
        "transport": "stdio",
    },
    "texte": {
        "command": sys.executable,
        "args": [os.path.join(ICI, "serveur_texte.py")],
        "transport": "stdio",
    },
    "dates": {
        "command": sys.executable,
        "args": [os.path.join(ICI, "serveur_dates.py")],
        "transport": "stdio",
    },
}

Chaque entrée décrit comment joindre un serveur. En transport stdio, le client lance le serveur en sous-processus — command et args — et dialogue avec lui par les flux standard : ni port, ni réseau, le plus simple pour des serveurs locaux. Le sys.executable garantit que les serveurs tournent avec le même Python que l'agent, donc avec le paquet mcp disponible. Un serveur distant se déclarerait plutôt avec une url et le transport http.

Construire un agent LangGraph outillé par MCP

Le client connecté, on récupère tous les outils des serveurs en un appel — get_tools() — puis on les passe à l'agent.

from langchain_ollama import ChatOllama
from langgraph.prebuilt import create_react_agent

MODELE = ChatOllama(model="qwen2.5", base_url="http://localhost:11434",
                    temperature=0)

async def construire_agent():
    """Connecte les serveurs MCP, charge leurs outils, crée l'agent."""
    client = MultiServerMCPClient(CONFIG_SERVEURS)
    outils = await client.get_tools()
    return create_react_agent(MODELE, outils)

Deux points méritent attention. get_tools() est asynchrone : connecter des serveurs implique des entrées-sorties, le code de l'agent est donc async. Et create_react_agent est la boucle ReAct prête à l'emploi de LangGraph : on lui donne un modèle et une liste d'outils, il fournit l'agent — la boucle raisonner / agir / observer du tout premier guide, ici sans l'écrire à la main.

Point clé : create_react_agent ne fait aucune différence entre un outil MCP et un outil Python local. get_tools() a traduit les outils MCP en outils LangChain ordinaires. Pour l'agent, un outil est un outil — leur provenance par le protocole est invisible.

Orchestrer trois serveurs

L'agent en place, on l'interroge. La question du lab mobilise deux serveurs distincts :

async def demander(question: str) -> str:
    agent = await construire_agent()
    resultat = await agent.ainvoke(
        {"messages": [{"role": "user", "content": question}]}
    )
    return resultat["messages"][-1].content

Q : Combien font 7 multiplié par 8 ? Et combien de mots contient
    la phrase « le chat dort sur le tapis » ?
R : Le résultat de 7 multiplié par 8 est 56.
    La phrase "le chat dort sur le tapis" contient 6 mots.

L'agent a fait son travail d'orchestration : il a reconnu qu'une partie de la question relevait du serveur calcul, l'autre du serveur texte, et a appelé le bon outil sur le bon serveur. Le serveur dates, lui, n'a pas été sollicité — il était disponible, sans être utile à cette question. C'est l'agent qui choisit, à partir de la description de chaque outil.

La suite de tests du lab vérifie cela à deux niveaux : les outils de chaque serveur, testés directement et sans modèle — une fonction multiplier reste une fonction Python —, et l'orchestration complète, où l'agent connecte les serveurs et résout une question outillée.

MCP dans les autres frameworks

LangGraph n'est pas seul à parler MCP — le protocole s'est imposé, et les principaux frameworks d'agents le consomment.

PydanticAI intègre le MCP nativement : on déclare des serveurs MCP à la création de l'Agent, et leurs outils rejoignent ceux de l'agent. Le principe est identique — un client, une configuration de serveurs, des outils découverts.

smolagents propose une ToolCollection capable de charger les outils d'un serveur MCP, qu'on passe ensuite à un CodeAgent ou à un ToolCallingAgent.

Le schéma est partout le même : un client MCP, une liste de serveurs, des outils découverts à l'exécution. C'est précisément la promesse d'un standard — l'outil ne dépend pas du framework qui le consomme.

Exposer un agent comme serveur MCP

Jusqu'ici, l'agent est client de serveurs MCP. Mais on peut renverser le rôle : exposer un agent lui-même comme serveur MCP.

L'idée est puissante. Un agent capable, par exemple, de synthétiser des notes de version peut être empaqueté en serveur MCP : il expose un outil synthetiser_releases, et un autre agent peut l'appeler — sans rien savoir de sa mécanique interne. L'agent appelant voit un outil ; derrière cet outil se cache un agent complet.

C'est le principe des architectures agent-à-agent : des agents qui se composent, chacun exposant ses capacités par le même protocole que de simples outils. Le MCP devient alors la langue commune non seulement entre un agent et ses outils, mais entre agents eux-mêmes. Concrètement, on enveloppe l'appel à l'agent dans une fonction décorée par @mcp.tool(), exactement comme n'importe quel serveur MCP — la logique interne étant un run d'agent au lieu d'un calcul.

Dépannage

Symptôme	Cause probable	Solution
Le serveur MCP ne démarre pas	`command` ne trouve pas Python ou `mcp`	Utiliser `sys.executable` pour le sous-processus
`get_tools()` ne renvoie rien	Mauvais chemin de serveur dans `args`	Donner un chemin absolu vers le fichier serveur
L'agent ignore un outil	Description d'outil trop vague	Soigner la docstring de l'outil côté serveur
`RuntimeError` sur la boucle asyncio	`get_tools()` appelé hors d'un contexte async	Encapsuler l'agent dans une fonction `async`
L'agent appelle le mauvais serveur	Outils homonymes entre serveurs	Nommer les outils distinctement

À retenir

Connecter un agent au MCP découple l'agent de ses outils : ils évoluent séparément.
MultiServerMCPClient connecte plusieurs serveurs ; get_tools() agrège leurs outils.
Pour l'agent, un outil MCP est un outil ordinaire — sa provenance par le protocole est invisible.
L'agent orchestre : il choisit le bon outil du bon serveur d'après sa description.
PydanticAI et smolagents consomment MCP selon le même schéma — c'est la force d'un standard.
Un agent peut lui-même être exposé comme serveur MCP — la base des architectures agent-à-agent.

Prochaines étapes

Comprendre le MCP Le protocole, ses concepts et sa raison d'être.

Créer un serveur MCP Écrire les serveurs que l'agent vient consommer.

Agents stateful avec LangGraph Le framework de l'agent connecté ici aux serveurs MCP.

Le parcours agents IA Le parcours complet, dont ce guide est l'aboutissement.

Pour aller plus loin

langchain-mcp-adapters — le client MCP pour LangChain et LangGraph.
Spécification du Model Context Protocol — la référence du protocole.