Un serveur MCP est un petit programme qui donne à une application d’IA un accès contrôlé aux fichiers, aux bases de données et aux outils grâce au Model Context Protocol. Cet article définit le terme, suit une requête étape par étape, présente de vrais exemples et se termine par un court serveur TypeScript que vous pouvez lancer dès aujourd’hui.
Demandez à un assistant d’IA de résumer les ventes du dernier trimestre, et il vous répondra poliment qu’il ne peut pas voir votre tableur. Le modèle est brillant, mais il se trouve dans une boîte sans portes. Un serveur MCP est cette porte. C’est un petit programme qui expose une capacité précise, comme lire des fichiers, interroger une base de données ou générer une image, à toute application d’IA qui parle le Model Context Protocol. Vous écrivez le serveur une seule fois, et chaque application compatible peut l’utiliser sans code de liaison sur mesure.
Cet article explique ce qu’est un serveur MCP, comment une requête voyage de votre fenêtre de discussion jusqu’à l’outil et retour, quels serveurs les gens utilisent aujourd’hui, où se situent les risques de sécurité, et comment en construire un qui fonctionne en une vingtaine de lignes de TypeScript.
MCP signifie Model Context Protocol, un standard ouvert qu’Anthropic a publié en novembre 2024. Un protocole est simplement une manière convenue de communiquer. Un serveur MCP est tout programme qui suit ces règles côté fournisseur : il annonce ce qu’il sait faire, attend les requêtes et renvoie les résultats dans un format prévisible. Des produits d’Anthropic, d’OpenAI, de Google et de Microsoft prennent désormais en charge MCP, et des milliers de serveurs communautaires existent, pour tout, des dépôts Git aux agendas.
Le mot serveur prête à confusion. Un serveur MCP n’a pas besoin de vivre dans un centre de données. La plupart tournent sur votre propre ordinateur, comme un processus en arrière-plan qui démarre avec votre application d’IA. D’autres fonctionnent à distance, derrière une adresse web, comme n’importe quel site.
Imaginez un vieux central téléphonique. Les appelants n’ont pas besoin de savoir comment chaque maison est câblée. Ils indiquent à la standardiste la personne qu’ils veulent, et elle branche le bon cordon dans la bonne prise. MCP joue le rôle de la standardiste entre une application d’IA et le monde extérieur. L’application dit je dois lire ce fichier ou je dois exécuter cette requête, et le protocole achemine la demande vers un serveur qui sait comment faire.
💡 Définition rapide : Un serveur MCP est un programme qui liste les outils, données et modèles de prompts qu’il propose, et permet à une application d’IA de les appeler grâce à un format de message standard unique.
L’analogie la plus populaire est celle de l’USB-C. Avant lui, chaque appareil avait sa propre prise et chaque ordinateur portable exigeait un tiroir plein d’adaptateurs. Avant MCP, chaque application d’IA avait besoin d’un connecteur sur mesure pour chaque service : un pour Slack dans cet assistant, un autre pour Slack dans celui-là. Comptez les combinaisons. Cinq applications et dix services représentaient cinquante intégrations distinctes. Avec MCP, chaque application implémente le côté client une fois et chaque service implémente un serveur une fois, si bien que quinze travaux remplacent cinquante.
Trois rôles apparaissent dans toute configuration MCP, et bien les distinguer dissipe l’essentiel de la confusion.
| Rôle | Ce que c’est | Exemple |
|---|---|---|
| Hôte | L’application d’IA avec laquelle l’utilisateur discute | Claude Desktop, Cursor, VS Code |
| Client | Un connecteur interne à l’hôte qui maintient une connexion avec un seul serveur | Créé automatiquement par l’hôte |
| Serveur | Le programme qui expose des outils, des données ou des prompts | Un serveur de système de fichiers, un serveur de base de données |
L’hôte crée un client par serveur. Si vous connectez cinq serveurs, votre application fait tourner cinq clients, chacun avec une ligne privée vers son propre serveur. Les messages circulent au format JSON-RPC 2.0, un format léger de requête et de réponse utilisé depuis des années. Rien d’exotique.
Voici le parcours d’une seule question, quelles factures sont en retard ?, à travers un hôte connecté à un serveur de comptabilité :
initialize. Le client et le serveur s’accordent sur une version du protocole et échangent leurs capacités.tools/list. Le serveur répond avec le nom de chaque outil, une description simple et un JSON Schema pour les entrées.list_overdue_invoices est la bonne démarche.tools/call avec le nom de l’outil et les arguments. Le serveur fait le vrai travail, par exemple l’exécution d’une requête SQL.L’appel de l’étape 5 est un petit message JSON :
{
"jsonrpc": "2.0",
"id": 7,
"method": "tools/call",
"params": {
"name": "list_overdue_invoices",
"arguments": { "days_overdue": 30 }
}
}
Le modèle ne touche jamais à votre base de données. Il produit seulement une requête. Le serveur détient les identifiants et effectue le travail, ce qui explique précisément pourquoi les serveurs sont le bon endroit pour appliquer des limites.
Un transport est le canal qui transporte ces messages JSON. MCP en définit deux standards.
| Transport | Lieu d’exécution du serveur | Idéal pour | Compromis |
|---|---|---|---|
| stdio | Sur votre machine, lancé par l’hôte comme processus enfant | Outils personnels, accès aux fichiers, développement | Un seul utilisateur, doit être installé localement |
| Streamable HTTP | À une adresse web, locale ou distante | Serveurs partagés d’équipe, produits hébergés | Nécessite une authentification et un hébergement |
Les serveurs qui utilisent stdio communiquent par l’entrée et la sortie standard, il n’y a donc aucun port réseau à attaquer. Les serveurs Streamable HTTP peuvent servir de nombreux utilisateurs à la fois, c’est pourquoi les éditeurs de logiciels les publient. Certains tutoriels plus anciens mentionnent un transport HTTP+SSE. La spécification actuelle l’a remplacé par Streamable HTTP.
Un serveur MCP expose jusqu’à trois types de briques.
| Primitive | Qui la contrôle | Ce qu’elle fait | Exemple |
|---|---|---|---|
| Outils | Le modèle décide quand les appeler | Effectuent des actions ou des calculs | Envoyer un e-mail, exécuter une requête, générer une image |
| Ressources | L’application décide ce qu’elle joint | Fournissent des données en lecture seule comme contexte | Un fichier, une ligne de base de données, un journal |
| Prompts | L’utilisateur les choisit | Modèles d’instructions réutilisables | « Relisez cette pull request » |
Les outils attirent presque toute l’attention, car ils permettent à une IA d’agir. Les ressources sont plus discrètes mais tout aussi utiles : elles alimentent la conversation en contexte sans appel d’outil. Les prompts fonctionnent comme des commandes slash qu’un serveur livre avec lui-même.
Le modèle choisit les outils en lisant leurs noms et leurs descriptions, rien d’autre. Un outil nommé run avec la description « fait des trucs » sera mal utilisé ou ignoré. Un outil nommé search_invoices avec la description « Trouve des factures par nom de client, statut ou plage de dates. Renvoie jusqu’à 20 résultats. » sera sélectionné au bon moment.
Une bonne conception d’outil tient en quatre réflexes :
create_ticket ou list_branches.💡 Astuce : Si un assistant continue de choisir le mauvais outil, réécrivez la description avant de toucher au code. En pratique, cela règle la plupart des confusions.
Le moyen le plus rapide de saisir l’idée est de regarder ce que les gens font réellement tourner.
Le serveur de système de fichiers de référence permet à un assistant de lire, rechercher et modifier des fichiers dans les dossiers que vous choisissez. Pointez-le vers un répertoire de projet et demandez tous les commentaires TODO, regroupés par fichier. Le serveur ne peut atteindre que les dossiers que vous avez listés, donc l’assistant travaille à l’intérieur d’une clôture que vous avez tracée.
Les serveurs de bases de données exposent un outil de requête, et parfois la structure des tables sous forme de ressource. Demandez quels trois clients ont le plus dépensé en septembre, le modèle écrit le SQL, le serveur l’exécute et les lignes reviennent. Beaucoup d’équipes les configurent volontairement en lecture seule. Les serveurs de recherche et de web fonctionnent de la même façon, en donnant au modèle des pages fraîches au lieu de données d’entraînement périmées. D’autres serveurs populaires connectent GitHub, Slack, Google Drive, Notion, Postgres et l’automatisation de navigateur.
La génération est le domaine où MCP prend une dimension visuelle. Un serveur d’images expose un outil generate_image. L’assistant rédige le prompt, le serveur appelle un modèle, et une URL de fichier apparaît dans la discussion. La vidéo fonctionne de la même façon, avec une différence : les clips prennent plus de temps, donc le serveur lance une tâche et l’assistant en vérifie l’avancement jusqu’à la fin.
PicassoIA repose sur ce modèle. Son API pour développeurs se trouve à https://api.picassoia.com/v1 et utilise un token Bearer qui commence par pia_sk_. Les requêtes suivent le style Replicate : créer une prédiction, l’interroger jusqu’à sa fin, puis récupérer le résultat. Chaque compte peut exécuter 5 prédictions simultanément. Les mêmes quatre modèles sont accessibles via l’API et via le connecteur MCP de PicassoIA :
Les connexions MCP se gèrent depuis la page MCP de votre compte PicassoIA, et la page tarifs détaille ce que chaque forfait inclut. Si vous préférez réaliser vos clips vous-même plutôt que par un assistant, des modèles comme Seedance 2.0 et Veo 3.1 sont à un clic.
Un dernier exemple, plus proche de nous. Un serveur de publication de blog peut exposer quatre outils : générer une image, vérifier si un slug d’URL est libre, lister les modèles d’IA disponibles et enregistrer l’article final dans une base de données. Un assistant qui reçoit un sujet appelle ces outils dans l’ordre, relance toute image qui échoue et stocke le résultat. Personne n’a écrit de « robot rédacteur ». Le modèle avait simplement les bons outils et une mission claire.
Un serveur MCP enveloppe généralement une API ordinaire, alors pourquoi ajouter une couche ? Parce que le lecteur est différent. Une API REST est écrite pour des développeurs qui lisent la documentation. Un serveur MCP est écrit pour un modèle qui doit lire cette documentation à l’exécution.
| REST API | Function calling | Serveur MCP | |
|---|---|---|---|
| Conçu pour | Développeurs | Le modèle d’une seule application | Toute application d’IA compatible |
| Trouver les outils | Documentation écrite pour les humains | Outils codés en dur dans chaque application | Une requête tools/list en direct |
| Réutilisation | Chaque application écrit son propre client | Chaque application redéclare les fonctions | Un seul serveur, plusieurs hôtes |
| Mise en place type | Appels HTTP dans le code | Un schéma JSON dans chaque requête | Une entrée de configuration dans l’hôte |
MCP ne remplace pas l’appel de fonctions. L’hôte traduit la liste d’outils du serveur dans le format d’appel de fonctions que le modèle connaît déjà. MCP standardise seulement l’origine de cette liste.
💡 Règle empirique : Vous construisez une application avec quelques fonctions privées ? L’appel de fonctions classique suffit. Vous voulez la même capacité dans plusieurs assistants, ou permettre à vos collègues de la brancher ? Écrivez un serveur MCP.
Un serveur MCP est du code qu’une IA peut déclencher, souvent avec de vrais identifiants en arrière-plan. Traitez-le comme tout autre logiciel qui touche à vos comptes. Cinq questions permettent de repérer la plupart des problèmes :
⚠️ Attention : Une description d’outil est un texte auquel le modèle fait confiance. Un serveur malveillant peut y dissimuler des instructions. Ne connectez que des serveurs que vous accepteriez d’installer comme logiciels.
Construire un serveur demande moins de travail que la plupart des gens ne l’imaginent. Des SDK officiels existent pour TypeScript, Python, Java, C# et plusieurs autres langages. Les trois mêmes étapes s’appliquent partout : créer un serveur, enregistrer un outil, connecter un transport.
Cet exemple enregistre un outil qui compte les mots et le sert via stdio. Enregistrez-le sous forme de module ES.
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: "word-counter", version: "1.0.0" });
server.registerTool(
"count_words",
{
description: "Count the words in a piece of text. Returns a single number.",
inputSchema: { text: z.string() },
},
async ({ text }) => ({
content: [
{ type: "text", text: String(text.trim().split(/\s+/).filter(Boolean).length) },
],
})
);
await server.connect(new StdioServerTransport());
Compilez-le, puis ajoutez une entrée dans le fichier de configuration de votre hôte : un nom, la commande node et le chemin vers le fichier compilé. Redémarrez l’hôte et count_words apparaît dans sa liste d’outils. Demandez « combien de mots contient ce paragraphe ? » et l’assistant appelle votre code au lieu de deviner.
Avant d’incriminer le modèle, testez le serveur seul. Le MCP Inspector officiel (npx @modelcontextprotocol/inspector node build/index.js) ouvre une page de navigateur où vous pouvez lister les outils, renseigner les arguments et lire les réponses brutes. Si cela fonctionne là, le problème se situe dans la configuration de l’hôte ou dans la description de l’outil.
Les serveurs MCP parlent surtout en texte, pourtant beaucoup de flux de travail se terminent par une image ou un clip. Un bon ordre de travail consiste à esquisser l’idée avec un modèle de langage, puis à la transformer en visuels. PicassoIA Image gère les photographies, PicassoIA Image Editor Pro les retouche et les remodèle, et PicassoIA Video anime le résultat.
Un modèle qui gère l’usage d’outils et le code fait un partenaire solide pour construire le serveur ci-dessus. Voici le chemin rapide avec Claude Sonnet 5 sur PicassoIA :
low, est rapide et économique. Passez à high ou max lorsqu’une tâche s’étend sur plusieurs fichiers ou cache un bogue délicat.D’autres modèles de langage valent un test côte à côte : GPT 5.6 Terra pour un texte prêt pour la production, Gemini 3.5 Flash pour des réponses rapides, et Kimi K2.6 pour les tâches de type agent.
Vous savez maintenant ce que fait un serveur MCP, comment une requête le traverse et où se cachent les risques. Le moyen le plus rapide de saisir l’idée est d’utiliser un outil qui renvoie quelque chose de visible. Ouvrez PicassoIA, décrivez une scène en une seule phrase et générez-la. Puis lancez le même prompt sur un second modèle et comparez les résultats. Des outils petits et interchangeables sont l’habitude que MCP récompense, et une première image prend moins d’une minute. Essayez dès maintenant avec PicassoIA et voyez où mène votre prompt.
Choisissez votre langue
