Mcp-Method et Mcp-Name : router du trafic MCP sans lire le body

C'est le changement le moins spectaculaire de la spec 2026-07-28, et le plus rentable si tu exploites l'infrastructure.

Deux en-têtes deviennent obligatoires sur le transport Streamable HTTP : Mcp-Method et Mcp-Name. Ils reflètent la méthode JSON-RPC et le nom appelé dans le corps de la requête. Une requête qui appelle l'outil export_all via tools/call l'annonce désormais dans ses en-têtes.

Le problème que ça résout

Jusqu'ici, toutes les requêtes MCP ressemblaient à la même requête vue de l'extérieur. Même URL, même méthode HTTP, même forme. La seule façon de savoir si un appel était une lecture triviale ou un export de toute la base était d'ouvrir le corps JSON-RPC.

Ça obligeait à des choses désagréables. Une passerelle qui fait de l'inspection profonde de paquets pour router. Un WAF aveugle. Des métriques qui ne descendent pas plus bas que « requêtes MCP par seconde ». Un rate limit global qui protège mal, parce qu'il traite le listing d'outils et la génération de rapport de la même manière.

Avec les deux en-têtes, tout ça se fait au niveau HTTP, avec les outils que tu as déjà.

Ce que tu peux faire dès la migration

Rate limit par outil. Dix appels par minute sur ton outil d'export, mille sur ta recherche. C'est probablement le gain le plus immédiat, parce que c'est aussi la protection anti-abus la plus efficace sur un serveur MCP public.

Routage vers des pools dédiés. Les outils coûteux partent sur des instances dimensionnées pour eux, sans polluer la latence des appels rapides.

Règles WAF sur les écritures. Filtrage, alerte ou double authentification sur les seuls outils destructeurs, sans toucher au reste.

Télémétrie par outil. Latence, taux d'erreur et volume par outil, directement depuis les logs d'accès. C'est ce qui te permet de dire après la migration si quelque chose s'est dégradé, et où.

Cache. Les réponses de listing deviennent identifiables sans lecture du body, donc cachables à la périphérie.

Fais ce travail pendant la migration, pas après. Tu as besoin d'une baseline par outil avant la bascule pour pouvoir comparer.

Le piège de sécurité

Ces en-têtes sont déclaratifs. Ils sont fournis par le client, et rien dans le transport ne garantit qu'ils correspondent au corps de la requête.

Le scénario d'attaque est direct : envoyer une requête dont le Mcp-Name désigne un outil anodin en lecture seule, pendant que le corps JSON-RPC appelle un outil restreint. Si ta politique d'autorisation ou ton rate limit se fie à l'en-tête sans vérifier, tu viens de créer un contournement propre et discret.

La règle est simple : la périphérie peut utiliser les en-têtes pour router, mesurer et limiter, mais l'autorisation se décide sur le corps de la requête, côté serveur. Et le serveur doit rejeter explicitement toute incohérence entre l'en-tête et le corps.

Ce rejet doit remonter dans ta télémétrie de sécurité, pas seulement dans les logs d'erreur. Un décalage entre en-tête et corps n'est presque jamais un bug de client. C'est un signal.

C'est aussi un des tests que je fais systématiquement en audit, parce que la plupart des serveurs migrés à la va-vite valident l'un ou l'autre, jamais les deux.

Ce qu'il faut vérifier chez toi

• Ton serveur exige-t-il les deux en-têtes, ou les traite-t-il comme optionnels ?
• Rejette-t-il une requête dont l'en-tête ne correspond pas au corps ?
• Ce rejet est-il compté et alerté ?
• Tes règles de périphérie prennent-elles une décision d'autorisation, ou seulement de routage ?
• Tes clients maison envoient-ils correctement les deux en-têtes ?

Ce dernier point est celui qui casse en premier. Un client interne écrit il y a un an, qui construit ses requêtes à la main plutôt qu'avec le SDK, se fera refuser dès que ton serveur exigera les en-têtes.

FAQ

Est-ce que je peux router uniquement sur Mcp-Method ?

Oui pour du routage grossier, entre les listings et les appels d'outils. Pour du rate limit ou du routage par outil, il te faut Mcp-Name.

Que faire d'une requête sans les en-têtes ?

Ça dépend de ta stratégie de compatibilité. Si tu sers encore l'ancienne révision, la requête vient probablement d'un ancien client et doit être traitée comme telle. Si tu ne sers que la nouvelle, tu refuses.

Est-ce que ça remplace l'authentification ?

Non, et c'est tout le sens du paragraphe précédent. Ces en-têtes sont une facilité d'exploitation, pas un mécanisme de sécurité.

Ta périphérie fait peut-être confiance à un en-tête déclaratif

C'est une des vérifications de l'audit. Envoie-moi ton serveur et ta configuration de passerelle, tu reçois sous 24 heures ouvrées le détail de ce qui est vérifié et de ce qui ne l'est pas.

Prêt à faire le point ? Faire auditer mon serveur MCP →

Lectures liées

• Migrer un serveur MCP vers la spec 2026-07-28 : le guide complet
• Serveur MCP sans session : remplacer Mcp-Session-Id par des handles
• Audit de migration MCP : la checklist en 12 points