Le problème que le MCP résout

Les grands modèles de langage (LLM) comme Claude, GPT-4 ou Gemini sont, dans leur état natif, des systèmes fermés. Ils reçoivent du texte, produisent du texte, mais n'ont aucun accès direct aux données de l'entreprise, aux outils internes, aux bases de données, aux APIs tierces ou au système de fichiers.

Pour combler ce fossé, les développeurs ont longtemps bricolé des solutions ad hoc : copier-coller de données dans les prompts, intégrations custom en dur dans le code, wrappers propriétaires… Cette fragmentation engendrait plusieurs problèmes critiques :

• Duplication de code — chaque équipe réimplémentait sa propre glue entre l'IA et les outils
• Maintenance coûteuse — un changement d'API tierce cassait l'intégration entière
• Sécurité approximative — les credentials et contextes sensibles circulaient de façon non standardisée
• Scalabilité limitée — impossible de réutiliser une intégration d'un projet à l'autre

Anthropic lance le MCP — novembre 2024

Le 25 novembre 2024, Anthropic publie le Model Context Protocol en open-source. L'annonce est accompagnée d'un SDK disponible en Python et TypeScript, ainsi que d'une poignée de serveurs MCP de référence connectant Claude Desktop à des outils courants : filesystem, GitHub, Google Drive, Slack, PostgreSQL, Puppeteer, etc.

La décision d'ouvrir le protocole dès le départ est stratégiquement importante : Anthropic ne cherche pas à capturer la valeur de l'écosystème d'intégration, mais à définir le standard. La communauté réagit fortement — en quelques semaines, des centaines de serveurs MCP tiers émergent.

L'écosystème avant MCP : le chaos des intégrations

Vue d'ensemble : un protocole client-serveur

MCP s'articule autour d'une architecture client-serveur standardisée. Trois acteurs principaux :

Le protocole de base : JSON-RPC 2.0

MCP repose sur JSON-RPC 2.0 comme protocole de messagerie. Ce choix est délibéré : JSON-RPC est simple, largement supporté, language-agnostic, et permet à la fois des appels request/response et des notifications unidirectionnelles.

La communication suit un cycle en 3 phases :

1. Initialisation — échange de capabilities entre client et serveur (initialize / initialized)
2. Opération — échanges normaux : le client appelle les outils, lit les ressources, etc.
3. Fin de session — fermeture propre avec notification de shutdown

Les 3 primitives fondamentales

Tools — Les outils d'action

Les Tools sont des fonctions que le LLM peut appeler pour effectuer des actions. C'est la primitive la plus utilisée et la plus puissante.

• Définition — chaque tool possède un nom, une description en langage naturel, et un schéma JSON Schema décrivant ses paramètres
• Exécution — le LLM décide d'appeler un tool, le client MCP transmet l'appel au serveur, le serveur exécute et renvoie le résultat
• Contrôle humain — par convention, les tools qui modifient l'état du monde (écriture, suppression, envoi) doivent être approuvés par l'utilisateur
• Exemples concrets — créer un fichier, exécuter une requête SQL, appeler une API externe, envoyer un email

Resources — Les données consultables

Les Resources sont des données exposées par le serveur que le LLM peut consulter. Contrairement aux Tools, elles sont en lecture seule et identifiées par une URI.

• Statiques — un fichier de configuration, un document de référence, un schéma de base de données
• Dynamiques — un flux de logs en temps réel, des données de capteurs IoT, le contenu actuel d'une page web
• Subscription — le client peut s'abonner aux changements d'une resource (notifications push)
• Chunking — les resources volumineuses peuvent être lues par morceaux via cursor pagination

Prompts — Les modèles de conversation

Les Prompts sont des templates de conversation pré-définis exposés par le serveur. Ils permettent aux développeurs de packager des workflows complexes et de les rendre accessibles à l'utilisateur via une interface standard.

• Paramétrables — un prompt peut accepter des arguments (ex : le nom d'un projet, une plage de dates)
• Multi-messages — un prompt peut définir toute une conversation initiale, pas seulement un message système
• Découverte — le client liste les prompts disponibles (prompts/list) et peut les présenter dans une UI

stdio — La solution locale

Le transport stdio est le plus simple et le plus courant pour les serveurs MCP locaux. Le host lance le serveur MCP comme un sous-processus, et communique avec lui via stdin/stdout. C'est le transport utilisé par Claude Desktop.

• Avantages — sécurité maximale (pas de réseau), latence minimale, déploiement trivial
• Inconvénients — limité à la machine locale, un processus par serveur
• Cas d'usage — accès au filesystem, outils de développement, bases de données locales

HTTP + SSE — Le transport distant

Pour les serveurs MCP hébergés à distance (SaaS, APIs d'entreprise, microservices), MCP utilise HTTP avec Server-Sent Events (SSE). Les requêtes client-vers-serveur passent par HTTP POST, et le serveur pousse ses réponses via SSE.

• Avantages — déployable en cloud, accessible depuis n'importe où, permet le multi-tenant
• Inconvénients — latence réseau, nécessite authentification, plus complexe à sécuriser
• Évolution — HTTP Streamable annoncé en mars 2025, unifiant request/response et streaming dans un seul endpoint

L'authentification : le chantier ouvert

La sécurité est l'un des points de friction du MCP actuel. La spécification prévoit OAuth 2.1 pour les serveurs distants, mais l'implémentation reste complexe. Pour les serveurs locaux, la sécurité repose sur l'isolation des processus et les permissions du système d'exploitation.

Adoption par les grands acteurs

En l'espace de quelques mois, le MCP est passé de projet open-source d'Anthropic à standard de facto de l'industrie. Plusieurs signaux forts :

Le registre de serveurs MCP

Le dépôt GitHub officiel modelcontextprotocol/servers répertorie des dizaines de serveurs officiels. La communauté en a développé des centaines d'autres. Les grandes catégories :

• Productivité — Slack, GitHub, Notion, Linear, Jira, Asana, Monday.com
• Bases de données — PostgreSQL, SQLite, MySQL, MongoDB, Redis, Supabase
• Cloud & infra — AWS, GCP, Azure, Kubernetes, Docker, Terraform
• Développement — Git, npm, Docker, terminal shell, LSP
• Web & scraping — Puppeteer, Playwright, Brave Search, Fetch
• Data & BI — Tableau, Metabase, BigQuery, dbt
• Médias & contenu — YouTube, Spotify, Figma, Canva

Clients MCP disponibles

Sampling — L'IA qui parle à l'IA

L'une des primitives les plus puissantes et les moins documentées de MCP est le Sampling. Il permet à un serveur MCP de demander au LLM hôte de générer du texte, en lui passant une conversation et en récupérant la réponse.

En clair : le serveur MCP peut invoquer le modèle d'IA de façon récursive pour décomposer une tâche complexe, analyser un résultat intermédiaire, ou prendre une décision. Cela ouvre la voie à des architectures d'agents multi-étapes sans nécessiter un framework externe.

Roots — La négociation de périmètre

Les Roots permettent au client d'indiquer au serveur MCP quels répertoires ou URIs il est autorisé à manipuler. C'est le mécanisme de sandboxing du protocole.

• Le client déclare ses roots lors de l'initialisation
• Le serveur devrait respecter ces limites (par convention, non enforced)
• Exemple : permettre l'accès à /home/user/projet mais pas à /home/user/.ssh

Capacités et négociation de version

À l'initialisation, client et serveur échangent leurs capabilities respectives. Cela permet une compatibilité ascendante : un serveur v2025 peut servir un client v2024 en n'utilisant que les fonctionnalités que ce dernier comprend.

Le SDK Python — Démarrage rapide

Le SDK Python officiel (mcp ou fastmcp) permet de créer un serveur MCP en quelques dizaines de lignes. L'approche FastMCP est la plus élégante :

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("Mon Serveur MCP")

@mcp.tool()
def rechercher_commandes(client_id: str, statut: str = "tous") -> list:
    """Recherche les commandes d'un client dans la BDD."""
    # Votre logique métier ici
    return db.query(client_id, statut)

@mcp.resource("commandes://{client_id}")
def get_commandes_client(client_id: str) -> str:
    return json.dumps(db.get_all(client_id))

Bonnes pratiques de conception

Descriptions riches = meilleures décisions du LLM. La qualité de la description d'un tool est critique. Le LLM utilise cette description pour décider si et quand appeler le tool. Une description pauvre mène à des erreurs d'utilisation.

Granularité des tools

• Un tool = une action atomique et bien définie
• Éviter les tools trop génériques ("faire quelque chose") et trop spécifiques
• Grouper les opérations CRUD connexes dans le même serveur pour la cohérence

Gestion des erreurs

• Toujours retourner un message d'erreur descriptif plutôt que lever une exception non catchée
• Distinguer les erreurs utilisateur ("fichier non trouvé") des erreurs système
• Utiliser le champ isError dans le résultat du tool pour signaler un échec contrôlé

Limitations techniques

Limitations sécurité

La sécurité du MCP repose sur la confiance. Quelques vecteurs d'attaque importants à connaître :

• Tool poisoning — un serveur MCP malveillant peut inclure des instructions cachées dans les descriptions de tools pour manipuler le LLM
• Rug pull — un serveur initialement bénin peut être mis à jour avec un comportement malveillant
• Exfiltration de contexte — un tool peut accéder au contexte complet de la conversation si le host n'isole pas les informations
• Escalade de privilèges — un serveur peut tenter d'accéder à des resources au-delà des roots déclarées

MCP 2.0 : ce qui est déjà en cours

HTTP Streamable (mars 2025). Le transport HTTP + SSE actuel impose deux endpoints distincts (GET pour SSE, POST pour les requêtes). HTTP Streamable unifie cela : un seul endpoint POST qui peut retourner soit une réponse HTTP classique, soit un stream SSE selon le cas. Cela simplifie le déploiement et rend MCP compatible avec les proxies et loadbalancers standard.

Structured Tool Output. Actuellement, le résultat d'un tool est du texte libre. Une évolution attendue est la possibilité de définir un JSON Schema pour la sortie d'un tool, permettant au LLM de traiter des données structurées sans avoir à les parser depuis du texte.

Elicitation (demande d'input utilisateur). Un serveur MCP pourra bientôt demander une entrée interactive à l'utilisateur en cours d'exécution ("Quel est votre token API ?", "Confirmez-vous la suppression ?"). Cela permet des flux de travail multi-étapes avec validation humaine sans casser le protocole.

Multi-agent et orchestration

L'évolution la plus structurante de MCP sera sa place dans les architectures multi-agents. Deux directions se dessinent :

MCP agent-à-agent. Un agent IA peut lui-même être exposé comme un serveur MCP. Un orchestrateur ("agent manager") peut ainsi déléguer des sous-tâches à des agents spécialisés via le protocole MCP standard. C'est l'architecture qui émerge dans des frameworks comme LangGraph ou les Agents SDK.

MCP et la mémoire persistante

L'état actuel de MCP est fondamentalement stateless — chaque session repart de zéro. Les évolutions vers la mémoire persistante passent par deux vecteurs :

• Serveurs MCP de mémoire — des serveurs dédiés (mem0, Memory Bank) exposent des tools pour sauvegarder et récupérer des faits, des préférences utilisateur, des résultats de sessions précédentes
• Native persistence — une évolution possible serait une primitive de session avec état, où le serveur peut maintenir un contexte entre plusieurs appels du même utilisateur

Dans Claude.ai, la mémoire utilisateur actuelle est déjà un exemple de ce pattern : un système de mémoire externe exposé comme ressource contextuelle.

MCP dans les navigateurs

La version web de Claude teste actuellement une intégration navigateur (Claude in Chrome). Le MCP pourrait y jouer un rôle central : une extension de navigateur expose un serveur MCP qui donne à l'IA accès au DOM, aux onglets, aux cookies, à la navigation, aux formulaires — remplaçant les approches bricolées de Puppeteer/Playwright.

Vers un modèle de confiance étendu

La gestion des données sensibles est le prochain grand chantier :

• Chiffrement de bout en bout des résultats de tools : le LLM reçoit des données sans que le host puisse les lire
• Attestation cryptographique : un serveur MCP peut prouver son identité et son intégrité via une signature
• Policy as code : les permissions d'un serveur MCP définies dans un fichier de politique versionné
• Audit trail standardisé : un log immuable de tous les appels MCP pour la conformité réglementaire (RGPD, ISO 27001)

MCP vs. Function Calling (OpenAI)

MCP vs. LangChain Tools

LangChain a longtemps dominé l'espace des intégrations IA. Mais son modèle présente des frottements que MCP résout :

• LangChain est un framework applicatif : votre code dépend de LangChain. MCP est un protocole : votre code dépend uniquement de la spec JSON
• LangChain tools vivent dans le même processus que le LLM. Les serveurs MCP sont des processus indépendants, plus faciles à tester et à sécuriser
• LangChain impose Python. MCP supporte nativement Python, TypeScript, et par extension tout langage capable de JSON-RPC

LangChain a d'ailleurs annoncé un support MCP natif, reconnaissant la complémentarité des deux approches.

MCP vs. A2A (Google Agent-to-Agent Protocol)

En avril 2025, Google a publié le protocole A2A, visant à standardiser la communication entre agents IA de différents fournisseurs. MCP et A2A sont complémentaires, pas concurrents :

Pour les entreprises

Réduction du lock-in. En exposant vos données et outils via des serveurs MCP, vous n'êtes plus liés à un LLM particulier. Si Claude devient trop cher ou que GPT-5 offre de meilleures performances pour votre cas d'usage, la migration est désormais une question de configuration du client, pas de réécriture d'intégrations.

IA interne et données sensibles. Des serveurs MCP déployés on-premise peuvent exposer des données sensibles (RH, finances, R&D) uniquement à des LLMs auto-hébergés (LLaMA, Mistral, etc.), sans que les données ne quittent votre infrastructure. C'est un pattern souveraineté des données.

Le nouveau tier applicatif. On peut voir les serveurs MCP comme un nouveau tier dans l'architecture logicielle : après le tier données (bases de données) et le tier applicatif (APIs REST), le tier contexte (serveurs MCP) expose vos capacités métier aux agents IA. C'est un nouvel actif à développer et à maintenir.

Pour les développeurs

• Les serveurs MCP deviennent un produit livrable à part entière, au même titre qu'une API REST ou un package npm
• La compétence MCP (conception de tools, optimisation des descriptions, sécurité) est une compétence différenciante
• Les frameworks comme FastMCP réduisent la barrière d'entrée à quelques dizaines de lignes
• L'émergence d'un marché de serveurs MCP premium ou SaaS ("MCP as a Service") est prévisible

Pour les éditeurs de logiciels

Exposer un serveur MCP officiel devient un avantage compétitif. Les entreprises comme Linear, Notion, ou Figma qui ont déjà un MCP officiel capturent une part de valeur dans l'écosystème agentic. Les éditeurs qui n'ont pas de MCP risquent d'être contournés par des serveurs tiers qui accèdent à leurs APIs.

Le Model Context Protocol est plus qu'un standard technique. Il représente une rupture architecturale dans la façon dont nous concevons les systèmes d'information à l'ère des agents IA. En standardisant l'interface entre les LLMs et le monde extérieur, il répond à une question fondamentale : comment rendre l'IA utile dans des contextes réels, avec des données réelles, sans compromettre la sécurité et la maintenabilité ?

La rapidité de l'adoption — de la publication par Anthropic en novembre 2024 à l'adoption par OpenAI, Microsoft et Google en quelques mois — est sans précédent pour un protocole de cette nature. Elle révèle un besoin longtemps non satisfait et une fenêtre d'opportunité pour tous ceux qui comprennent et maîtrisent ce standard.

Les évolutions à venir — sessions persistantes, orchestration multi-agents, sécurité renforcée, registre centralisé — transformeront progressivement MCP d'un protocole d'intégration en une infrastructure critique de l'économie numérique. Comme HTTP pour le web, ou TCP/IP pour les réseaux, MCP a le potentiel de devenir le protocole invisible sur lequel repose l'ère des agents.