MCP (Model Context Protocol)

Le principe en une phrase

MCP (Model Context Protocol) est un protocole ouvert qui standardise la manière dont les modèles d'IA se connectent aux sources de données et aux outils externes. C'est un adaptateur universel : un seul standard pour brancher n'importe quelle source de données à n'importe quel modèle.

Avant MCP, chaque connexion entre un modèle d'IA et un outil externe nécessitait une intégration spécifique et fragile. Avec MCP, on passe d'un problème M x N (M modèles x N outils) à un problème M + N : chaque modèle implémente MCP une fois, chaque outil implémente MCP une fois, et tout communique.

Le problème : le M x N des intégrations

Imaginez un écosystème avec 5 modèles d'IA (Claude, GPT, Gemini, Llama, Mistral) et 10 outils (GitHub, Slack, PostgreSQL, Jira, Google Drive, etc.). Sans standard, il faut coder 5 x 10 = 50 intégrations spécifiques.

Claude  ──── GitHub      (intégration spécifique)
Claude  ──── Slack       (intégration spécifique)
Claude  ──── PostgreSQL  (intégration spécifique)
GPT     ──── GitHub      (autre intégration spécifique)
GPT     ──── Slack       (encore une autre)
...

Chaque intégration a son propre format, sa propre authentification, sa propre gestion d'erreurs. Si GitHub modifie son API, toutes les intégrations côté modèle doivent être mises à jour. C'est un cauchemar de maintenance.

Avec MCP, chaque côté n'implémente le protocole qu'une seule fois :

Claude  ─┐
GPT     ─┤              ┌── GitHub (serveur MCP)
Gemini  ─┼── MCP ───────┼── Slack (serveur MCP)
Llama   ─┤              ├── PostgreSQL (serveur MCP)
Mistral ─┘              └── Jira (serveur MCP)

5 + 10 = 15 implémentations au lieu de 50. Et chaque nouvel outil ou modèle n'ajoute qu'une seule implémentation.

L'architecture de MCP

MCP suit un modèle client-serveur :

• Le Host : l'application qui utilise l'IA (par exemple, Claude Desktop, un IDE, un chatbot).
• Le Client MCP : intégré dans le Host, il se connecte aux serveurs MCP.
• Le Serveur MCP : expose les données et les outils d'un service externe via le protocole MCP.

┌─────────────────────────────────────┐
│           Host (Claude Desktop)      │
│                                     │
│  ┌──────────┐    ┌──────────┐      │
│  │ Client   │    │ Client   │      │
│  │ MCP #1   │    │ MCP #2   │      │
│  └────┬─────┘    └────┬─────┘      │
│       │               │            │
└───────┼───────────────┼────────────┘
        │               │
   ┌────▼─────┐   ┌────▼─────┐
   │ Serveur  │   │ Serveur  │
   │ MCP      │   │ MCP      │
   │ (GitHub) │   │ (Slack)  │
   └──────────┘   └──────────┘

Les trois primitives de MCP

MCP expose trois types de capacités :

1. Les Ressources (Resources)

Des données que le modèle peut lire. Similaire à un endpoint GET dans une API REST.

{
  "uri": "github://repos/my-org/my-repo/issues/42",
  "name": "Issue #42",
  "mimeType": "application/json"
}

Le modèle peut demander à lire cette ressource pour obtenir le contenu d'une issue GitHub, le contenu d'un fichier, les résultats d'une requête SQL, etc.

2. Les Outils (Tools)

Des actions que le modèle peut exécuter. Similaire à un endpoint POST.

{
  "name": "create_github_issue",
  "description": "Crée une issue sur un dépôt GitHub",
  "inputSchema": {
    "type": "object",
    "properties": {
      "repo": { "type": "string" },
      "title": { "type": "string" },
      "body": { "type": "string" }
    },
    "required": ["repo", "title"]
  }
}

Le modèle peut appeler cet outil pour créer une issue, envoyer un message Slack, exécuter une requête SQL, etc.

3. Les Prompts

Des templates de conversation prédéfinis qui guident l'interaction. Par exemple, un prompt pour analyser les performances d'une requête SQL ou pour faire une revue de code.

{
  "name": "analyze_query",
  "description": "Analyse les performances d'une requête SQL",
  "arguments": [
    { "name": "query", "description": "La requête SQL à analyser" }
  ]
}

Exemple concret : un serveur MCP pour une base de données

Voici à quoi ressemble un serveur MCP simplifié qui expose une base de données PostgreSQL :

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import pg from "pg";
 
const pool = new pg.Pool({ connectionString: process.env.DATABASE_URL });
const server = new Server(
  { name: "postgres-server", version: "1.0.0" },
  { capabilities: { tools: {}, resources: {} } },
);
 
// Exposer un outil pour exécuter des requêtes SQL en lecture seule
server.setRequestHandler("tools/list", async () => ({
  tools: [
    {
      name: "query",
      description: "Exécute une requête SQL en lecture seule",
      inputSchema: {
        type: "object",
        properties: {
          sql: {
            type: "string",
            description: "La requête SELECT à exécuter",
          },
        },
        required: ["sql"],
      },
    },
  ],
}));
 
server.setRequestHandler("tools/call", async (request) => {
  if (request.params.name === "query") {
    const sql = request.params.arguments.sql;
 
    // Sécurité : n'autoriser que les SELECT
    if (!sql.trim().toUpperCase().startsWith("SELECT")) {
      return {
        content: [
          { type: "text", text: "Seules les requêtes SELECT sont autorisées." },
        ],
      };
    }
 
    const result = await pool.query(sql);
    return {
      content: [
        { type: "text", text: JSON.stringify(result.rows, null, 2) },
      ],
    };
  }
});
 
// Démarrer le serveur sur stdin/stdout
const transport = new StdioServerTransport();
await server.connect(transport);

Une fois ce serveur configuré, un modèle d'IA peut interroger la base de données en langage naturel. L'utilisateur demande "Quels sont les 10 clients avec le plus de commandes ?", le modèle génère la requête SQL, l'exécute via l'outil MCP, et présente les résultats.

L'analogie avec USB

MCP est souvent comparé à l'USB pour l'IA. Avant l'USB, chaque périphérique (imprimante, scanner, souris) avait son propre connecteur et son propre pilote. L'USB a unifié tout cela : un seul port, un seul standard. Tout périphérique compatible USB fonctionne avec tout ordinateur compatible USB.

MCP fait la même chose pour les modèles d'IA : un seul protocole pour connecter n'importe quel modèle à n'importe quelle source de données ou outil.

Transports de communication

MCP supporte deux modes de transport :

stdio : le client lance le serveur MCP comme un processus fils et communique via stdin/stdout. Simple, idéal pour les outils locaux.

HTTP avec SSE (Server-Sent Events) : pour les serveurs distants. Le client envoie des requêtes HTTP et reçoit les réponses via un flux SSE. Adapté aux déploiements cloud.

Sécurité et bonnes pratiques

MCP introduit des questions de sécurité importantes :

• Principe du moindre privilège : un serveur MCP pour une base de données ne devrait exposer que des requêtes en lecture seule, pas des DROP TABLE.
• Validation des entrées : les arguments des outils proviennent du modèle d'IA, qui peut halluciner ou être manipulé. Validez tout.
• Consentement utilisateur : les actions sensibles (écriture, suppression) devraient nécessiter une confirmation humaine avant exécution.
• Authentification : chaque serveur MCP doit gérer ses propres credentials pour accéder au service sous-jacent, sans les exposer au modèle.

Résumé

MCP transforme l'écosystème des intégrations IA en passant d'un problème M x N à un problème M + N. Au lieu de coder une intégration fragile pour chaque combinaison modèle/outil, on implémente un protocole standard une seule fois de chaque côté. C'est un changement d'échelle : chaque nouveau serveur MCP est immédiatement utilisable par tous les clients compatibles, et chaque nouveau modèle compatible a accès à tous les serveurs existants.