Model Context Protocol (MCP) : le standard ouvert qui connecte les LLM à vos outils et données en 2026

Initié par Anthropic fin 2024, adopté en 2025 par OpenAI, Google DeepMind et Microsoft, le Model Context Protocol s'est imposé en 2026 comme le standard de référence pour brancher n'importe quel LLM sur vos outils, vos APIs et vos données métier. Fini les intégrations sur mesure pour chaque assistant : un serveur MCP écrit une fois est réutilisable par Claude, ChatGPT, Cursor, Claude Code, Zed et toute la nouvelle vague d'agents IA — exactement comme LSP a unifié l'intégration des IDE en 2016.

Pourquoi MCP a changé la donne en deux ans

Avant MCP, connecter un LLM à une base de données, à un système de fichiers ou à une API interne signifiait écrire du code spécifique pour chaque fournisseur : tool calling propriétaire chez OpenAI, blocs tool_use chez Anthropic, function calling chez Google, plugins ChatGPT, GPTs, actions Copilot. Chaque équipe réinventait la même intégration pour chaque modèle. MCP résout ce problème en standardisant un protocole JSON-RPC sur stdio, WebSocket ou HTTP streamable, qui expose trois primitives universelles : tools (actions exécutables), resources (données contextuelles) et prompts (templates partagés). En 2026, Anthropic recense plus de 4 000 serveurs MCP publics dans son registre officiel, et la plupart des SaaS B2B (GitHub, Linear, Notion, Stripe, Sentry, PostgreSQL, Slack, Atlassian) publient désormais leur propre serveur de référence.

L'architecture client-serveur-host expliquée

MCP repose sur trois rôles. Le host est l'application qui orchestre le LLM (Claude Desktop, Cursor, Claude Code, votre propre IDE ou SaaS). Le client est instancié par le host et maintient une connexion 1-pour-1 avec un serveur. Le serveur est un processus indépendant qui expose des capacités locales (filesystem, git, base de données) ou distantes (APIs SaaS). Cette séparation permet d'isoler les permissions : un serveur a accès uniquement à ce qu'on lui donne, et le host arbitre toujours les appels du modèle avec consentement utilisateur. Les SDK officiels en TypeScript, Python, Java, C# et Rust ramènent l'écriture d'un serveur fonctionnel à une vingtaine de lignes — déclarer un schéma Zod pour les paramètres, retourner du contenu structuré, et c'est terminé.

Construire son propre serveur MCP en TypeScript

Le SDK @modelcontextprotocol/sdk propose une API déclarative pour TypeScript et Node.js. On instancie un McpServer, on enregistre des tools avec un nom, un schéma Zod et un handler asynchrone qui retourne le résultat. Le serveur peut être exposé en stdio pour l'usage local (parfait pour Claude Desktop ou Claude Code), ou via le nouveau transport HTTP streamable de la spec 2025-06-18 pour le déploiement multi-utilisateurs sur Cloudflare Workers, Vercel ou un VPS. La gestion d'authentification est désormais standardisée autour d'OAuth 2.1 avec PKCE et metadata discovery, ce qui élimine les bricolages de tokens statiques qui caractérisaient les premières versions du protocole. Pour distribuer votre serveur, il suffit de le publier sur npm : npx -y mon-serveur-mcp devient la ligne à coller dans la configuration du client.

Cas d'usage concrets et pièges à éviter

En entreprise, MCP s'impose pour brancher Claude ou ChatGPT sur le code interne (serveur git + serveur de tickets Jira), sur la knowledge base (serveur Notion ou Confluence), sur les bases de production (serveur PostgreSQL en lecture seule avec row-level security) et sur les outils d'observabilité (serveur Sentry ou Datadog). Les pièges classiques en 2026 : exposer trop de tools dans un seul serveur — au-delà de 30, le modèle se perd dans la sélection ; ignorer les permissions de scope OAuth et donner un accès trop large ; oublier que les resources sont préférables aux tools pour les données statiques (le LLM les charge en contexte sans appel actif) ; et ne pas tester le serveur avec MCP Inspector, l'outil officiel qui simule un client et permet de valider schémas, latences et erreurs avant déploiement.