MCP est partout. Chaque annonce d'outil IA début 2026 le mentionne. Chaque article sur la "stack IA moderne" le liste. Mais quand tu demandes aux gens ce qu'est réellement MCP, tu obtiens soit une thèse de doctorat, soit un pitch marketing.

Voici la version en une phrase : MCP, c'est un port USB pour les agents IA.

C'est toute l'explication. OK d'accord, voici le reste. 😼

Le monde avant le standard

Imagine ton setup fin 2024. Tu construis un agent IA — un programme qui utilise un grand modèle de langage (LLM — le cerveau derrière ChatGPT, Claude, Gemini) pour prendre des décisions et agir de manière autonome. Ton agent doit interroger une base PostgreSQL, chercher sur le web, gérer des issues GitHub, et lire des fichiers locaux.

Pour chaque outil, tu écris du code d'intégration sur mesure :

# Chaque outil a besoin de son propre code de liaison
from custom_postgres import query_db
from custom_github import create_issue
from custom_search import web_search
from custom_files import read_file

# Chaque intégration a ses propres :
# - Méthodes d'authentification
# - Formats de réponse
# - Gestion d'erreurs
# - Gestion de connexion

Chaque fournisseur IA construisait son propre système d'intégration. Claude avait le "tool use". OpenAI avait le "function calling". LangChain avait les "tools". Ils faisaient tous la même chose de manières incompatibles. Construire une intégration pour l'un signifiait tout reconstruire pour l'autre.

C'est l'ère du port série, du port parallèle, du chargeur propriétaire de l'outillage IA. Tu te souviens de ça ? Avant l'USB, chaque appareil avait son propre câble. Le chaos total. 😹

Le vide à combler

Le problème n'était pas que les intégrations étaient difficiles. Le problème, c'est qu'elles étaient difficiles à chaque fois. Un nouvel outil sort — tu écris encore 200 lignes d'intégration custom. Multiplie ça par chaque client IA sur le marché. Le calcul est brutal.

Quelqu'un devait définir une prise universelle.

Voici MCP

Anthropic a introduit MCP (Model Context Protocol) fin 2024 comme standard ouvert — un standard de prise universelle pour les outils IA, comme l'USB mais pour les données. En mars 2026, c'est devenu la méthode par défaut pour connecter les agents IA au monde extérieur.

Voici à quoi ressemble la connexion de quatre outils avec MCP :

{
  "mcpServers": {
    "postgres": { "command": "npx", "args": ["-y", "@mcp/server-postgres", "..."] },
    "github": { "command": "npx", "args": ["-y", "@mcp/server-github"] },
    "search": { "command": "npx", "args": ["-y", "@mcp/server-brave-search"] },
    "files": { "command": "npx", "args": ["-y", "@mcp/server-filesystem", "/home"] }
  }
}

Quatre outils. Quatre lignes de config. Zéro code custom. Chaque serveur parle le même protocole — un ensemble de règles définissant comment les programmes communiquent — et chaque client le comprend.

L'architecture : trois acteurs, zéro magie

MCP a exactement trois composants :

┌──────────────────┐
│       HOST       │  (Claude Code, Cursor, ton appli)
│                  │
│  ┌────────────┐  │
│  │   CLIENT   │──── MCP Protocol ──── SERVER (Postgres, GitHub)
│  └────────────┘  │
│                  │
│  ┌────────────┐  │
│  │   CLIENT   │──── MCP Protocol ──── SERVER (Search, Files)
│  └────────────┘  │
└──────────────────┘

Host — l'application IA avec laquelle tu interagis. Claude Code, Claude Desktop, Cursor, Windsurf, ou ta propre appli custom.

Client — vit à l'intérieur du host. Gère la connexion à un serveur. Un host peut exécuter plusieurs clients connectés à plusieurs serveurs simultanément.

Server — fournit les outils et les données. Tourne comme un processus séparé — un programme autonome — soit sur ta machine, soit sur un serveur distant.

Pas de couche d'orchestration. Pas de file de messages. Pas de service mesh. Juste un client qui parle à un serveur via un protocole standard. C'est tout. 😸

Ce qui circule dans le tuyau

Les serveurs MCP peuvent fournir trois types de choses :

1. Tools — les actions que l'IA peut effectuer

Les tools sont des fonctions — des opérations autonomes — que l'IA peut appeler. Comme "exécuter une requête SQL" ou "créer une issue GitHub".

{
  "name": "query",
  "description": "Run a read-only SQL query against the database",
  "inputSchema": {
    "type": "object",
    "properties": {
      "sql": { "type": "string", "description": "The SQL query to execute" }
    },
    "required": ["sql"]
  }
}

Quand le serveur démarre, il dit au client : "Voici les outils que je fournis, voici ce que chacun fait, voici les paramètres." Le modèle IA lit ces descriptions et décide quand les utiliser — de la même façon que tu décides quelle appli ouvrir sur ton téléphone.

2. Resources — les données que l'IA peut lire

Les resources sont des morceaux de données que le serveur expose. Le contenu d'un fichier, un schéma de base de données (la structure de tes tables), une configuration.

La distinction est importante : les tools font des choses, les resources fournissent du contexte. L'IA lit les resources pour comprendre l'environnement avant d'agir. Pense à ça comme lire la carte du restaurant avant de commander.

3. Prompts — des templates de démarrage

Des templates pré-écrits que le serveur propose, comme "analyse cette table" ou "review cette pull request". Ce sont des raccourcis pratiques qui savent comment utiliser efficacement les outils du serveur.

La plupart des gens ignorent les prompts et parlent normalement à leur IA. Et c'est très bien. Ils sont optionnels.

Traçage d'une vraie requête

Suivons ce qui se passe quand tu tapes "Montre-moi tous les utilisateurs inscrits aujourd'hui" dans Claude Code avec un serveur MCP Postgres connecté :

1. TU tapes : "Montre-moi tous les utilisateurs inscrits aujourd'hui"

2. CLAUDE voit que les outils MCP Postgres sont disponibles
   (query, list_tables, describe_table)

3. CLAUDE appelle d'abord 'describe_table' pour comprendre
   la structure de la table users

4. CLIENT envoie au SERVER :
   { "method": "tools/call",
     "params": { "name": "describe_table",
                 "arguments": { "table": "users" } } }

5. SERVER interroge PostgreSQL, renvoie le schéma

6. CLAUDE écrit une requête SQL basée sur le schéma :
   SELECT * FROM users WHERE created_at >= CURRENT_DATE

7. CLIENT envoie la requête au SERVER, SERVER l'exécute

8. CLAUDE formate les résultats et te les affiche

Le tout prend 1-2 secondes. Tu as posé ta question en français, l'IA a trouvé le SQL, le serveur MCP l'a exécuté, et tu as tes résultats. Pas de requête manuelle. C'est le moment "ah mais c'est génial" pour la plupart des gens. 😻

La couche transport — comment les bits voyagent

MCP fonctionne via deux méthodes de transport :

STDIO (serveurs locaux) — le serveur tourne comme processus enfant sur ta machine. La communication passe par stdin/stdout — les mêmes pipes texte que ton terminal utilise. C'est le setup le plus courant :

{
  "mcpServers": {
    "my-server": {
      "command": "node",
      "args": ["server.js"],
      "env": { "DB_URL": "..." }
    }
  }
}

Simple, rapide, pas de réseau impliqué.

Streamable HTTP (serveurs distants) — pour les serveurs sur d'autres machines. Hébergés dans le cloud, partagés dans une équipe, ou services tiers :

{
  "mcpServers": {
    "remote-server": {
      "url": "https://mcp.example.com/sse",
      "headers": { "Authorization": "Bearer your-token" }
    }
  }
}

Les requêtes partent en HTTP POST classique. Les réponses arrivent en streaming temps réel. C'est comme ça que fonctionnent les déploiements entreprise — des serveurs centralisés auxquels plusieurs développeurs se connectent.

Construis le tien en 20 lignes

Voici le serveur MCP fonctionnel le plus simple que tu puisses écrire avec le SDK officiel TypeScript :

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

const server = new McpServer({
  name: "my-tool",
  version: "1.0.0"
});

server.tool(
  "hello",
  "Says hello to someone",
  { name: { type: "string", description: "Person to greet" } },
  async ({ name }) => ({
    content: [{ type: "text", text: `Hello, ${name}!` }]
  })
);

const transport = new StdioServerTransport();
await server.connect(transport);

Installe le SDK (npm install @modelcontextprotocol/sdk), définis tes outils, connecte le transport. Le SDK gère la négociation du protocole — le handshake où client et serveur se mettent d'accord sur ce qu'ils supportent tous les deux — le parsing des messages et la gestion d'erreurs.

Un exemple pratique — API météo

server.tool(
  "get_weather",
  "Get current weather for a city",
  {
    city: { type: "string", description: "City name" },
    units: { type: "string", description: "celsius or fahrenheit", default: "celsius" }
  },
  async ({ city, units }) => {
    const response = await fetch(
      `https://wttr.in/${encodeURIComponent(city)}?format=j1`
    );
    const data = await response.json();
    const current = data.current_condition[0];
    const temp = units === "fahrenheit"
      ? current.temp_F + "°F"
      : current.temp_C + "°C";
    return {
      content: [{ type: "text", text: `${city}: ${temp}, ${current.weatherDesc[0].value}` }]
    };
  }
);

Maintenant ton agent IA peut vérifier la météo. Plus important encore, observe le pattern : récupère des données depuis n'importe quelle API (interface de programmation applicative — la façon dont les programmes communiquent entre eux), emballe-les dans un outil MCP, et chaque client compatible MCP de la planète peut l'utiliser.

Le handshake de capacités

Quand un client se connecte à un serveur pour la première fois, ils négocient :

Client : "Je supporte tools, resources et prompts. T'as quoi ?"
Server : "Je fournis 3 tools et 2 resources. Les voilà."
Client : "Reçu. C'est parti."

Ce qui signifie que les clients n'ont pas besoin de savoir à l'avance ce qu'un serveur fournit. Les serveurs peuvent ajouter ou supprimer des fonctionnalités sans rien casser. Différents clients peuvent utiliser le même serveur différemment. C'est de l'évolution gracieuse, pas du couplage fragile.

Ce qui n'est pas parfait

Ne faisons pas semblant que c'est sans défaut. En mars 2026 :

La sécurité, c'est ton problème. Un serveur MCP peut faire tout ce que tu lui donnes la permission de faire. Un serveur malveillant pourrait exfiltrer des données via les appels d'outils. Il n'y a pas de sandboxing intégré — pas d'isolation automatique du reste de ton système. Tu fais confiance à chaque serveur comme tu fais confiance à n'importe quel paquet npm que tu installes. Réfléchis-y deux secondes.

La découverte est bordélique. Trouver le bon serveur MCP pour ton cas d'usage signifie parcourir des registres comme mcpservers.org ou glama.ai/mcp/servers. Il n'y a pas encore de marketplace centralisée et vérifiée. La qualité varie énormément.

Le debug est pénible. Quand un appel d'outil échoue, les messages d'erreur traversent souvent plusieurs couches — client, protocole, serveur, API sous-jacente — et ressortent de l'autre côté en bouillie. Ça s'améliore, mais c'est encore douloureux.

L'overhead de performance existe. Chaque appel d'outil est un aller-retour JSON-RPC — un message requête-réponse au format JSON. Pour les serveurs STDIO locaux, c'est négligeable. Pour les serveurs distants en HTTP, la latence s'accumule quand l'IA enchaîne plusieurs appels.

Ce que ça signifie pour toi

Si tu utilises des outils de code IA comme Claude Code ou Cursor : MCP signifie que ton IA acquiert de nouvelles capacités sans mise à jour logicielle. Un nouveau serveur MCP pour Jira apparaît ? Installe-le, et ton IA gère tes tickets. Un nouveau serveur pour AWS ? Ton IA gère ton infrastructure. Tu n'attends pas que l'éditeur de l'outil construise des intégrations — la communauté les construit.

Si tu construis des outils ou des APIs : MCP signifie que tu écris une seule intégration et elle fonctionne avec Claude, Cursor, Windsurf, Cline, et chaque futur client compatible MCP. Un serveur, des dizaines de clients. C'est le calcul USB.

Si tu es fondateur : construire un serveur MCP pour ton produit devient un prérequis, comme construire une API REST l'était il y a 10 ans. Si ton outil développeur n'a pas de serveur MCP, tes utilisateurs te demanderont pourquoi.

L'écosystème en mars 2026

  • Serveurs officiels d'Anthropic : PostgreSQL, GitHub, Filesystem, Brave Search, Puppeteer, Google Maps, Slack, et plus — voir le dépôt des serveurs MCP
  • Serveurs entreprise d'AWS, Cloudflare, Sentry
  • Serveurs communautaires pour Docker, Kubernetes, Notion, Linear, Figma, Stripe — des centaines et ça continue
  • La roadmap 2026 se concentre sur la communication agent-à-agent, le scaling horizontal, et un mécanisme de découverte .well-known pour que les serveurs puissent s'annoncer automatiquement

L'USB a tué le chargeur propriétaire. MCP tue les intégrations custom.

MCP est la chose la plus importante qui soit arrivée à l'outillage IA depuis que les fenêtres de contexte — la mémoire de travail de l'IA — sont devenues assez grandes pour contenir une vraie codebase. Ce n'est pas sexy. C'est un protocole JSON-RPC sur stdio. Mais l'USB non plus n'était pas sexy, et il a tué chaque connecteur propriétaire sur son passage.

Le truc le plus malin que tu puisses faire maintenant : arrête de lire des documents de spécification. Installe un serveur MCP Postgres, connecte-le à Claude Code, et pose-lui des questions sur ta base de données. Tu comprendras MCP en 30 secondes.

La spécification, c'est pour ceux qui construisent le protocole. Toi, tu l'utilises. 😹