MCP en production : ce que la spec ne vous dit pas

Construire votre premier serveur MCP prend un week-end. La spec est propre, les SDK sont bons, et la démo où Claude appelle vos tools tient de la magie. Je le sais parce que j'ai livré cette démo. Puis j'ai passé les six mois suivants à apprendre tout ce que la spec ne couvre pas.

Produit fictif. Patterns d'ingénierie réels.

Le contexte : AdPilot, une plateforme où un agent IA gère des campagnes publicitaires sur Meta, LinkedIn et Google Ads. L'agent fait des choses réelles avec de l'argent réel. Il met en pause des campagnes, ajuste des budgets, récupère des données de performance. Tout passe par MCP. Voici ce que j'aurais aimé savoir dès le premier jour.

Problème un : vos tools dévorent le context window

On a commencé avec un serveur MCP par plateforme. Le serveur LinkedIn exposait à lui seul 27 tools. Google Ads en demandait 36 pour couvrir campagnes, groupes d'annonces, mots-clés, budgets, stratégies d'enchères et reporting. Ajoutez Meta et vous poussez plus de 80 définitions de tools dans le contexte du modèle avant que l'utilisateur ait tapé le moindre mot.

Deux choses se produisent. D'abord, vous payez ces tokens à chaque requête. Ensuite, et c'est pire, l'agent devient plus bête. Avec 80 tools qui se ressemblent tous vaguement (update_campaign, update_campaign_budget, update_ad_group_budget...), la précision de sélection des tools chute. Le modèle choisit le tool LinkedIn quand l'utilisateur parlait de Google. Il enchaîne trois appels là où un seul suffirait.

Le correctif n'était pas moins de fonctionnalités. C'était de la consolidation : on a migré de serveurs autonomes par plateforme vers un unique serveur multi-source, avec un middleware partagé et un routing par source. Moins de tools, mais plus intelligents, avec un paramètre source : ça bat une multitude de tools étroits. Les descriptions de tools sont devenues la surface de prompt engineering au plus fort levier de tout le produit. On les réécrivait plus souvent que le system prompt.

Problème deux : l'auth, c'est entièrement votre problème

La spec MCP vous donne un transport et un protocole. Elle ne vous dit pas comment gérer un workspace dont le token Meta expire tous les 60 jours, ni quoi faire quand un utilisateur révoque l'accès depuis l'interface Meta sans vous prévenir.

Dans un produit multi-tenant, chaque appel de tool doit résoudre les credentials au runtime : quelle organisation, quel workspace, quel compte plateforme, quel token. On a fini avec des API keys scopées par workspace, un helper de refresh de token qui se déclenche proactivement avant l'expiration, et une détection de token révoqué qui propage un statut que l'interface peut afficher. Rien de glamour là-dedans. Tout est obligatoire, parce qu'un agent qui échoue silencieusement sur un token expiré ne ressemble pas à un problème d'auth pour l'utilisateur. Il ressemble à un agent stupide.

Pour les clients agences qui gèrent des comptes clients sur le long terme, le flow OAuth standard ne suffisait même pas. On a ajouté un second parcours d'onboarding avec des system tokens qui n'expirent pas. Deux flows d'auth pour une seule plateforme, parce que le travail du protocole s'arrête là où la réalité de vos utilisateurs commence.

Problème trois : les messages d'erreur sont des prompts

Celui-là m'a pris un temps embarrassant à intégrer. Quand un appel de tool échoue, le message d'erreur n'est pas destiné à un développeur qui lit les logs. Il est destiné au modèle, qui va le lire et décider quoi faire ensuite.

Error 400: invalid parameter envoie l'agent dans une boucle de retry avec les mêmes arguments cassés. The date range exceeds 90 days. Split the request into smaller ranges. vous donne une deuxième tentative correcte. On s'est mis à écrire les messages d'erreur comme on écrit des prompts : dire ce qui n'a pas marché, dire quoi faire à la place. La gestion d'erreur des tools est devenue une partie de la boucle de raisonnement de l'agent, pas un détail rajouté après coup.

Même logique pour l'idempotence. Les agents font des retry. Parfois ils réessaient des choses qui avaient déjà réussi. Tout tool avec des effets de bord, comme créer une campagne ou ajuster un budget, doit tolérer d'être appelé deux fois avec la même intention, sinon vous expliquerez à un client pourquoi son budget a doublé.

Problème quatre : parfois le meilleur tool, c'est du SQL

Le plus grand déblocage est venu de la suppression de tools, pas de leur ajout.

Au début, répondre à "compare le CPA des trois dernières semaines au mois précédent, par campagne" obligeait l'agent à enchaîner des appels API paginés : lister les campagnes, récupérer les insights par campagne, récupérer la période de comparaison, agréger dans sa tête. Lent, coûteux, et faux assez souvent pour être gênant.

On avait déjà construit un pipeline de données qui synchronisait les données des plateformes pub dans ClickHouse, avec une row-level security native par tenant. On a donc remplacé la chaîne de tools de reporting par un seul : exécuter du SQL brut sur les tables de reporting, la RLS appliquée automatiquement selon le scope de l'utilisateur.

Un seul tool, une flexibilité analytique quasi illimitée. Le modèle est bon en SQL, bien meilleur qu'à orchestrer cinq endpoints paginés. La frontière de sécurité s'est déplacée là où elle doit être : dans la base de données. Chaque requête doit porter le contexte du tenant, et les row policies échouent avec une erreur explicite si celui-ci manque. Pas en silence. De manière bruyante. Même un bug dans la couche applicative ne peut pas faire fuiter des données entre workspaces.

La leçon se généralise : un tool est une interface pour un moteur de raisonnement, pas un wrapper autour de votre API REST. Concevez pour ce en quoi le modèle est bon.

Ce que je me dirais au tout début

La spec, c'est les 20 % faciles. Le vrai travail, c'est le cycle de vie de l'auth, l'isolation des tenants, les messages d'erreur écrits pour un modèle, et une curation impitoyable des tools. Budgétez pour ça, pas pour le protocole.

Et mesurez la précision de sélection des tools comme vous mesurez la latence. C'est la métrique qui décide si votre agent paraît intelligent ou stupide, et personne ne vous prévient à son sujet.