Le mois dernier, j'ai regardé une équipe passer neuf jours à construire un serveur MCP pour récupérer des données météo. Neuf jours. L'agent aurait pu appeler l'API avec un simple curl et une définition d'outil en une ligne. Mais MCP était la chose brillante du moment, alors MCP ce fut.
Laissez-moi dire la partie silencieuse à voix haute : vous devriez arrêter de construire des serveurs MCP pour tout et n'importe quoi. Le Model Context Protocol est genuinement bon. Il est aussi sauvagement sur-appliqué par des gens qui ont entendu « standard » et ont supposé « obligatoire ».
À quoi MCP sert vraiment
MCP résout un vrai problème : vous avez une capacité que vous voulez exposer à plusieurs agents, sur plusieurs clients, avec une interface cohérente. Pensez à une base de données que toute votre organisation interroge. Un design system. Un index de recherche interne que douze outils différents doivent interroger. Construisez le serveur une fois, et Claude Desktop, Cursor, et votre propre harnais custom lui parlent tous de la même façon. C'est ça l'avantage. La réutilisation entre clients.
C'est tout. C'est tout l'argument. Si vous n'obtenez pas de réutilisation entre plusieurs clients ou plusieurs agents, vous payez la taxe du protocole pour rien.
La taxe dont personne ne parle
Chaque serveur MCP est un processus. Il a un cycle de vie. Il a un transport — stdio ou SSE — qui peut se bloquer, se déconnecter, ou silencieusement arrêter de répondre. Il charge des définitions d'outils dans votre fenêtre de contexte que vous les appeliez ou non. J'ai vu un seul serveur MCP bavard consommer 4 000 tokens de contexte avant que le modèle ait lu un mot de la tâche réelle.
Et vous devez le maintenir. Le versionner. Gérer l'authentification à l'intérieur. Le déboguer quand l'agent dit « l'outil ne répond pas » et que vous n'avez aucune idée si c'est le serveur, le transport, ou le modèle qui hallucine un nom d'outil.
Comparez ça à une simple fonction que l'agent appelle directement, ou une commande CLI qu'il exécute via Bash. Quand mon agent Claude Code doit appeler l'API GitHub, il lance gh. Pas de serveur. Pas de protocole. Pas de cycle de vie. L'outil est déjà sur la machine et le modèle sait déjà comment le piloter.
La règle de décision honnête
Voici le test que j'utilise vraiment avant d'écrire une seule ligne de code serveur :
- Plus d'un client ou agent va-t-il l'utiliser ? Si non, passez MCP.
- Existe-t-il déjà un CLI qui le fait ? Si oui, laissez l'agent exécuter le CLI.
- Est-ce une intégration ponctuelle pour un seul projet ? Écrivez un outil local, pas un serveur.
- Doit-il survivre à ce dépôt et être partagé ? Là MCP a du sens.
Remarquez combien souvent la réponse est « passez MCP ». Pour un développeur solo qui livre un produit, c'est presque toujours passer. Vous n'avez pas plusieurs clients. Vous en avez un. Vous construisez une infrastructure pour une flotte que vous ne possédez pas.
Le piège de l'enveloppe
Le pire serveur MCP le plus courant est l'enveloppe API. Quelqu'un prend une API REST déjà bien documentée, avec déjà une spec OpenAPI, déjà fonctionnelle avec un token bearer, et l'enveloppe dans MCP. Pourquoi ? L'agent pouvait lire la spec. Il pouvait faire la requête. Vous avez ajouté une couche de traduction entre le modèle et une chose que le modèle maîtrisait déjà.
Pire, vous avez maintenant caché la surface réelle de l'API derrière vos définitions d'outils choisies à la main. L'API a 40 points de terminaison. Votre serveur en expose 6, parce que c'étaient ceux dont vous aviez besoin mardi. Maintenant l'agent ne peut littéralement pas faire les 34 autres choses sans que vous livriez une nouvelle version du serveur.
Si la chose sous-jacente est une API HTTP, essayez d'abord ça :
# Laissez l'agent l'appeler directement
curl -s https://api.example.com/v1/items \
-H "Authorization: Bearer $TOKEN" | jq '.items'
Donnez au modèle l'URL de base, le schéma d'authentification, et la documentation. Regardez-le travailler. Vous serez surpris de la fréquence à laquelle l'exigence « on a besoin d'un serveur MCP » s'évapore.
Quand je fais appel à MCP
Je ne suis pas anti-MCP. J'en ai construit un pour un vector store que quatre agents distincts interrogent, avec une logique d'embedding partagée que je ne voulais pas réimplémenter quatre fois. C'est le point idéal : vrai état partagé, vrai multi-consommateur, vrai coût à dupliquer la logique. Le protocole a gagné sa place.
Je l'utilise aussi quand la capacité doit être avec état d'une façon qu'un CLI sans état ne peut pas bien gérer — un pool de connexions longue durée, un index en cache, une session d'authentification coûteuse à rétablir. Le serveur maintient l'état. Les agents l'empruntent. Bon usage.
Mais ce sont des cas spécifiques. Ce n'est pas « chaque intégration ». La valeur par défaut devrait être : outil direct, ou CLI, ou une simple fonction. MCP est l'escalade, pas le point de départ.
Le problème du développement piloté par le CV
Soyons honnêtes sur pourquoi ça arrive. MCP est nouveau et populaire, et « j'ai construit un serveur MCP » sonne mieux dans un point de synchronisation que « j'ai écrit une définition d'outil en 12 lignes ». Je comprends. L'incitation est de construire la chose qui semble impressionnante.
Mais vos utilisateurs ne se soucient pas de votre architecture. Ils se soucient de savoir si l'agent livre la fonctionnalité. Chaque heure que vous passez à construire de la plomberie de protocole pour une intégration à consommateur unique est une heure que vous n'avez pas consacrée au produit. Le geste le plus senior est souvent le plus ennuyeux : passer le serveur, appeler l'API, avancer.
Construisez le serveur MCP quand vous avez beaucoup de bouches à nourrir. D'ici là, votre agent a un shell. Laissez-le l'utiliser.