Model Context Protocol : la révolution des connexions IA-outils

Une nouvelle ère pour les agents d'IA : le Model Context Protocol

Dans mes précédents articles, j'ai exploré la manière dont les agents d'IA choisissent et utilisent divers outils, en détaillant le processus par lequel un modèle génère un appel d'outil, notre code l'exécute, et le résultat est renvoyé au modèle. Cette méthode fonctionne bien dans un cadre simplifié, mais elle pose un problème majeur : la provenance des outils.

Dans les exemples que nous avons étudiés, les outils étaient définis manuellement dans le même script Python que l'agent. Cette méthode, bien qu'adéquate pour un tutoriel, devient rapidement impraticable dans une application réelle. Chaque outil nécessite une intégration sur mesure, chaque paire modèle-outil a besoin de son propre connecteur, et ainsi de suite. Par exemple, une configuration avec trois modèles d'IA et dix outils pourrait nécessiter jusqu'à trente intégrations, et chaque changement dans ces éléments peut entraîner des dysfonctionnements. En résumé, cette approche ne s'adapte pas à des configurations complexes.

Ce problème n'est pas isolé, mais représente un défi majeur dans l'ère actuelle de l'IA agentique. C'est précisément pour résoudre ce problème que le Model Context Protocol (MCP) a été conçu.

Les défis avant l'introduction du MCP

Avant l'avènement du MCP, connecter un modèle d'IA à un outil externe, tel qu'une base de données ou un dépôt GitHub, nécessitait une intégration personnalisée à chaque fois. Le modèle devait comprendre comment appeler l'outil dans son format spécifique, et l'outil devait savoir répondre dans un format compréhensible par le modèle. Si le modèle ou l'outil changeait, l'intégration devait être réécrite.

Ce problème est souvent décrit comme le problème M×N, où M représente le nombre de modèles et N le nombre d'outils, nécessitant M×N intégrations personnalisées. À mesure que le nombre de modèles et d'outils augmente, cette approche devient insoutenable.

Une analogie utile est l'évolution des connecteurs matériels. Autrefois, chaque périphérique informatique avait son propre connecteur propriétaire. Ce problème a été résolu par l'adoption de l'USB comme connecteur standard. De même, le MCP peut être vu comme l'USB des agents d'IA, un protocole standard permettant à tout agent compatible de se connecter à n'importe quel outil compatible, indépendamment de leur fabricant.

Définition et architecture du Model Context Protocol

Le Model Context Protocol est un standard ouvert qui permet aux développeurs de créer des connexions sécurisées et bidirectionnelles entre leurs sources de données et les outils alimentés par l'IA. Créé par Anthropic et publié en open source en novembre 2024, il remplace les intégrations personnalisées par un protocole client-serveur unique, permettant à tout hôte d'IA compatible MCP de découvrir et d'utiliser des outils et ressources de données compatibles MCP.

L'architecture du MCP repose sur trois participants principaux :

• L'Hôte : C'est l'application d'IA avec laquelle l'utilisateur interagit, comme Claude Desktop ou une extension VS Code. L'hôte gère la fenêtre de contexte du modèle, décide quand invoquer des outils, et redirige les sorties des outils dans la conversation.

• Le Client : Il réside à l'intérieur de l'hôte et gère la connexion à un ou plusieurs serveurs MCP. Le client est la partie de l'application qui gère le protocole MCP.

• Le Serveur : C'est là où se trouvent les outils et les données réelles. Un serveur MCP expose des capacités à travers une interface standardisée, mais ne communique jamais directement avec le LLM ; toute interaction est médiée par le client.

Les capacités exposées par le serveur MCP peuvent être de trois types :

• Outils : Ce sont des opérations exécutables qui renvoient leur sortie au modèle d'IA, comme des requêtes à une base de données ou l'envoi d'un e-mail.

• Ressources : Elles offrent un accès en lecture seule aux données, comme le contenu de fichiers ou les réponses d'API.

• Prompts : Ce sont des modèles de prompts réutilisables qui définissent des schémas d'interaction structurés.

Mise en œuvre d'un serveur MCP en Python

Pour illustrer le fonctionnement du MCP, examinons un exemple de serveur MCP minimal en Python, utilisant le SDK MCP officiel :

from mcp.server.fastmcp import FastMCP

# créer un serveur MCP
mcp = FastMCP("weather-server")

def get_current_weather(city: str, unit: str = "celsius") -> dict:
    """Obtenir la météo actuelle pour une ville donnée en utilisant Open-Meteo."""
    # géocoder la ville
    geo = requests.get(
        "https://geocoding-api.open-meteo.com/v1/search",
        params={"name": city, "count": 1}
    )
    lat = geo["results"][0]["latitude"]
    lon = geo["results"][0]["longitude"]
    weather = requests.get(
        "https://api.open-meteo.com/v1/forecast",
        params={
            "latitude": lat,
            "longitude": lon,
            "current": "temperature_2m,weather_code",
            "temperature_unit": unit
        }
    )
    return {
        "[temperature](/glossaire/temperature)": weather["current"]["temperature_2m"],
    }

if __name__ == "__main__":
    # Lancement du serveur
    mcp.run()

Dans cet exemple, nous enregistrons notre fonction get_current_weather comme un outil MCP en utilisant @mcp.tool(). Ce décorateur génère automatiquement le schéma JSON à partir des annotations de type, le rendant découvrable par tout hôte compatible MCP. Ainsi, le besoin d'intégrations personnalisées et d'adaptateurs spécifiques au modèle est éliminé. Tout agent compatible MCP peut désormais appeler cet outil météo en se connectant à ce serveur MCP.

Intégration côté client

Examinons maintenant le côté client, où un agent peut se connecter à 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:
            # découvrir les outils disponibles sur le serveur
            tools = await session.list_tools()
            print(f"Outils disponibles : {[t.name for t in tools.tools]}")
            # Outils disponibles : ['get_current_weather']
            # l'agent peut maintenant appeler cet outil comme n'importe quel autre
            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ôte découvre les outils disponibles sur le serveur sans avoir besoin de les connaître à l'avance. Ainsi, nous passons d'intégrations codées en dur à des capacités dynamiques et découvrables.

Implications pratiques du MCP

Avant le MCP, la question de savoir si un agent pouvait utiliser un outil nécessitait une réponse d'ingénierie personnalisée. Avec le MCP, cette question devient triviale, remplacée par des considérations sur les outils auxquels les agents devraient avoir accès, et comment sécuriser cet accès à grande échelle.

Le MCP a été lancé en novembre 2024 avec environ 100 000 téléchargements mensuels du SDK. En mars 2025, OpenAI l'a adopté officiellement, suivi par Google pour son projet Gemini. En mars 2026, les SDK Python et TypeScript combinés avaient atteint 97 millions de téléchargements mensuels.

En décembre 2025, Anthropic a transféré le MCP à la Agentic AI Foundation (AAIF), sous l'égide de la Linux Foundation, assurant ainsi sa viabilité à long terme. Ce transfert a placé le MCP aux côtés de projets comme Kubernetes et PyTorch dans le portefeuille d'infrastructure ouverte de la Linux Foundation.

Nous assistons à l'émergence d'un écosystème MCP, avec un marché de serveurs MCP préconstruits pour des outils populaires. Des serveurs MCP existent pour GitHub, Slack, PostgreSQL, Docker, Kubernetes, et bien d'autres, tous consultables via le MCP Registry. Connecter un agent à ces serveurs est désormais une simple étape de configuration.

Pour les développeurs, cela change le calcul entre construire et intégrer. Avant le MCP, connecter un agent à divers systèmes nécessitait plusieurs intégrations personnalisées. Avec le MCP, si des serveurs existent, il s'agit d'une simple configuration. S'ils n'existent pas, créer un serveur MCP une fois permet à n'importe quel agent de l'utiliser.

Il est crucial de noter que le MCP ne remplace pas les API REST. Le MCP est un protocole pour l'accès aux outils d'IA, et non un standard d'API général. Vos API REST et GraphQL continuent de servir des clients humains et des services traditionnels, le MCP venant simplement les envelopper.