MCP expliqué : comment les agents d’IA modernes se connectent au monde réel

Dans mes derniers articles, sur l’appel d’outils, j’explore comment les agents d’IA décident quel outil utiliser et comment l’utiliser. Nous avons vu comment le modèle génère un appel d’outil, notre code l’exécute et le résultat est renvoyé au modèle. Cela fonctionne assez bien, mais il y a un problème que nous avons en quelque sorte passé sous silence. C’est, d’où viennent les outils ?

Dans tous les exemples présentés précédemment, nous avons défini nous-mêmes les outils, à la main, dans le même script Python que l’agent. Apparemment, pour un tutoriel destiné à nous aider à comprendre comment tout cela fonctionne, c’est bien, mais pour une application réelle, cette approche s’effondre rapidement. En effet, chaque outil nécessite une intégration personnalisée, chaque nouvelle paire modèle-outil nécessite son propre connecteur, etc. Pensez, par exemple, que pour une configuration utilisant trois modèles d’IA et dix outils, nous maintenons déjà potentiellement trente intégrations, et chaque fois qu’un de ces éléments change, quelque chose peut se casser. En d’autres termes, aussi efficace que cette approche puisse fonctionner pour une configuration simple de modèle et d’outils, elle ne s’adapte pas du tout.🤷‍♀️

Il ne s’agit pas d’un problème de niche, mais plutôt d’un défi majeur de l’ère de l’IA agentique. Et c’est exactement ce que Protocole de contexte de modèle (MCP) a été conçu pour résoudre.

Alors, jetons un coup d’œil !

🍨 Crème de données est un bulletin d’information à propos IA, données et technologie. Si ces sujets vous intéressent, abonnez-vous ici!

Et le MCP ?

Avant MCP, connecter un modèle d’IA à un outil externe (comme une base de données, un système de fichiers, un espace de travail Slack ou un référentiel GitHub) impliquait l’écriture d’une intégration personnalisée. à chaque fois. Le modèle devait savoir comment appeler l’outil dans son format spécifique, et d’un autre côté, l’outil devait savoir comment répondre dans un format que le modèle pouvait comprendre. Si le modèle changeait, nous devions réécrire l’intégration, et s’il y avait un nouvel outil, nous écririons une autre intégration à partir de zéro.

Ceci est parfois appelé le Problème M×Nce qui signifie que nous avons M modèles et N outils, créant le besoin d’intégrations personnalisées M × N. Comme vous pouvez l’imaginer, à mesure que le nombre de modèles et d’outils à utiliser augmente, cela ne s’adapte pas très bien.

Une métaphore utile pour comprendre cela est l’évolution et la standardisation du matériel informatique. Au début des périphériques informatiques, chaque imprimante, chaque souris, chaque clavier possédait son propre connecteur propriétaire (par exemple, une imprimante était achetée pour un ordinateur spécifique et ne fonctionnait pas avec un autre). Finalement, ce problème a été résolu par l’utilisation de l’USB comme connecteur standard unique, et tout appareil qui le prend en charge fonctionne avec n’importe quel ordinateur qui le prend en charge.

Nous pouvons imaginer MCP comme l’USB pour les agents IA. Un protocole standard et tout agent qui le prend en charge peuvent se connecter à n’importe quel outil qui le prend en charge, quelle que soit l’entreprise qui les a construits.

---

Ainsi, le Protocole de contexte de modèle est une norme ouverte qui permet aux développeurs d’établir des connexions bidirectionnelles sécurisées entre leurs sources de données et les outils basés sur l’IA. Il a été créé par Anthropic et publié en open source dans novembre 2024. Essentiellement, il remplace les intégrations point à point personnalisées par un protocole client-serveur unique, permettant à tout hôte IA compatible MCP de découvrir et d’utiliser tous les outils et ressources de données compatibles MCP.

Plus précisément, l’architecture MCP se compose de trois participants principaux. Ce sont :

1. L’hôtequi est l’application d’IA avec laquelle l’utilisateur interagit. Il peut s’agir de Claude Desktop, d’une extension VS Code ou de toute autre application intégrant un LLM. L’hôte gère la fenêtre contextuelle du modèle, décide quand appeler les outils et achemine les sorties des outils vers la conversation.
2. Le Clientqui réside à l’intérieur de l’hôte et gère la connexion à un ou plusieurs serveurs MCP. En d’autres termes, le client est la partie de l’application qui gère le protocole MCP.
3. Le serveuroù se trouvent les outils et les données réels. Un serveur MCP expose capacités (c’est-à-dire les choses que l’IA peut faire ou lire) via une interface standardisée. Une chose importante à clarifier ici est que le serveur ne communique jamais directement avec le LLM ; toute interaction est médiatisée par le client.

En particulier, concernant les capacités exposées par le serveur MCP, celles-ci peuvent être de trois types :

1. Outils: Comme nous l’avons déjà vu, les outils sont des opérations exécutables qui renvoient leur sortie au modèle d’IA. Celles-ci peuvent inclure l’interrogation d’une base de données, l’envoi d’un e-mail, l’appel d’une API météo ou toute autre chose. Essentiellement, nous pouvons créer des outils pour n’importe quelle opération imaginable, ce qui en fait l’élément puissant facilité par MCP, mais aussi le plus sensible en matière de sécurité.
2. Ressources: Les ressources sont essentiellement un accès en lecture seule aux données. Pensez, par exemple, au contenu des fichiers, aux enregistrements de base de données et aux réponses API. En d’autres termes, les ressources peuvent récupérer des informations mais ne changent jamais d’état.
3. Invites: Les invites sont des modèles d’invites réutilisables (duh !) qui définissent des modèles d’interaction structurés. Par exemple, un flux de travail en plusieurs étapes pour la révision du code disponible sur un serveur MCP est une invite.

Un simple serveur MCP en Python

Alors essayons tout cela en action. Voici à quoi ressemble un serveur MCP minimal en Python, en utilisant le SDK MCP officiel :

from mcp.server.fastmcp import FastMCP
import requests

# create an MCP server
mcp = FastMCP("weather-server")

@mcp.tool()
def get_current_weather(city: str, unit: str = "celsius") -> dict:
    """Get the current weather for a given city using Open-Meteo."""
    # geocode the city
    geo = requests.get(
        "https://geocoding-api.open-meteo.com/v1/search",
        params={"name": city, "count": 1}
    ).json()
    lat = geo["results"][0]["latitude"]
    lon = geo["results"][0]["longitude"]

    # fetch weather
    weather = requests.get(
        "https://api.open-meteo.com/v1/forecast",
        params={
            "latitude": lat,
            "longitude": lon,
            "current": "temperature_2m,weather_code",
            "temperature_unit": unit
        }
    ).json()

    return {
        "city": city,
        "temperature": weather["current"]["temperature_2m"],
        "unit": unit
    }

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

Aaet ça y est ; Nous avons maintenant mis en place un serveur MCP complet.

Remarquez comment nous enregistrons nos get_current_weather fonctionner comme un outil MCP en utilisant @mcp.tool(). Plus précisément, @mcp.tool() génère automatiquement le schéma JSON à partir des indices de type et le rend détectable par tout hôte compatible MCP. Ainsi, le code d’intégration personnalisé et les adaptateurs spécifiques au modèle ne sont plus nécessaires. Tout agent compatible MCP peut désormais appeler cet outil météo en se connectant à ce serveur MCP.

Voyons maintenant le côté client, où nous pouvons connecter un agent à ce serveur :

from anthropic import Anthropic
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client

async def run_agent_with_mcp():
    server_params = StdioServerParameters(
        command="python",
        args=["weather_server.py"]
    )

    async with stdio_client(server_params) as (read, write):
        async with ClientSession(read, write) as session:
            # discover available tools from the server
            tools = await session.list_tools()
            print(f"Available tools: {[t.name for t in tools.tools]}")
            # Available tools: ['get_current_weather']

            # the agent can now call this tool just like any other
            result = await session.call_tool(
                "get_current_weather",
                arguments={"city": "Athens", "unit": "celsius"}
            )
            print(result.content)
            # {'city': 'Athens', 'temperature': 29.0, 'unit': 'celsius'}

Au moment de l’exécution, l’hébergeur découvre les outils disponibles sur le serveur sans avoir besoin de savoir à l’avance de quoi il s’agit. Le changement clé est donc que nous sommes passés d’intégrations codées en dur (rappelez-vous l’outil météo codé en dur) à des intégrations dynamiques et détectables. capacités (l’outil météo est désormais disponible pour n’importe quelle application via le serveur MCP).

Ce que cela signifie en pratique

Avant MCP, la question «cet agent peut-il utiliser cet outil ?« nécessitait une réponse d’ingénierie personnalisée à chaque fois. Après MCP, cela devient trivialement résolu et la question est remplacée par une question pas si technique »à quels outils les agents doivent-ils avoir accès ?« . Plus précisément, comment les agents devraient-ils décider quels outils utiliser, et comment sécuriser et gouverner l’accès aux outils à grande échelle ?

---

Mais la partie technique du problème est plutôt résolue, et cela est également souligné par l’adoption impressionnante du MCP. MCP a été lancé en novembre 2024 avec environ 100 000 téléchargements mensuels de SDK. En mars 2025, OpenAI l’a officiellement adopté. Le mois suivant, Google a confirmé le support MCP pour Gemini, le décrivant comme « devenant rapidement un standard ouvert pour l’ère agentique de l’IA. » En mars 2026, les SDK combinés Python et TypeScript avaient atteint 97 millions de téléchargements mensuels.

En décembre 2025, Anthropic a fait don de MCP au Fondation pour l’IA agentique (AAIF)un fonds dirigé par la Linux Foundation, cofondé par Anthropic, Block et OpenAI. C’est cette décision qui a consolidé la viabilité à long terme de MCP, car il ne s’agit plus d’un projet d’un seul fournisseur, mais se trouve désormais aux côtés de Kubernetes et PyTorch dans le portefeuille d’infrastructures ouvertes de la Linux Foundation.

---

La conséquence pratique est que nous assistons à l’émergence d’un Écosystème MCP: un marché de serveurs MCP prédéfinis pour les outils et services populaires. Des serveurs MCP existent pour GitHub, Mou, PostgreSQL, Docker, Kuberneteset plusieurs centaines d’autres outils, tous consultables via le Registre MCP. Dans la plupart des cas, connecter votre agent à l’un d’entre eux constitue désormais une étape de configuration et non un projet d’ingénierie.

Pour les développeurs qui créent des applications agentiques, cela modifie considérablement le calcul de construction par rapport à l’intégration. Avant MCP, la connexion d’un agent à la base de connaissances interne, au CRM et au système de billetterie de votre entreprise nécessitait trois intégrations personnalisées distinctes. Avec MCP, si des serveurs existent pour ces systèmes (et c’est de plus en plus le cas), c’est une question de configuration. S’ils n’existent pas encore, écrire un serveur MCP une seule fois signifie que n’importe quel agent (pas seulement celui que vous construisez aujourd’hui) peut l’utiliser.

Il vaut également la peine de savoir ce que MCP ne fait pas. MCP ne remplacera pas les API REST. MCP est un protocole d’accès aux outils d’IA, et non une norme API à usage général. Vos API REST et GraphQL servent toujours les clients humains et les services traditionnels. Le seul ajout est que MCP encapsule ces API pour les rendre accessibles aux LLM.

---

MCP est puissant, et avec ce pouvoir devient réel sécurité responsabilité 🕸 qui mérite d’être signalée explicitement. Plus précisément, les risques les plus courants sont :

• Injection rapide via la sortie de l’outil: Cela fait référence à la possibilité qu’une source de données malveillante renvoie du contenu conçu pour manipuler le modèle afin d’appeler d’autres outils. Si votre serveur MCP renvoie du contenu généré par l’utilisateur (tickets d’assistance, notes CRM, etc.), le modèle le considère comme un contexte fiable.
• Empoisonnement d’outils: Cela fait référence à la possibilité qu’un serveur MCP malveillant puisse enregistrer des outils avec des noms imitant ceux de confiance. De cette façon, le modèle peut choisir les mauvais outils.
• Accès trop autorisé: Cela fait référence à la possibilité qu’un serveur MCP qui expose à la fois des outils de lecture et d’écriture à un agent qui n’a besoin que d’un accès en lecture crée un risque inutile.

La spécification officielle MCP répond à ceci : hôtes doivent obtenir le consentement explicite de l’utilisateur avant d’invoquer un outil, et les développeurs doivent créer des flux d’autorisation robustes dans leurs applications. Pour les déploiements en production, traitez l’accès aux outils MCP avec la même rigueur que vous appliqueriez à n’importe quelle API externe : autorisations de moindre privilège, validation des entrées et gestion minutieuse des sorties de l’outil avant qu’elles ne réintègrent le contexte du modèle.

Dans mon esprit

Ce que je trouve le plus intéressant dans MCP, ce ne sont pas les détails techniques, mais plutôt le fait qu’il représente une étape technologique majeure pour l’IA. Chaque écosystème technologique passe par une phase de standardisation de la plomberie, et c’est toujours à ce moment-là que commence la véritable innovation. Cela permet aux utilisateurs et aux développeurs de cesser de passer du temps à essayer de résoudre les problèmes de connexion et de commencer à consacrer du temps aux problèmes d’application.

Nous sommes à ce moment-là pour l’IA agentique. La question de savoir comment les agents se connectent aux outils est en grande partie résolue. Les questions les plus intéressantes qui se posent aujourd’hui portent sur ce que les agents devraient être autorisés à faire, comment évaluer s’ils le font bien, comment maintenir la surveillance humaine alors que les agents assument des tâches plus longues et plus complexes, etc. MCP est la base, et ce qui est construit dessus est la partie intéressante.

✨ Merci d’avoir lu ! ✨

---

Si tu es arrivé jusqu’ici, les pialgorithmes pourraient vous être utiles: une plateforme que nous avons créée qui aide les équipes à gérer en toute sécurité les connaissances organisationnelles en un seul endroit.

---

Vous avez adoré cet article ? Rejoignez-moi sur 💌 Sous-pile et 💼 LinkedIn

---

Toutes les images de l’auteur, sauf mention osinon