Qu'est-ce qu'un serveur MCP ? (et comment en construire un)

Ce qu'est un serveur MCP

Le MCP (Model Context Protocol) est un standard ouvert qui connecte les AI agents a des tools, donnees et services externes via une interface commune. Un serveur MCP est la piece que vous (ou un fournisseur) ecrivez et qui se place devant une capacite donnee: une base de donnees, un navigateur, un issue tracker, un systeme de fichiers, une API. Il annonce ce qu'il sait faire, et tout client MCP peut le decouvrir et l'utiliser. La raison pour laquelle le MCP s'est repandu si vite est qu'il resout un probleme N fois M: avant le MCP, chaque tool avait besoin d'une integration sur mesure pour chaque agent; avec le MCP, un tool s'integre une fois et fonctionne partout. Il existe donc aujourd'hui un serveur MCP pour presque tout ce qu'un agent doit atteindre.

• Un serveur enveloppe une capacite (une base de donnees, un navigateur, une API) et l'expose aux agents.
• Il parle le Model Context Protocol, pour que tout client MCP puisse l'utiliser sans code de colle sur mesure.
• Ecrivez l'integration une fois; toute appli compatible MCP en profite. C'est pourquoi le support s'est repandu vite.
• Voir l'entree de glossaire sur le MCP pour la definition courte et Tool Calling pour la facon dont les agents l'appellent.

Comment il fonctionne: host, client et serveur

Le MCP utilise une architecture client-serveur basee sur JSON-RPC 2.0, avec trois participants. Le host est l'application IA que vous utilisez, comme Claude Code ou Cursor. Quand le host demarre, il cree un client MCP par serveur configure, et chaque client tient sa propre connexion dediee et a etat vers un serveur MCP. Le serveur est le programme qui expose la capacite. Les messages circulent comme des requetes, reponses et notifications JSON-RPC via un transport. Il y a deux transports courants: stdio, ou le host spawne le serveur comme processus enfant local et ils dialoguent via l'entree et la sortie standard, et Streamable HTTP, utilise pour les serveurs distants heberges sur le cloud. Un host peut mener plusieurs connexions client-serveur simultanement, ainsi un agent atteint un systeme de fichiers, un navigateur et une base de donnees dans la meme session.

• Host: l'appli IA (Claude Code, Cursor, Claude Desktop) avec laquelle l'utilisateur interagit.
• Client: un par serveur, cree par le host, qui tient une connexion dediee.
• Serveur: votre programme qui expose une capacite et parle JSON-RPC 2.0.
• Transport: stdio pour les serveurs locaux, Streamable HTTP pour les distants (SSE est deprecated).

Ce qu'un serveur expose: tools, resources et prompts

Un serveur MCP peut exposer trois sortes de primitives, et un serveur donne implemente celles qui ont du sens pour lui. Les tools sont des actions que le modele peut appeler, comme "execute cette query" ou "cree ce issue"; chaque tool declare un schema d'input, pour que l'agent sache comment l'appeler. Les resources sont des donnees read-only que l'agent peut recuperer, comme le contenu d'un fichier ou un enregistrement de base de donnees, adresse par URI. Les prompts sont des templates reutilisables que le serveur offre, souvent presentes a l'utilisateur comme des slash commands ou des quick actions. Les tools sont de loin les plus courants, parce que la valeur principale du MCP est de laisser un agent agir sur un systeme, pas seulement le lire.

• Tools: des actions que l'agent peut appeler (interroger une base, ouvrir une PR, piloter un navigateur). Chacun a un schema d'input.
• Resources: des donnees read-only que l'agent peut recuperer par URI (contenu de fichier, enregistrements).
• Prompts: des templates reutilisables que le serveur offre, souvent montres comme slash commands.
• Un serveur declare quelles primitives il supporte; la plupart menent avec des tools.

Construire un serveur MCP minimal

Le moyen le plus rapide de comprendre un serveur est d'en construire un tout petit. Le SDK TypeScript officiel arrive comme le paquet @modelcontextprotocol/server et vous laisse monter un serveur stdio fonctionnel en quelques lignes: creez un McpServer, enregistrez un tool avec un nom, une description et un schema d'input Zod, puis connectez-le via un StdioServerTransport. L'exemple ci-dessous expose un tool greet. Sauvegardez-le, pointez votre client MCP sur la commande qui l'execute (pour Claude Code, c'est claude mcp add --transport stdio), et l'agent peut appeler greet. Un SDK Python (FastMCP) offre la meme forme si vous preferez Python.

// server.ts - a minimal MCP server exposing one tool over stdio
import { McpServer } from '@modelcontextprotocol/server'
import { StdioServerTransport } from '@modelcontextprotocol/server/stdio'
import * as z from 'zod'

const server = new McpServer({ name: 'greeting-server', version: '1.0.0' })

// Register a tool: a name, a description, and a Zod input schema.
server.registerTool(
  'greet',
  {
    description: 'Greet someone by name',
    inputSchema: z.object({ name: z.string() }),
  },
  async ({ name }) => ({
    content: [{ type: 'text', text: `Hello, ${name}!` }],
  }),
)

// Connect over stdio: the host spawns this file and talks via stdin/stdout.
const transport = new StdioServerTransport()
await server.connect(transport)

Gardez server.ts sans console.log sur stdout: un serveur stdio utilise stdout pour le protocole JSON-RPC, donc loggez plutot sur stderr. A partir de la, vous ajoutez d'autres tools, resources et prompts de la meme facon et vous passez a Streamable HTTP quand vous voulez heberger le serveur a distance.

Serveur MCP vs une simple API

Une question legitime est de savoir pourquoi un agent a besoin d'un serveur MCP alors que le service sous-jacent a deja une API REST. La difference est la decouverte et l'auto-description. Une API REST a besoin d'un humain qui lit sa doc et ecrit du code d'integration pour chaque client; un serveur MCP annonce ses tools, leurs schemas et leurs descriptions dans un standard que l'agent lit en se connectant, de sorte que l'agent apprend automatiquement a l'utiliser et que le meme serveur fonctionne sur tout client MCP. Le MCP ne remplace pas votre API; c'est une couche mince et adaptee aux agents devant elle. Pour un cas interne ponctuel, un CLI que l'agent peut appeler est peut-etre plus simple, mais pour tout ce que plusieurs agents et applis doivent utiliser, un serveur MCP est le choix interoperable.

• Une API REST a besoin de code d'integration par client; un serveur MCP est auto-descriptif et reutilise partout.
• L'agent lit les schemas et descriptions des tools en se connectant, donc il sait comment les appeler.
• Le MCP se place comme couche adaptee aux agents devant votre API, il ne la remplace pas.
• Pour un cas prive ponctuel, un CLI est peut-etre plus simple; pour un usage partage, un serveur gagne.

Serveurs courants que vous devriez connaitre

Vous avez rarement besoin de construire un serveur depuis zero, parce que l'ecosysteme couvre deja les cas courants. De bonnes premieres connexions sont le serveur filesystem (limite a un dossier, pour que l'agent puisse lire et ecrire des fichiers de projet), le serveur Playwright (pour que l'agent puisse piloter un vrai navigateur pour tester ou scraper) et un serveur de base de donnees pour votre stack. Au-dela, il y a des serveurs pour les issue trackers, les outils de design, le monitoring et la plupart des grands produits SaaS. Mais connectez avec discernement: chaque serveur ajoute ses definitions de tools au contexte de l'agent, donc chacun a un cout continu, et un serveur est du code tiers avec acces a vos systemes, donc verifiez-le comme toute dependance. Notre guide Configurer le MCP dans Claude Code guide l'ajout, le scoping et la verification surs des serveurs.

• Serveur filesystem: lire et ecrire des fichiers dans un dossier limite.
• Serveur Playwright: laisser l'agent piloter un vrai navigateur.
• Serveur de base de donnees: interroger vos donnees directement, plutot que copier des lignes dans le chat.
• Connectez-en peu et verifiez chacun: chaque serveur coute du contexte et est du code tiers.

Pas à pas

1. 01

   Installer le SDK

   Dans un nouveau projet Node.js, installez le SDK TypeScript officiel avec "npm install @modelcontextprotocol/server" (et zod pour les schemas d'input). Un SDK Python, FastMCP, est disponible si vous preferez Python.

2. 02

   Creer le serveur et enregistrer un tool

   Creez un McpServer avec un nom et une version, puis appelez server.registerTool avec un nom de tool, une description et un inputSchema Zod, et renvoyez un tableau content depuis le handler async.

3. 03

   Connecter via un transport

   Pour un usage local, creez un StdioServerTransport et await server.connect(transport). Le host spawne votre fichier et dialogue avec lui via stdin/stdout, donc loggez sur stderr, jamais sur stdout.

4. 04

   Enregistrer le serveur aupres d'un client

   Pointez votre client MCP sur la commande qui execute le serveur. Dans Claude Code: "claude mcp add --transport stdio <nom> -- node server.js". Voir notre guide Configurer le MCP dans Claude Code pour les scopes et la verification.

5. 05

   Verifier et etendre

   Confirmez que l'agent peut voir et appeler votre tool, puis ajoutez d'autres tools, resources et prompts de la meme facon. Passez a Streamable HTTP quand vous voulez heberger le serveur a distance.

Questions fréquemment posées

Continuez à apprendre