Qu'est-ce qu'un serveur MCP ? Guide clair sur les outils, ressources et prompts

Le problème que résolvent les serveurs MCP

Avant MCP, connecter un assistant à un produit signifiait écrire une intégration par paire : un plugin ChatGPT pour votre outil de suivi, une extension séparée pour Cursor, un jeu de fonctions sur mesure pour Claude, et ainsi de suite. Chaque assistant avait son format, et chaque intégration était maintenue par qui s'en souciait assez.

MCP, publié par Anthropic en novembre 2024 et désormais géré comme une spécification ouverte, remplace les paires par un standard. Un produit écrit un serveur. Tout assistant qui parle MCP (Claude, ChatGPT, Cursor, Codex, VS Code et des dizaines d'autres en octobre 2026) peut s'y connecter. L'assistant n'a pas besoin de savoir comment le produit fonctionne en dessous, seulement ce que le serveur dit offrir.

L'analogie qui tient le mieux est celle du port USB. Avant lui, chaque appareil avait besoin de son propre connecteur ; après, n'importe quel appareil pouvait se brancher sur n'importe quel ordinateur. MCP est ce connecteur pour les assistants IA et les systèmes sur lesquels ils agissent.

Les trois choses qu'un serveur propose

La spécification (révision actuelle 2025-11-25) définit trois types de choses qu'un serveur peut exposer. Un serveur n'est pas obligé d'offrir les trois ; beaucoup n'offrent que des outils.

Outils

Un outil est une fonction avec un nom, une description et un JSON Schema qui dit quels arguments elle prend. Le modèle lit les descriptions, décide qu'un outil correspond à la demande, remplit les arguments, et l'application vous demande avant de l'exécuter. Les outils sont la partie de MCP qui permet à un assistant d'agir et pas seulement de répondre.

Notre propre serveur expose 85 outils. Quelques-uns, pour donner le ton : projects_list et project_status lisent l'état d'un produit ; work_create_issue et work_set_issue_status modifient le backlog ; crm_list_deals et crm_move_deal touchent au pipeline ; calendar_find_time cherche un créneau libre entre plusieurs personnes ; people_find retrouve un collègue par son nom. Chacun est marqué lecture ou écriture et nomme le scope de permission dont il a besoin.

Ressources

Une ressource est quelque chose que le modèle peut lire comme contexte : un document, un enregistrement, un fichier. La différence avec un outil tient à qui choisit. Un outil est contrôlé par le modèle, qui décide de l'appeler. Une ressource est contrôlée par l'application : l'app ou la personne l'attache à la conversation, comme on glisse un fichier dans un chat. Les bons serveurs exposent les documents que les gens colleraient sinon à la main.

Prompts

Un prompt est un gabarit que le serveur propose pour une tâche courante, avec des emplacements pour des arguments. Il apparaît dans l'assistant comme une commande ou un élément de menu, la personne le choisit, et le serveur remplit le texte. Ce sont les moins utilisés des trois, et les plus utiles pour transformer les outils d'un serveur en un flux que quelqu'un peut répéter sans réécrire l'instruction à chaque fois.

Comment un assistant découvre un serveur

Le protocole est JSON-RPC 2.0, le même format de requête et de réponse que les serveurs de langage des éditeurs de code. Une connexion se déroule ainsi :

1. Initialiser. Le client envoie initialize avec la version du protocole qu'il prend en charge et ses propres capacités. Le serveur répond avec sa version et ce qu'il offre (outils, ressources, prompts, et s'il peut prévenir le client quand cela change).
2. Lister. Le client appelle tools/list, et généralement resources/list et prompts/list. Le serveur renvoie le nom, la description et le schéma d'entrée de chaque outil. Le modèle sait maintenant ce qu'il peut faire.
3. Appeler. Quand le modèle choisit un outil, le client envoie tools/call avec le nom et les arguments. Le serveur fait le travail et renvoie un résultat : une liste d'éléments de contenu (du texte, en général) et, éventuellement, des données structurées conformes à un schéma de sortie.
4. Notifier. Si la liste d'outils du serveur change, parce qu'une personne a approuvé une nouvelle permission, par exemple, il peut envoyer une notification et le client liste à nouveau.

Un outil qui échoue d'une façon que le modèle devrait connaître, comme une écriture refusée ou un mauvais argument, renvoie un résultat normal avec isError: true et un message. Le modèle lit le message et peut tenter autre chose, au lieu que toute la connexion casse.

Un principe de sécurité est intégré là-dedans : la spécification demande aux applications de traiter comme non fiables les descriptions d'outils d'un serveur en qui elles n'ont pas pleinement confiance, et de garder une personne dans la boucle sur les appels d'outils. Une description d'outil n'est que du texte écrit par le serveur ; un serveur malveillant pourrait en écrire une trompeuse.

Serveurs locaux et distants

Les serveurs existent sous deux formes, et la différence compte quand on en choisit ou en construit un.

Un serveur local tourne sur votre propre machine. L'assistant le lance comme sous-processus et lui parle par l'entrée et la sortie standard (le transport stdio). Il lit généralement ses identifiants dans des variables d'environnement. C'est ainsi que fonctionnaient la plupart des premiers serveurs MCP : un serveur de système de fichiers, un serveur Git, un serveur de base de données pointé vers votre propre Postgres. Bien pour un développeur ; pénible pour une équipe, parce que chaque ordinateur doit avoir le serveur installé, à jour et muni d'une clé.

Un serveur distant tourne sur internet derrière un seul endpoint HTTPS, avec le transport Streamable HTTP, et est partagé par de nombreux utilisateurs. Vous l'ajoutez à l'assistant par URL, vous vous connectez via OAuth dans le navigateur, et le serveur garde séparées les données de chacun. C'est ainsi qu'un produit hébergé devrait proposer MCP, parce que personne ne veut installer quoi que ce soit ni coller une clé d'API dans un fichier de configuration. Le serveur Atrix est distant uniquement, à https://atrix.dev/api/mcp, pour cette raison : un espace de travail est partagé, donc la connexion doit être par personne et révocable.

L'entrée du glossaire sur les serveurs MCP approfondit les transports ; la version courte est que stdio est pour votre machine et Streamable HTTP pour tout ce qui est partagé.

Un vrai appel d'outil, du début à la fin

Voici ce qui se passe quand quelqu'un connecté à notre serveur via Claude Code tape « crée un bug : le bouton d'export de la page factures ne fait rien dans Safari ».

Le modèle lit les descriptions d'outils reçues à tools/list et choisit work_create_issue. L'entrée du glossaire sur les outils MCP décrit la forme générale ; l'appel précis ressemble à ceci :

{
  "method": "tools/call",
  "params": {
    "name": "work_create_issue",
    "arguments": {
      "projectId": "Billing",
      "title": "Le bouton d'export ne fait rien dans Safari (page factures)",
      "priority": "HIGH"
    }
  }
}

Trois choses se passent avant la moindre écriture. Claude Code affiche l'appel et demande à la personne de l'approuver. Le serveur vérifie que le jeton présenté possède le scope work.write. Il vérifie ensuite que la personne derrière le jeton a le droit de créer des tickets dans ce projet ; un jeton ne peut jamais faire plus que la personne qui l'a créé. Si une vérification échoue, le résultat revient avec isError: true et un message nommant le scope manquant, et le modèle dit à la personne quoi ajouter.

Si les trois passent, le ticket est créé et le résultat porte son identifiant :

{
  "content": [{ "type": "text", "text": "Créé BIL-142 : Le bouton d'export ne fait rien dans Safari (page factures)" }],
  "structuredContent": { "issueId": "BIL-142", "href": "/dashboard/projects/billing?issue=BIL-142" }
}

L'appel est aussi audité : quel outil, quelle issue, quel enregistrement, jamais le contenu. Cette trace d'audit est la différence entre un assistant que vous pouvez confier à une équipe et un que vous ne pouvez confier qu'à vous-même.

Notez que « Billing » a été passé comme nom, pas comme identifiant. Un serveur écrit pour des assistants devrait accepter des noms quand il le peut, parce que le modèle a généralement le nom et pas l'id, et devrait refuser clairement, en listant les candidats, quand un nom est ambigu.

Serveur MCP vs API vs plugin

On demande légitimement pourquoi un serveur est nécessaire quand le produit a déjà une API REST. Les trois résolvent des problèmes différents.

Une API est pour les programmes. Un plugin est pour un assistant. Un serveur MCP est une couche mince au-dessus de l'API, façonnée pour qu'un modèle, quel qu'il soit, puisse la lire : des noms et descriptions d'outils entre lesquels un modèle peut choisir, des schémas qu'il peut remplir, des résultats qu'il peut comprendre. En pratique, notre serveur appelle les mêmes fonctions que notre API REST ; il les décrit simplement autrement.

La limite honnête : un modèle qui choisit parmi 85 outils choisit à partir de descriptions, et des descriptions mal écrites mènent à de mauvais appels. Construire un serveur tient moins du protocole, que n'importe quel SDK gère, que du nommage et de la description des outils pour que le modèle choisisse le bon.

Quand une petite équipe devrait en utiliser un

Vous n'avez pas besoin de construire un serveur MCP pour en tirer parti. Le cas courant pour une équipe de cinq à quinze personnes est de connecter un assistant que vous payez déjà aux outils que vous utilisez déjà.

Prenez un serveur quand vous vous surprenez à copier du contexte dans une fenêtre de chat : coller les trois derniers tickets, l'étape du deal d'un client, la page d'exigences. Un assistant connecté lit tout cela lui-même. C'est aussi pertinent quand vous voulez agir depuis l'assistant, créer des tickets ou réserver un créneau, sans changer d'application.

Attendez si le serveur est local uniquement et qu'il faudrait l'installer sur chaque ordinateur, ou s'il demande une clé d'API collée sans scopes ; une clé qui peut tout faire, stockée dans un fichier de configuration sur cinq machines, est un passif. Et souvenez-vous que l'assistant ne fait toujours que ce que ses outils permettent. Notre serveur, par exemple, n'a aucun outil qui lit un salaire, par conception.

La page de la fonctionnalité MCP liste les assistants qui se connectent à Atrix aujourd'hui, et la vue d'ensemble développeurs donne la configuration de chacun.

FAQ

Que signifie MCP ?

Model Context Protocol. C'est une spécification ouverte, publiée par Anthropic en novembre 2024, qui définit comment les applications IA se connectent à des systèmes externes via des serveurs qui exposent des outils, des ressources et des prompts. La révision actuelle est 2025-11-25.

Un serveur MCP est-il la même chose qu'une API ?

Non. Une API est une interface pour les programmes, documentée pour les développeurs. Un serveur MCP est une couche au-dessus qui se décrit elle-même à un modèle de langage dans un format standard, pour que le modèle découvre les outils avec tools/list et les appelle avec tools/call sans que personne n'écrive de glu sur mesure. La plupart des serveurs appellent une API en dessous.

Faut-il savoir coder pour utiliser un serveur MCP ?

Pas pour en utiliser un. Les serveurs distants s'ajoutent à un assistant par URL et s'autorisent dans le navigateur ; les serveurs locaux s'installent en général en une commande. Construire son propre serveur demande du code, mais les SDK officiels (TypeScript, Python et d'autres) gèrent le protocole.

Est-il sûr de connecter un assistant aux données de mon entreprise via MCP ?

Cela dépend du serveur. Cherchez une connexion par personne avec des scopes que vous choisissez, des permissions résolues à chaque appel pour que l'assistant ne puisse jamais faire plus que vous, un journal d'audit et la possibilité de révoquer l'accès. Évitez les serveurs qui veulent une unique clé toute-puissante collée dans un fichier.

Quelle est la différence entre un outil et une ressource ?

Un outil est une fonction que le modèle décide d'appeler, avec le consentement de l'utilisateur, et qui peut modifier des données. Une ressource est une donnée que l'application ou l'utilisateur attache pour que le modèle la lise, et elle ne peut rien modifier.

Quels assistants peuvent se connecter à des serveurs MCP ?

En octobre 2026 : Claude (web, bureau et Claude Code), ChatGPT, Cursor, OpenAI Codex, VS Code avec GitHub Copilot et bien d'autres. La prise en charge des serveurs distants avec OAuth varie selon l'assistant ; vérifiez les réglages de connecteurs de chacun.

Prochaine étape

Si vous voulez voir un serveur de l'intérieur, la vue d'ensemble développeurs explique comment connecter Claude Code, ChatGPT ou Cursor au serveur Atrix, avec la commande exacte pour chacun et la liste de tous les outils avec leur scope. La page de la fonctionnalité MCP en est la version non technique. Pour le vocabulaire, le glossaire a des entrées sur les serveurs MCP et les outils MCP.