Brancher une IA à ses outils avec MCP (Model Context Protocol)

Tu veux qu'un assistant IA lise ta base, appelle ton API ou déclenche une action — sans réécrire une intégration propriétaire à chaque fois ? Le Model Context Protocol (MCP) est un standard ouvert : tu écris un serveur qui expose des outils, et n'importe quel client compatible (Claude Desktop, un IDE, ton propre agent) peut les utiliser. À la fin de ce tuto, tu auras un serveur MCP fonctionnel avec un outil.

Étape 1 — Comprendre le découpage

• Serveur MCP : expose des outils (fonctions typées), des ressources (données) et des prompts. C'est toi qui l'écris.
• Client MCP : l'appli qui héberge l'IA. Elle liste tes outils et décide quand les appeler selon la conversation.
• Transport : comment les deux se parlent. En local, c'est stdio (entrée/sortie standard). À distance, du HTTP.

Le modèle ne « voit » jamais ton code : il voit une description d'outil et des arguments typés.

Étape 2 — Initialiser le projet

mkdir mcp-meteo && cd mcp-meteo
npm init -y
npm install @modelcontextprotocol/sdk zod

Dans package.json, ajoute "type": "module" pour utiliser les imports ES.

Étape 3 — Écrire le serveur

Un serveur minimal qui expose un outil get_meteo (server.js) :

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: "meteo", version: "1.0.0" });

server.tool(
  "get_meteo",
  { ville: z.string().describe("Nom de la ville") },
  async ({ ville }) => {
    // Ici tu appellerais ta vraie API météo ; on simule.
    const tempC = 21;
    return {
      content: [{ type: "text", text: `Il fait ${tempC}°C à ${ville}.` }],
    };
  }
);

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

Le schéma Zod ({ ville: z.string() }) sert deux choses : il documente l'outil pour le modèle et valide les arguments reçus.

Étape 4 — Brancher un client et tester

Dans Claude Desktop, ajoute le serveur à la config MCP (fichier claude_desktop_config.json) :

{
  "mcpServers": {
    "meteo": {
      "command": "node",
      "args": ["/chemin/absolu/vers/mcp-meteo/server.js"]
    }
  }
}

Redémarre le client. Demande à l'assistant « quel temps fait-il à Lyon ? » : il doit détecter l'outil get_meteo, l'appeler avec ville: "Lyon", et te répondre avec le résultat.

Adapter à ton cas

• Lecture de données : un outil search_clients(query) qui interroge ta base et renvoie les résultats en texte.
• Action : un outil create_ticket(titre, priorite) qui écrit dans ton système — expose-le seulement si tu maîtrises les droits.
• Ressources : au lieu d'un outil, expose un document comme ressource pour que le client l'injecte dans le contexte.
• À distance : remplace le transport stdio par le transport HTTP pour un serveur accessible en réseau (ajoute alors une authentification).

En cas de souci

• Le client ne voit pas le serveur : chemin non absolu dans la config, ou node introuvable. Vérifie le chemin et relance le client (la config n'est lue qu'au démarrage).
• L'outil n'est jamais appelé : sa description est trop vague. Un .describe() clair sur l'outil et ses arguments aide le modèle à savoir quand l'utiliser.
• Erreur de validation : le modèle a envoyé un argument non conforme au schéma Zod. Rends le schéma plus tolérant ou précise la description.
• Sécurité : un outil qui écrit ou supprime est une action réelle déclenchée par un modèle. Commence en lecture seule, ajoute des garde-fous (validation, quotas) avant toute action destructive, et n'expose jamais de secrets dans les réponses d'outil.