Le Model Context Protocol (MCP) : connecter ses agents IA à des outils et services

Les agents IA comme Claude ne sont vraiment utiles que lorsqu’ils peuvent agir sur leur environnement : lire des fichiers, interroger des APIs, exécuter des commandes, consulter des bases de données. Le Model Context Protocol (MCP), standardisé par Anthropic en 2024 et aujourd’hui largement adopté, définit un protocole ouvert pour connecter un LLM à n’importe quel service externe. Cet article présente son fonctionnement, ses cas d’usage concrets, et comment l’intégrer dans une infrastructure open source.

Pourquoi un protocole dédié aux outils des agents IA ?

Avant MCP, chaque intégration entre un LLM et un outil externe était une solution sur-mesure : une fonction ad hoc, un wrapper spécifique, une API propriétaire. Le résultat : des silos, des doublons, des incompatibilités entre modèles et environnements. Dès qu’on voulait réutiliser un outil (par exemple, une recherche dans CKAN) dans un autre contexte d’agent, il fallait tout réécrire.

MCP résout ce problème en définissant un contrat standard : un serveur MCP expose des outils (tools), des ressources (resources) et des invites (prompts) via une interface JSON-RPC normalisée. Le client MCP — l’agent IA ou l’application hôte — peut alors découvrir dynamiquement ce que le serveur sait faire et l’invoquer de manière structurée. Un serveur MCP écrit une fois peut être consommé par Claude Desktop, Claude Code, ou n’importe quelle application compatible.

Architecture : hôte, client, serveur

MCP distingue trois rôles :

L’hôte : l’application qui embarque le LLM et orchestre la session (Claude Desktop, une application Python, un système d’agents custom).
Le client MCP : le composant dans l’hôte qui gère les connexions aux serveurs MCP et fait le lien avec le modèle de langage.
Le serveur MCP : le processus qui expose les capacités (outils, ressources, prompts) vers l’hôte. Il peut s’exécuter localement (via stdio) ou à distance (via SSE ou WebSocket).

Le serveur MCP expose ses capacités via trois primitives. Les tools sont des fonctions que le LLM peut appeler pour effectuer une action (requête SQL, appel API, écriture de fichier). Les resources sont des données que le serveur peut mettre à disposition du modèle sous forme de contexte (contenu d’un fichier, résultat d’une requête, page web). Les prompts sont des modèles d’invite préconfigurés que l’utilisateur peut activer.

Écrire un serveur MCP : exemple avec FastMCP en Python

Le SDK Python officiel (et sa surcouche FastMCP) permet d’écrire un serveur MCP en quelques dizaines de lignes. L’exemple suivant expose un outil permettant à un agent IA d’interroger l’API CKAN d’un portail open data :

from mcp.server.fastmcp import FastMCP
import httpx

mcp = FastMCP("ckan-portail")

@mcp.tool()
async def rechercher_datasets(query: str, portail_url: str = "https://data.monportail.fr") -> str:
    """Recherche des jeux de données dans un portail CKAN."""
    url = f"{portail_url}/api/3/action/package_search"
    async with httpx.AsyncClient() as client:
        r = await client.get(url, params={"q": query, "rows": 5})
        resultats = r.json()["result"]["results"]
    return "\n".join(f"- {d['title']} ({d['name']})" for d in resultats)

if __name__ == "__main__":
    mcp.run(transport="stdio")

En ajoutant ce serveur dans la configuration de Claude Desktop (fichier claude_desktop_config.json), l’agent peut désormais rechercher des jeux de données open data à la demande, sans aucune configuration supplémentaire dans le prompt.

Cas d’usage dans une infrastructure open source

MCP prend tout son sens dans une stack auto-hébergée, où l’on contrôle les APIs et les données. Quelques exemples :

Serveur MCP pour CKAN : exposer la recherche, la lecture de jeux de données et l’accès aux ressources d’un portail open data directement à un agent.
Serveur MCP pour Gitea : lire des dépôts, créer des issues, consulter l’historique de commits depuis un agent de revue de code ou de documentation.
Serveur MCP pour PostgreSQL : permettre à un agent IA d’exécuter des requêtes SQL en lecture sur une base de données analytique, avec contrôle des droits par rôle.
Serveur MCP pour Nextcloud : lire et écrire des fichiers dans un espace documentaire, alimenter un agent de gestion de connaissances.
Serveur MCP de monitoring : interroger Prometheus, lire les alertes Grafana, permettre à un agent de diagnostic de répondre à des questions sur l’état de l’infrastructure.

Sécurité et périmètre d’accès

Un serveur MCP hérite des droits du processus qui l’exécute. Il est donc crucial de l’exécuter avec des permissions minimales : accès en lecture seule aux bases de données quand c’est suffisant, token API à portée restreinte, isolation réseau si le serveur est exposé à distance. Les transports SSE (Server-Sent Events) pour les serveurs distants doivent être protégés par authentification — un token Bearer ou une mTLS selon le niveau d’exposition.

Il faut également penser à la traçabilité : chaque appel d’outil par un agent est une action avec des effets potentiels. Journaliser les appels MCP — quel outil, avec quels paramètres, à quelle heure — est une bonne pratique, surtout pour les outils qui modifient des données.

L’écosystème MCP en 2026

Le protocole MCP s’est rapidement imposé comme un standard de facto pour l’outillage des agents IA. Des centaines de serveurs MCP sont aujourd’hui disponibles en open source : pour GitHub, Slack, PostgreSQL, Elasticsearch, les navigateurs web, les systèmes de fichiers, et bien d’autres. La spécification est ouverte, implémentée en Python, TypeScript, Go, Rust, et intégrée nativement dans Claude Desktop, Claude Code, et de nombreux frameworks d’agents (LangChain, CrewAI, AutoGen).

Pour une infrastructure open source auto-hébergée, écrire ses propres serveurs MCP est la méthode la plus directe pour donner à ses agents IA un accès structuré, auditable et maintenable aux systèmes internes — sans exposer ces systèmes à des tiers ni dépendre d’intégrations propriétaires.