Un serveur MCP, c'est quoi exactement ?

Un modèle de langage, seul, ne peut pas lire vos fichiers, interroger votre base de données, ni se souvenir d'hier. Il produit du texte. Tout le reste — chaque action, chaque consultation — arrive parce qu'un programme extérieur au modèle est allé le faire.

Avant le Model Context Protocol, chacune de ces connexions était du sur-mesure. Pour que Claude lise votre Notion et que ChatGPT lise votre Notion, il fallait écrire deux intégrations contre deux systèmes de plugins différents, et aucune ne survivait à la version suivante de l'éditeur. MCP est l'accord qui met fin à ça : un serveur, n'importe quel client qui parle le protocole.

La forme générale

Il y a trois parties. L'hôte, c'est l'application que vous utilisez vraiment : un assistant de bureau, un IDE, une interface de chat. Le client vit dans l'hôte et gère une connexion. Le serveur est la chose que vous, ou quelqu'un d'autre, avez écrite, et c'est lui qui détient la capacité : accès à un système de fichiers, à une instance Postgres, à un agenda, à une mémoire.

Ils parlent JSON-RPC 2.0. Ce n'est pas un détail sur lequel s'attarder, mais il vaut la peine de le savoir : cela signifie que l'ensemble est inspectable. Vous pouvez lire les messages. Il n'y a pas de couche magique où le modèle « décide » quelque chose que vous ne verriez pas.

La séquence est volontairement terne : le client se connecte, les deux côtés échangent leurs capacités, le client demande ce que le serveur propose, et à partir de là le modèle peut réclamer l'une de ces choses par son nom. Le serveur exécute. Le résultat revient sous forme de texte que le modèle lit.

Les trois choses qu'un serveur peut exposer

À peu près tous les serveurs que vous croiserez utilisent la première et ignorent les deux autres. Les trois méritent d'être comprises, parce que la différence porte sur qui décide.

• Les outils (tools) — des fonctions que le modèle peut appeler de sa propre initiative. `search_memory`, `create_issue`, `run_query`. Le modèle lit votre description de l'outil et décide quand elle s'applique. C'est là qu'est la puissance, et c'est là qu'est le risque.
• Les ressources (resources) — des données que l'*hôte* lit et place dans le contexte. Un fichier, un enregistrement, un document. Ce n'est pas le modèle qui déclenche, c'est l'application. Moins d'autonomie, plus de prévisibilité.
• Les prompts — des modèles réutilisables que l'utilisateur choisit délibérément. L'équivalent le plus proche d'une commande slash.

Une conséquence que l'on découvre tard : la description d'un outil n'est pas de la documentation, ce sont des instructions au modèle. Si un outil n'est jamais appelé alors qu'il devrait l'être, le correctif n'est généralement pas dans le code — c'est que la description n'a pas su dire au modèle à quelle situation elle appartient. Nous avons réécrit les nôtres pour exactement cette raison, et le taux d'appel a changé immédiatement.

Local ou distant : le choix qui compte

Deux transports existent, et l'arbitrage entre les deux détermine l'essentiel de ce à quoi votre installation ressemblera.

stdio lance le serveur comme un processus fils sur votre propre machine. L'hôte exécute une commande, lui parle via l'entrée et la sortie standard, et le tue en quittant. Rien ne sort de l'appareil. C'est la bonne réponse pour tout ce qui touche à des fichiers locaux, et c'est pourquoi les serveurs filesystem et git fonctionnent ainsi. Le prix : il n'existe que sur cette machine. Votre ordinateur portable et votre téléphone ne le partagent pas, et le serveur n'est vivant que pendant que l'application l'est.

HTTP fait tourner le serveur quelque part d'accessible. L'hôte se connecte par le réseau, en s'authentifiant généralement en OAuth 2.0. Dès lors, tous les appareils voient le même serveur, et un service hébergé peut en être un. Le prix : vous faites confiance à celui qui l'exploite, et vous devriez savoir où il tourne — ce qui est le sujet d'un autre article ici.

Pour la mémoire en particulier, l'arbitrage n'est pas serré. Une mémoire qui n'existe que sur un seul portable est un carnet. Tout l'intérêt de la chose, c'est que l'assistant que vous ouvrez sur un autre appareil sache déjà.

Ce qu'un serveur peut vous faire

Un serveur MCP est du code auquel vous avez accordé le droit d'agir. Traitez-le comme tel.

Un serveur local tourne avec les permissions de votre utilisateur — il peut lire tout ce que vous pouvez lire. Un serveur distant reçoit tout ce que le modèle lui envoie, ce qui, avec le temps, fait beaucoup sur vous. Et une description d'outil est un texte adressé au modèle : un serveur peut donc influencer le comportement de l'assistant, pas seulement lui répondre.

Quatre questions à se poser avant d'en installer un :

1. Puis-je lire le code source, ou est-ce un binaire fourni par un inconnu ?
2. Quelles permissions détient-il — un seul dossier, ou tout mon répertoire personnel ?
3. S'il est distant : qui l'exploite, dans quel pays, et puis-je supprimer mes données ?
4. Écrit-il, ou se contente-t-il de lire ? Un serveur en lecture seule a un rayon d'impact bien plus petit.

L'écosystème est jeune et majoritairement construit par des individus de bonne foi. Ce n'est pas la même chose qu'audité. Le registre officiel et les listes communautaires sont des outils de découverte, pas des garanties.

Quand vous devriez en écrire un

La barre est basse : un serveur qui expose deux outils tient dans un fichier court, en Python ou en TypeScript, et les SDK gèrent le protocole. La vraie question est de savoir si un outil est la bonne forme pour ce que vous voulez.

C'est généralement le cas quand l'assistant doit *agir* sur un système vivant, ou récupérer quelque chose qui change. Ce ne l'est généralement pas quand vous avez seulement besoin que le modèle connaisse un corpus de texte fixe : le coller, ou l'exposer comme ressource, est plus simple et plus fiable que d'apprendre au modèle à aller le demander.

Si vous voulez les détails, la spécification est courte et lisible, ce qui est rare et dit quelque chose de bon sur le projet.

Pryzm est un serveur MCP distant dont l'unique métier est la mémoire : il stocke ce que vous lui dites et en ressort les parties pertinentes plus tard, dans n'importe quel client qui parle le protocole. Si vous préférez héberger vous-même, plusieurs serveurs de mémoire libres et auto-hébergeables existent, et nous les listons dans notre comparatif.