Qu'est-ce que le MCP ? Le Model Context Protocol expliqué

MCP, le Model Context Protocol, est un protocole ouvert qui connecte de façon standardisée les applications d'IA à des outils et à des données externes. Un service décrit une seule fois ce qu'il propose, sous la forme d'un serveur MCP, et les clients compatibles peuvent l'utiliser, qu'il s'agisse de Claude Code, Cursor, Codex ou VS Code, à condition qu'ils prennent en charge son transport, son autorisation et sa version du protocole. Anthropic a présenté MCP le 25 novembre 2024. En décembre 2025, l'entreprise a fait don du protocole à l'Agentic AI Foundation, un fonds dédié (directed fund) placé sous l'égide de la Linux Foundation.

Le problème que résout MCP

Un modèle de langage ne connaît que ce qui se trouve dans son contexte. Pour lire un ticket, interroger une base de données ou lancer un déploiement, une application d'IA a besoin d'une intégration avec ce système. Avant MCP, chaque application construisait la sienne. Selon les mots d'Anthropic : « Every new data source requires its own custom implementation, making truly connected systems difficult to scale. » Autrement dit, chaque nouvelle source de données exigeait une intégration spécifique, ce qui compliquait la mise à l'échelle des systèmes connectés.

MCP remplace ces intégrations au cas par cas par un seul protocole. Un service implémente un serveur MCP, une application d'IA implémente des clients MCP, et chacun peut communiquer avec des systèmes compatibles, sous réserve du transport, de l'autorisation, de la version et des fonctionnalités qu'ils prennent en charge. La spécification indique s'inspirer du Language Server Protocol, qui a standardisé la prise en charge des langages de programmation dans les outils de développement. En décembre 2025, Anthropic citait ChatGPT, Cursor, Gemini, Microsoft Copilot et Visual Studio Code parmi les produits ayant adopté MCP.

Hôtes, clients et serveurs

• Hôte (host) : l'application d'IA dans laquelle vous travaillez, comme Claude Code, Claude Desktop ou VS Code. Il coordonne un ou plusieurs clients.
• Client : un composant de l'hôte qui maintient la connexion avec un serveur. L'hôte crée un client par serveur.
• Serveur : le programme qui fournit les outils et le contexte. Il tourne sur votre machine (serveur local) ou comme service sur Internet (serveur distant).

Le client et le serveur échangent des messages JSON-RPC 2.0. Quand vous connectez Claude Code à Nodion, Claude Code est l'hôte, il exécute un client pour cette connexion, et c'est le serveur MCP hébergé de Nodion qui répond.

Ce qu'offre un serveur : outils, ressources et prompts

• Outils (tools) : des fonctions que le modèle peut appeler pour agir, comme un appel d'API ou une requête en base de données. Chaque outil a un nom, une description et un JSON Schema pour ses entrées. Les outils sont contrôlés par le modèle : c'est lui qui décide quand en appeler un, en fonction de votre demande.
• Ressources (resources) : des données qui donnent du contexte au modèle, comme le contenu de fichiers, des enregistrements de base de données ou des réponses d'API.
• Prompts : des gabarits de prompts réutilisables pour travailler avec le modèle, comme un prompt système ou des exemples few-shot.

Le client découvre les outils avec tools/list et en exécute un avec tools/call. Voici l'appel tiré de la spécification, sans les métadonnées que porte chaque requête :

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "location": "New York" }
  }
}

Un serveur peut aussi demander des informations à l'utilisateur. Avec l'elicitation, le serveur répond à une requête par un résultat indiquant qu'il a besoin de plus d'informations ; le client interroge l'utilisateur et renvoie la requête avec la réponse. Dans la révision actuelle, les serveurs ne lancent pas de requêtes de leur propre initiative.

Transports : stdio et Streamable HTTP

MCP définit deux transports standard, et les transports personnalisés sont aussi autorisés :

• stdio : l'hôte lance le serveur comme processus local et communique avec lui via l'entrée et la sortie standard. Cela convient aux outils qui travaillent sur votre machine, comme un serveur de système de fichiers. Un serveur local sert généralement un seul client.
• Streamable HTTP : le client envoie ses messages par HTTP POST, et le serveur peut transmettre ses réponses en flux avec des Server-Sent Events. C'est le transport des serveurs distants. Il prend en charge l'authentification HTTP standard, comme les bearer tokens, les clés d'API et les en-têtes personnalisés, et le protocole recommande OAuth pour obtenir les tokens.

La révision actuelle de la spécification porte la date 2026-07-28. Le protocole y est sans état (stateless) : chaque requête porte la version du protocole et les capacités dont elle a besoin, si bien qu'un serveur peut traiter chaque requête indépendamment. La révision décrit aussi des extensions facultatives comme Tasks et MCP Apps ; les détails se trouvent dans la spécification.

Pourquoi MCP compte pour les agents de codage IA

Les agents de codage IA lisent, écrivent et testent déjà le code de votre dépôt. Une bonne partie du travail autour de ce code se passe dans d'autres systèmes : le gestionnaire de tickets, la base de données, le suivi des erreurs et la plateforme d'hébergement. MCP permet à l'agent de travailler aussi dans ces systèmes.

• Une intégration pour de nombreux agents : un service qui fournit un serveur MCP fonctionne avec des clients compatibles comme Claude Code, Cursor et Codex, sans plugin séparé pour chacun, tant qu'ils prennent en charge son transport, son autorisation et ses fonctionnalités.
• Des demandes en langage naturel : les noms, les descriptions et les schémas d'entrée des outils indiquent au modèle ce qu'il peut faire, si bien que « Montrez-moi les dernières erreurs » devient le bon appel d'outil.
• Rien à installer pour les serveurs distants : un serveur hébergé n'a besoin que de son URL et d'une clé ou d'une connexion à votre compte.

Sécurité : ce qu'il faut vérifier avant de connecter un serveur

MCP donne à un modèle l'accès à de vrais systèmes, et la spécification le dit clairement : les outils représentent une exécution de code arbitraire, et les hôtes doivent obtenir le consentement explicite de l'utilisateur avant d'invoquer un outil. En pratique :

• Confirmez les actions d'écriture. Gardez un humain dans la boucle : la spécification demande aux applications d'indiquer quels outils sont exposés et de demander une confirmation, et ce sont les paramètres d'autorisation de votre client qui décident s'il le fait. Ne comptez pas sur un flag côté serveur que l'agent peut positionner lui-même.
• Appliquez le principe du moindre privilège aux clés. Donnez à chaque serveur un identifiant d'accès avec uniquement les scopes dont il a besoin, et utilisez une clé par agent pour pouvoir la révoquer séparément. Les recommandations de sécurité de la spécification appellent cela la minimisation des scopes (scope minimization).
• Ne connectez que des serveurs de confiance. Les clients doivent considérer les descriptions et les annotations des outils comme non fiables, sauf si elles proviennent d'un serveur de confiance.
• Vérifiez les serveurs locaux. Un serveur local tourne avec les mêmes privilèges que le client qui le lance. Lisez la commande exacte avant d'en ajouter un.
• Gardez les secrets hors du chat. Les tokens ont leur place dans la configuration du client, pas dans un prompt.

Le serveur MCP hébergé de Nodion

Nodion héberge un serveur MCP distant à l'adresse https://mcp.nodion.net/mcp. Votre agent utilise le même compte que vous dans le dashboard, et il n'y a aucun processus local à installer. Une fois connecté, vous formulez vos demandes en langage naturel : créer un projet, déployer une app depuis le dépôt courant, rattacher une base de données, définir des variables d'environnement, lire les logs et vérifier qu'une release est en ligne. Que l'on vous demande votre accord avant chaque appel d'outil dépend des paramètres d'autorisation de votre client. Nodion exige aussi un flag de confirmation explicite sur les outils d'écriture pour les clés personnelles, mais c'est l'agent qui définit ce flag : il ne remplace donc pas une vérification humaine.

Claude Code se connecte avec une seule commande et une clé personnelle créée sous Account → Security :

claude mcp add nodion --transport http https://mcp.nodion.net/mcp \
  --header "Authorization: Bearer nodion_your_key"

Les clés personnelles portent des scopes comme read, write, deploy, env:read et logs:read, et vous pouvez limiter une clé à certains projets. Un agent qui doit seulement analyser des erreurs n'a besoin ni de write ni de deploy.

Cursor utilise le même type de clé. Claude Desktop, ChatGPT et Codex se connectent plutôt via OAuth : vous vous connectez sur la page d'autorisation de Nodion et vous y liez un ou plusieurs projets. Les secrets restent dans le dashboard, et la connexion ne collecte ni mots de passe ni valeurs d'environnement dans le chat. Windsurf, Zed, VS Code Copilot et OpenCode utilisent la même URL de serveur, https://mcp.nodion.net/mcp.

La configuration de chaque client est décrite sur Connectez Nodion à votre agent, et la référence complète se trouve dans la documentation MCP.