Ce que fait réellement un serveur MCP et pourquoi le construire soi-même

Le Model Context Protocol, standardisé par Anthropic fin 2024, est un protocole JSON-RPC 2.0 qui permet à un LLM de découvrir et d'appeler des outils exposés par un serveur externe. La plupart des articles s'arrêtent là. Ce qui est utile en pratique, c'est de comprendre que vous pouvez exposer n'importe quelle logique métier, une API interne, une base de données, un système de fichiers propriétaire, comme un outil natif pour Claude, pour GPT-4o via un client compatible, ou pour vos propres agents orchestrés sous n8n ou LangGraph.

Les serveurs MCP communautaires disponibles sur le dépôt officiel couvrent les cas génériques : GitHub, Slack, Postgres, systèmes de fichiers locaux. Dès que vous avez une API interne, un ERP, ou un pipeline de données maison, vous devez écrire votre propre serveur. C'est là que le SDK officiel TypeScript entre en jeu. Il prend en charge le handshake de négociation de capacités, la sérialisation des schémas d'outils en JSON Schema, et le routage des appels entrants vers vos handlers. Vous écrivez la logique métier, pas la plomberie protocole.

Structure minimale d'un serveur MCP en TypeScript

Avec le SDK officiel ModelContextProtocol pour Node.js, un serveur fonctionnel tient en moins de cinquante lignes. Vous instanciez un objet Server, vous déclarez vos outils via le handler ListTools, chaque outil ayant un nom, une description en langage naturel, et un inputSchema JSON Schema strict. Ensuite vous branchez le handler CallTool qui reçoit le nom de l'outil et les arguments validés, exécute votre logique, et retourne un tableau de ContentBlock. Le transport par défaut en développement est stdio, ce qui permet de le tester directement depuis Claude Desktop en modifiant le fichier de configuration mcpServers.

Les points de friction que l'on rencontre systématiquement au moment du développement :

  • Les descriptions d'outils sont lues par le LLM comme des instructions : une description vague produit des appels mal construits. Rédigez-les comme des docstrings orientées comportement, pas comme des labels UI.
  • Le JSON Schema doit être strict : évitez additionalProperties non contrôlé, le modèle invente alors des paramètres inexistants.
  • Les erreurs doivent remonter via isError true dans le ContentBlock retourné, pas via une exception non catchée qui coupe la connexion stdio.
  • En production, le transport HTTP avec SSE est préférable à stdio. Le SDK expose un SSEServerTransport que vous branchez sur un serveur Express ou Fastify en quelques lignes.
  • La gestion des timeouts est de votre responsabilité côté serveur : si votre outil appelle une API tierce lente, le client MCP peut abandonner la connexion avant la réponse.

Intégrer un serveur MCP custom dans n8n et dans un agent LangGraph

Depuis la version 1.68 de n8n, le nœud MCP Client permet de pointer vers n'importe quel serveur MCP exposé en HTTP SSE. Vous renseignez l'URL du endpoint SSE, n8n liste automatiquement les outils disponibles, et vous pouvez les utiliser dans un nœud AI Agent comme s'il s'agissait d'outils natifs. C'est particulièrement efficace pour exposer des connecteurs métier sans recoder un nœud n8n complet. Le serveur MCP devient une couche d'abstraction réutilisable entre plusieurs workflows et plusieurs agents.

Côté LangGraph ou LangChain en Python, la bibliothèque langchain-mcp-adapters publiée début 2025 convertit les outils MCP en BaseTool LangChain. Vous ouvrez une session avec MultiServerMCPClient, vous passez la configuration de vos serveurs, et vous récupérez une liste d'outils prêts à être injectés dans votre agent. La compatibilité est complète avec LangGraph et avec le mode tool calling de tous les LLM supportés par LangChain.

Ce qui mérite attention avant de déployer en production

L'authentification n'est pas définie dans le protocole MCP de base. En pratique, vous sécurisez le endpoint HTTP avec un header Authorization vérifié dans votre middleware Express, ou vous passez par un tunnel Cloudflare avec access policy si le serveur tourne en local. La spec MCP 2025-03 introduit OAuth 2.1 comme mécanisme recommandé, mais peu de clients le supportent encore nativement, Claude Desktop inclus.

L'autre point structurant concerne la granularité des outils. Un outil MCP qui fait trop de choses crée de l'ambiguïté pour le modèle. Préférez des outils atomiques avec des noms d'action clairs, par exemple get_invoice_by_id plutôt qu'un outil générique manage_invoices avec un paramètre action. Le LLM compose mieux avec des primitives précises qu'avec des abstractions polysémiques. C'est une règle de conception qui s'applique aussi bien aux function calls OpenAI qu'aux outils MCP.