MCP : le protocole qui unifie l'IA

TL;DR

MCP (Model Context Protocol) est un standard ouvert qui connecte les LLM a des outils externes via une architecture client/serveur.

OpenAI l'a adopte en mars 2025, ce qui en fait un standard de facto pour l'industrie.

Un serveur MCP expose des outils, des ressources et des prompts. Un client (l'agent) les consomme.

Tu peux construire un serveur MCP en quelques dizaines de lignes avec le SDK officiel.

C'est plus important que n'importe quelle sortie de modele : ca structure l'ecosysteme.

Le probleme que personne ne voulait resoudre

Pendant deux ans, chaque fournisseur d'IA a invente sa propre facon de connecter un LLM au monde exterieur. OpenAI avait les plugins, puis les GPTs, puis le function calling. Google avait ses extensions Gemini. Anthropic avait son propre systeme d'outils. Chaque startup construisait ses connecteurs custom.

Resultat : si tu voulais que ton application IA parle a Slack, a une base de donnees et a Git, tu ecrivais trois integrations differentes pour chaque fournisseur. Trois formats, trois protocoles, trois maintenances. C'etait l'equivalent du monde avant USB, ou chaque peripherique avait son propre connecteur proprietaire.

Le probleme n'etait pas technique. Les integrations fonctionnaient. Le probleme etait structurel : l'ecosysteme ne pouvait pas scaler avec N fournisseurs x M outils. Ca faisait N*M connecteurs a maintenir. Intenable.

MCP : l'USB de l'IA

En novembre 2024, Anthropic a publie le Model Context Protocol (MCP). L'idee est simple : un protocole ouvert et standardise pour connecter n'importe quel LLM a n'importe quel outil.

Comme USB pour les peripheriques. Tu ne te demandes pas si ton clavier est compatible avec ton PC. Tu le branches, ca marche. MCP vise exactement ca pour l'IA.

Le protocole definit trois types de capacites qu'un serveur peut exposer :

Tools : des fonctions que le LLM peut appeler. Lire un fichier, executer une requete SQL, envoyer un message.
Resources : des donnees que le LLM peut lire. Le contenu d'un fichier, le schema d'une base de donnees, un document.
Prompts : des templates de prompt pre-configures que le client peut utiliser.

Le tout avec un transport standardise (JSON-RPC 2.0), une decouverte automatique des capacites, et une gestion des permissions.

Pourquoi l'adoption d'OpenAI change tout

En mars 2025, OpenAI a annonce le support natif de MCP dans ses produits. C'est le moment ou MCP est passe de "protocole interessant d'Anthropic" a "standard de facto de l'industrie".

Quand le numero un et le numero deux du marche adoptent le meme protocole, le debat est clos. Les autres n'ont plus le choix. Google suivra (ou sera marginalise sur ce point). Les startups qui construisaient leurs propres connecteurs migrent vers MCP.

Ce que ca change concretement :

Plus de vendor lock-in sur les outils. Tu ecris un serveur MCP une fois, il marche avec Claude, avec GPT, avec n'importe quel client compatible.
Un ecosysteme partage. Les centaines de serveurs MCP deja construits par la communaute deviennent accessibles a tous les modeles.
Les agents deviennent interoperables. Un agent construit avec Claude Code peut theoriquement utiliser les memes outils qu'un agent GPT.

L'architecture : client, serveur, transport

Architecture MCP : un host contient plusieurs clients, chaque client parle a des serveurs

L'architecture est volontairement simple :

Host : l'application qui contient le LLM. Claude Desktop, un IDE avec IA integree, ton application custom. Le host cree et gere les clients.

Client : maintient une connexion 1:1 avec un serveur MCP. Un client pour Git, un client pour ta base de donnees, un client pour Slack. Chacun negocie les capacites avec son serveur au demarrage.

Serveur : expose des tools, des resources et des prompts via JSON-RPC. Le serveur peut tourner en local (stdio) ou a distance (HTTP avec Server-Sent Events, ou le nouveau Streamable HTTP).

Transport : deux modes principaux. stdio pour les serveurs locaux (le host lance un processus fils et communique via stdin/stdout). HTTP pour les serveurs distants.

Le flux est toujours le meme : le client se connecte, decouvre les capacites du serveur (tools/list, resources/list), puis le LLM peut appeler ces outils quand il en a besoin.

Construire un serveur MCP en 50 lignes

Prenons un exemple concret : un serveur MCP qui expose un outil pour recuperer la meteo d'une ville.

hljs typescript

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

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

server.tool(
  "get-weather",
  "Recupere la meteo actuelle pour une ville",
  {
    city: z.string().describe("Nom de la ville"),
  },
  async ({ city }) => {
    const response = await fetch(
      `https://api.weatherapi.com/v1/current.json?key=${process.env.API_KEY}&q=${city}`
    );
    const data = await response.json();

    return {
      content: [
        {
          type: "text",
          text: `Meteo a ${city}: ${data.current.condition.text}, ${data.current.temp_c}°C`,
        },
      ],
    };
  }
);

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

C'est tout. Ce serveur peut etre utilise par Claude Desktop, par un agent custom, par n'importe quel client MCP. Tu declares un outil avec un nom, une description, un schema de parametres (via Zod), et une fonction d'execution. Le SDK gere tout le reste : la negociation des capacites, le parsing JSON-RPC, la serialisation des reponses.

Pour le connecter a Claude Desktop, tu ajoutes quelques lignes dans la configuration :

hljs json

{
  "mcpServers": {
    "weather": {
      "command": "npx",
      "args": ["tsx", "weather-server.ts"],
      "env": {
        "API_KEY": "ta-cle-api"
      }
    }
  }
}

Pourquoi c'est plus important qu'un nouveau modele

Chaque semaine sort un nouveau modele plus performant. GPT-4.1, Claude 3.5, Gemini 2. Et chaque semaine, le modele de la semaine precedente est depasse. C'est la course aux benchmarks, et elle ne s'arretera pas.

Mais un protocole, c'est different. Un protocole structure l'ecosysteme. TCP/IP n'est pas "meilleur" que tel ou tel reseau local proprietaire des annees 80. Il a gagne parce qu'il a permis a tout le monde de se connecter a tout le monde. HTTP n'est pas techniquement parfait. Il a gagne parce qu'il a cree le web.

MCP joue le meme role pour l'IA. Il ne rend pas les modeles plus intelligents. Il les rend utiles, en leur donnant un acces standardise au monde reel.

Les implications pour les developpeurs :

Construis des serveurs, pas des plugins. Un serveur MCP que tu ecris aujourd'hui sera utilisable dans deux ans, quel que soit le modele dominant.
L'integration devient un investissement durable. Plus besoin de reecrire tes connecteurs a chaque changement de fournisseur.
Les agents deviennent composables. Tu peux assembler des serveurs MCP comme des briques Lego pour creer des agents specialises.

Les limites actuelles

MCP n'est pas parfait. Quelques points a garder en tete :

La securite est encore jeune. Le modele de permissions est basique. Un serveur MCP malveillant pourrait potentiellement exfiltrer des donnees via les arguments d'outils. Les mecanismes d'authentification et d'autorisation entre clients et serveurs distants sont encore en cours de maturation.

La decouverte reste manuelle. Il n'y a pas encore de registre central officiel de serveurs MCP. Tu dois savoir quel serveur installer et le configurer manuellement. Des registres communautaires comme Smithery et mcp.run commencent a combler ce vide.

Le debug n'est pas trivial. Quand un agent echoue a utiliser un outil MCP, diagnostiquer le probleme (transport ? schema ? permission ? logique ?) demande de l'outillage. L'inspecteur MCP officiel aide, mais c'est encore rudimentaire.

Les performances varient. Un serveur stdio local est rapide. Un serveur HTTP distant introduit de la latence. Pour des agents qui font des dizaines d'appels d'outils, ca s'accumule.

Le futur : un ecosysteme d'outils partage

Ce qui m'excite le plus, c'est ce qui vient apres l'adoption. Quand un protocole devient un standard, l'ecosysteme explose. Pense a ce qui s'est passe avec les API REST : une fois le standard etabli, tout le monde a pu construire par-dessus.

On va voir apparaitre des marketplaces de serveurs MCP, des frameworks pour les construire plus vite, des outils de monitoring et de securite dedies. Les entreprises vont exposer leurs services internes via MCP pour que leurs agents internes puissent les consommer.

Et surtout : le role du developpeur evolue. On ne construit plus juste des applications. On construit des capacites que les agents peuvent utiliser. C'est un changement de paradigme discret mais profond.