Serveurs MCP : ce qu'ils sont et ce qu'ils coûtent

Qu'est-ce qu'un serveur MCP ?

Un serveur MCP est un programme qui expose des outils — des fonctions qu'un modèle peut appeler — via le Model Context Protocol, pour qu'un agent puisse interroger votre base de données, appeler votre API ou piloter un navigateur sans que personne n'écrive de code de liaison spécifique à ce couple. Il tourne soit comme processus local sur votre machine, soit comme endpoint HTTP distant, et tout agent parlant MCP peut s'y connecter. La raison d'être du protocole est combinatoire. Avant lui, chaque agent avait besoin d'une intégration sur mesure avec chaque outil : N agents × M outils, tous écrits à la main et cassant indépendamment. MCP transforme ça en N + M — un serveur s'écrit une fois et fonctionne avec tout ce qui parle le protocole. C'est de la bonne ingénierie, et ça explique la vitesse à laquelle l'écosystème a grossi. Je construis des outils de réduction de tokens, donc mon angle est plus étroit que la plupart des articles sur le sujet : ce qu'un serveur coûte une fois branché. Cette partie n'apparaît quasiment jamais dans les instructions d'installation, et c'est celle qui revient sur votre facture tous les mois.

Comment fonctionne réellement un serveur MCP ?

L'agent se connecte, demande quels outils sont disponibles, et le serveur répond par un manifeste — une liste lisible par machine de chaque outil, ses paramètres et sa description. À partir de là, ce manifeste voyage avec votre conversation. Le déroulé, dans l'ordre :

Connexion. En stdio pour un processus local, en HTTP pour un endpoint distant. (SSE fonctionne encore, mais HTTP est désormais le transport distant recommandé.)
Découverte. L'agent demande la liste des outils. Le serveur renvoie les schémas qui les décrivent.
Annonce. Ces schémas sont placés dans la fenêtre de contexte du modèle — car un modèle ne peut pas appeler un outil dont on ne lui a pas dit qu'il existe.
Appel. Quand le modèle juge qu'un outil convient, il émet un appel, le serveur l'exécute, et le résultat revient dans la conversation.

L'étape 3 est celle qui compte financièrement, et c'est celle que les guides de démarrage sautent. Le manifeste n'est pas envoyé une fois à la connexion puis mémorisé — il fait partie de la charge utile que le modèle lit à chaque tour, puisque chaque tour renvoie tout le contexte. Vingt tours, vingt copies. Au-delà des outils, un serveur peut aussi exposer des resources que vous référencez directement (une mention @ pointant un fichier, une issue, un schéma) et des prompts qui apparaissent comme slash commands. Le support varie — chaque serveur choisit ce qu'il implémente — mais les resources méritent d'être connues : tirer une chose précise coûte moins cher que décrire une recherche.

Que vous coûte un serveur MCP ?

Les définitions d'outils de chaque serveur connecté sont renvoyées au modèle à chaque tour : un serveur que vous n'appelez jamais vous facture tant qu'il reste branché. C'est structurel, pas un bug — c'est ainsi que le modèle sait que les outils existent. Ici je dois être direct, parce que c'est le point où la plupart des articles se mettent à inventer des chiffres : presque aucun éditeur ne publie ce que coûte son manifeste. Des estimations tierces circulent largement pour les serveurs populaires et se contredisent de plusieurs dizaines de milliers de tokens — ce qui signale des mesures sur des versions différentes dans des conditions différentes, pas un fait établi. Je ne vais pas les répéter comme si elles en étaient. Ce qu'on peut obtenir, c'est l'ordre de grandeur, à partir de ce que les éditeurs publient réellement. Le serveur MCP officiel de GitHub embarque 20 toolsets et expose 56 outils en lecture seule, avant même de compter ceux en écriture. Chacun de ces schémas est annoncé au modèle à chaque tour tant que vous ne restreignez pas l'ensemble. Pas besoin d'un chiffre en tokens pour voir qu'un manifeste de cette taille, renvoyé sur trente tours, n'est pas une erreur d'arrondi — et GitHub, à son crédit, permet de le réduire (voir plus bas). Donc mesurez plutôt que de deviner. Deux lectures disent presque tout :

Le nombre d'outils. La taille du manifeste croît avec le nombre d'outils et la verbosité de leurs schémas. Un serveur qui en expose 40 ne joue pas dans la même catégorie qu'un qui en expose 4.
Le contexte avant de taper. Ouvrez une session fraîche, regardez ce qui occupe déjà la fenêtre, branchez le serveur, redémarrez, comparez. La différence est son prix réel sur votre installation, dans sa version actuelle.

Cette mesure prend deux minutes et vaut mieux que n'importe quel chiffre que je pourrais citer, puisque les manifestes changent d'une version à l'autre.

Les serveurs MCP en valent-ils la peine ?

Souvent oui — mais la réponse honnête est que cela dépend du rapport entre ce qu'un serveur vous économise et ce qu'il vous facture à chaque tour. Un serveur mérite sa place quand il remplace un travail qui coûterait davantage. Un serveur de base de données qui répond à une question de schéma en un appel bat un agent qui lit six fichiers de migration pour déduire la même chose. Un serveur navigateur qui récupère un contenu de page propre bat un agent qui avale du HTML brut. Dans les deux cas, le coût du manifeste est remboursé par les tokens non dépensés ailleurs. Un serveur perd sa place quand il dort. L'essai ne coûte rien ; l'oubli coûte à chaque tour, en silence, indéfiniment. C'est le gaspillage le plus fréquent que je constate : on branche un serveur pour tester, ça marche, on passe à autre chose, et il taxe discrètement toutes les sessions pendant des mois. Deux habitudes règlent l'essentiel. Garder les serveurs cantonnés au projet qui en a besoin plutôt qu'installés globalement, et auditer de temps en temps ce qui est branché. Si vous n'avez pas appelé un serveur cette semaine, il ne gagne pas son manifeste.

Peut-on garder les outils sans payer ceux qui dorment ?

Oui, en différant le manifeste : envoyer les définitions d'outils quand un outil est réellement appelé, au lieu de les précharger à chaque tour. C'est le lazy MCP loading, un correctif structurel plutôt qu'une discipline à se rappeler. La version manuelle relève de l'hygiène : brancher ce dont la session a besoin, débrancher le reste, préférer la portée projet à la portée globale. Ça marche, et ça suppose de le faire tous les jours — exactement le type de constance qui s'effrite sous la pression. Tokenade comble cet écart en chargeant les définitions d'outils MCP de façon paresseuse dans Claude Code, Cursor, Codex, Copilot et Windsurf, puisque le problème du manifeste est identique partout. Il compresse aussi ce que renvoient les outils bavards, l'autre moitié de la facture MCP — un outil qui répond par 8 000 tokens de JSON vous coûte aussi à tous les tours suivants. C'est source-available sous licence MIT : vous pouvez lire exactement ce qu'il fait à votre contexte avant de lui confier une session.

Comment choisir les serveurs à faire tourner ?

Partez de la tâche, pas de la liste. L'écosystème est vaste et l'essentiel en est hors sujet pour un projet donné : la bonne question est « qu'est-ce que ce dépôt a besoin d'atteindre ? » et non « qu'est-ce qui est populaire ? ». Une heuristique courte qui tient dans le temps :

Préférer peu d'outils à beaucoup. Dix outils concis peuvent coûter moins que quatre aux schémas tentaculaires, mais en première approximation, une surface réduite est une facture réduite et un risque moindre que le modèle choisisse le mauvais outil.
Préférer les resources aux outils pour les lectures simples. Référencer une resource tire une chose précise ; un appel d'outil décrit une recherche.
Préférer la portée projet. Un serveur qui vous suit dans tous les dépôts paie un loyer dans des projets qui ne s'en servent jamais.
Réauditer après chaque ajout. Le bon moment pour lancer /context est juste après avoir branché quelque chose, tant que l'avant/après a encore du sens.

Pour la sélection propre à Claude Code, les meilleurs serveurs MCP Claude Code les classent par valeur rapportée à leur coût réel, et la configuration MCP de Claude Code couvre la mécanique de connexion — scopes, .mcp.json, secrets et états de connexion.

Ce qui tourne mal (anti-patterns)

Installer les serveurs globalement par défaut. C'est le choix pratique et le choix coûteux. Chaque projet paie pour chaque outil que vous avez branché un jour. Brancher un serveur « pour tester » et ne jamais le débrancher. Le coût est récurrent et invisible ; aucune ligne de facture ne dit « le serveur que vous avez oublié ». Se fier aux tailles de manifestes annoncées par des tiers. Elles se contredisent parce qu'elles mesurent des versions différentes. Mesurez la vôtre : deux minutes. Juger un serveur au seul nombre d'outils. C'est un indice, pas une mesure. Des schémas verbeux sur peu d'outils peuvent peser plus lourd que des schémas concis sur beaucoup. Prendre une grande fenêtre de contexte pour une permission. Une fenêtre d'un million de tokens ne rend pas les manifestes gratuits ; elle supprime juste le garde-fou qui vous tenait propre. Vous payez toujours ce que vous y mettez.

Foire aux questions

Qu'est-ce qu'un serveur MCP, simplement ?

C'est un adaptateur. D'un côté il parle le Model Context Protocol, que tout agent IA compatible comprend ; de l'autre il fait quelque chose d'utile — interroger une base, appeler une API, piloter un navigateur. Comme la face agent est standardisée, un seul serveur fonctionne avec tous les agents parlant MCP, au lieu d'exiger une intégration sur mesure par couple.

Faut-il un serveur MCP pour utiliser un agent de code IA ?

Non. Les agents fonctionnent très bien avec leurs capacités natives — lire des fichiers, lancer des commandes, éditer du code. Les serveurs MCP étendent leur portée à des systèmes qu'ils ne peuvent pas atteindre autrement. C'est un ajout avec un coût récurrent, pas un prérequis, et démarrer sans aucun est un défaut parfaitement raisonnable.

Les serveurs MCP sont-ils sûrs ?

Ils tournent avec les permissions que vous leur donnez : un serveur MCP est du code que vous choisissez de faire tourner, comme n'importe quelle dépendance. Les serveurs locaux s'exécutent sur votre machine avec vos accès ; les distants reçoivent ce que vous leur envoyez. Les configurations de portée projet sont généralement soumises à une approbation explicite pour cette raison précise — récupérer une branche ne devrait pas brancher un nouveau serveur à votre insu.

Fonctionnent-ils avec d'autres agents que Claude ?

Oui, c'est tout l'intérêt d'un protocole partagé. Un serveur écrit pour un hôte fonctionne généralement ailleurs, même si les hôtes diffèrent par leur format de configuration et par les parties optionnelles de la spécification qu'ils implémentent (resources et prompts en particulier). Le coût du manifeste par tour se reporte à l'identique, d'où le caractère agnostique des conseils de réduction de tokens des agents de code IA.

Combien de serveurs MCP est-ce trop ?

Il n'y a pas de nombre fixe, puisque le coût dépend de la taille des schémas et non du nombre de serveurs. Le test pratique : avez-vous appelé chacun récemment ? Si un serveur n'a pas servi cette semaine, il vous facture chaque tour une capacité que vous n'utilisez pas — débranchez-le et rebranchez quand le besoin revient. La reconnexion prend quelques secondes et ne perd rien.

Quelle différence entre tools, resources et prompts MCP ?

Les tools sont des fonctions que le modèle appelle pour faire quelque chose. Les resources sont des données qu'il référence directement, en général par une mention @, pour lire quelque chose de précis. Les prompts sont des workflows pré-écrits que le serveur expose en slash commands. Les tools occupent toujours de la place dans le manifeste ; resources et prompts sont des capacités optionnelles que tous les serveurs n'implémentent pas.

À voir aussi :

MCP (Model Context Protocol) — le protocole lui-même, en une page.
Serveur MCP GitHub : installation et coût réel — le serveur courant le plus lourd, et comment n'en charger qu'une tranche.
Claude Code MCP : comment le configurer — transports, scopes, .mcp.json, secrets.
Meilleurs serveurs MCP Claude Code, classés au coût réel — lesquels méritent leur surcoût.
Lazy MCP loading — le correctif structurel des manifestes inactifs.
Utilisation des outils MCP économe en tokens — réduire le coût des schémas et des sorties.