Trois outils MCP déployés sur cinq ne disent rien à l'agent de ce qu'ils font

De quoi s’agit-il ?

Le 10 septembre 2026, le chercheur indépendant Haseeb Mohammed Afsar a publié une mesure de la population des serveurs Model Context Protocol qui fait ce que la littérature existante ne fait pas : elle tire un échantillon probabiliste et refuse de réparer quoi que ce soit.

À partir d’un recensement du registre MCP officiel — 24 135 serveurs au balayage du 22 août 2026, contre 16 548 au 14 juillet 2026 — l’étude construit une base de sondage de 7 258 entrées actives publiées sur npm et déclarées en stdio, en tire 400 avec une graine publiée, et sonde chacune exactement une fois. Aucun identifiant, aucune nouvelle tentative, aucune réparation. Chaque tirage est consigné avec son issue.

Deux chiffres comptent pour la posture de sécurité. Seuls 48,8 % ont mené à bien une poignée de main initialize. Et sur les 2 766 outils annoncés par les 195 serveurs qui ont démarré, 1 626 — soit 58,8 % — ne portent aucune annotation de sûreté.

Comment ça marche

Les ToolAnnotations de MCP, livrées avec la révision 2025-03-26 de la spécification, sont quatre booléens optionnels qui permettent à un serveur d’indiquer au client ce que fait un outil avant de l’appeler : readOnlyHint, destructiveHint, idempotentHint, openWorldHint. C’est tout le vocabulaire de risque pré-appel du protocole.

La spécification en parle avec prudence dans deux directions à la fois. D’abord, ce sont des indications et non des contrats — un billet des mainteneurs MCP du 16 mars 2026 rappelle que les clients doivent traiter comme non fiables les annotations provenant d’un serveur non fiable, puisqu’un serveur peut déclarer readOnlyHint: true et supprimer vos fichiers malgré tout. Ensuite, les valeurs par défaut sont délibérément pessimistes : un outil non annoté doit être présumé non lecture seule, potentiellement destructif, non idempotent et ouvert sur l’extérieur.

Cette valeur par défaut est la pièce porteuse. Elle ne produit un comportement sûr que si les clients la respectent — et la respecter avec un taux d’omission de 58,8 % revient à solliciter l’utilisateur sur environ trois outils sur cinq accessibles à l’agent.

La mesure montre aussi où se loge l’omission, et elle n’est pas diffuse. Sur les 194 serveurs annonçant au moins un outil, 72 annotent tous leurs outils et 122 n’en annotent aucun. Pas un seul serveur partiellement annoté n’apparaît dans l’échantillon. Les auteurs se refusent à en faire un absolu — zéro observation sur 194 fonde une borne supérieure unilatérale à 95 % de 1,53 % sur l’annotation partielle, pas une négation — et signalent qu’une exécution antérieure non publiée avait trouvé quatre serveurs partiels, résultat que l’exécution actuelle ne reproduit pas.

  tirés de la base de sondage        400 serveurs
  ├─ poignée de main réussie         195   48,8 %   ← le seul palier que l'on mesure
  ├─ n'a jamais démarré              150   37,5 %
  ├─ identifiants requis              53   13,3 %
  └─ paquet indisponible               2    0,5 %

  sur les 195 démarrés → 2 766 outils annoncés
  ├─ violations fatales de schéma JSON  0    0,0 %
  └─ sans annotation de sûreté      1 626   58,8 %   (base curée : 41,5 %)

La ligne des schémas mérite d’être relevée, car elle contredit une intuition répandue : zéro outil sur 2 766 porte une violation fatale de JSON Schema. Les schémas d’outils MCP ne sont pas malformés en pratique. Toute la variance se trouve dans les métadonnées optionnelles.

Pourquoi c’est important

Le résultat de plus grande portée n’est pas les 58,8 %. C’est que la curation embellit la santé de l’écosystème dans les deux directions à la fois. Passée au même instrument, une base curée à la main de 24 serveurs de référence et populaires donne un taux de démarrage de 66,7 % (17,9 points de mieux) et un taux d’omission d’annotations de 41,5 % (17,3 points de mieux). Les serveurs de référence annotent, et les bases curées en sont pleines. Toute statistique de posture tirée d’une liste de popularité, d’un jeu de référence ou d’un pipeline qui répare les serveurs jusqu’à ce qu’ils démarrent mesure une population qui s’est sélectionnée pour fonctionner.

Cela change directement la lecture du reste de la littérature de sécurité MCP. L’évaluation dynamique de Nicolás Padilla, publiée le 31 juillet 2026, portant sur 414 serveurs exposés sur Internet — 68 constats rapportables, 91,8 % sans OAuth, et 41,6 % des serveurs confirmés disparus en trois jours entre deux passes — corrobore ce renouvellement par le versant distant. Deux instruments indépendants s’accordent désormais : une large part de ce que le registre annonce n’est pas une chose durable et fonctionnelle.

Pour un client, un outil non annoté ne laisse que deux options, toutes deux mauvaises à ce taux. Respecter la valeur par défaut pessimiste, et vous générez des demandes d’approbation sur la majeure partie de la surface d’outils — c’est ainsi que l’on apprend aux utilisateurs à valider sans lire, la même fatigue que nous avons traitée dans l’écart entre ce qu’une fenêtre d’approbation bloque et ce qu’elle montre. L’ignorer, et vous avez silencieusement auto-approuvé des outils dont personne n’a déclaré le comportement. Le billet des mainteneurs note lui-même qu’aucun client MCP ne permet aujourd’hui de filtrer les outils par valeur d’annotation, et qu’aucun ne fait remonter les annotations dans les demandes d’approbation : en pratique, l’essentiel de ce vocabulaire n’atteint pas la décision qu’il était censé éclairer.

Les 37,5 % qui ne démarrent jamais constituent un problème de second ordre. Un registre où deux entrées publiées sur cinq sont inertes est un registre plein de noms qui ne résolvent vers rien — et un nom qui ne résout vers rien est un nom qu’un attaquant peut faire résoudre vers quelque chose. C’est le problème d’hygiène du chemin d’installation qui sous-tend les réécritures de description après approbation et la campagne Deadbugz et ses métadonnées activées à l’exécution, où le comportement hostile n’apparaît qu’une fois l’approbation obtenue.

Un dernier résultat, à l’attention de quiconque évalue des agents : à méthode de similarité constante, les vrais outils MCP présentent 2,8 % de quasi-doublons au cosinus 0,70 et 0,0 % entre auteurs indépendants, à tous les seuils testés. BFCL v4 en présente 16,7 %, dont 16,4 points entre des tâches présentées comme indépendantes. Avant déduplication, 68,8 % des lignes brutes de BFCL et 85,6 % de celles d’UltraTool sont des répétitions exactes nom + description, contre 0,4 % pour les vrais outils MCP. Après déduplication, UltraTool est plus propre que les outils réels, à 0,3 % : c’est donc une propriété d’un corpus donné et non des corpus synthétiques comme classe — le papier le dit explicitement. L’enseignement opérationnel : une statistique calculée sur ces publications sans déduplication globale mesure de la répétition, pas des outils.

Défenses

Traitez une annotation manquante comme un constat, pas comme une valeur par défaut. Si vous exploitez une passerelle MCP interne, énumérez tools/list sur chaque serveur enregistré et remontez le taux d’omission d’annotations par serveur. La distribution en tout-ou-rien rend l’exercice peu coûteux : vous classez des serveurs, pas des outils.

Ne laissez pas une indication absente devenir une approbation implicite. Quel que soit le traitement que votre client réserve à destructiveHint: true, il doit réserver le même à un outil sans aucune indication. C’est ce que dit la valeur par défaut de la spécification, et c’est le cas que les clients exercent le moins.

Ne laissez jamais une indication issue d’un serveur non fiable assouplir un contrôle. Les annotations sont écrites par le serveur et non vérifiées. Servez-vous-en pour durcir la posture — un outil marqué openWorldHint: true fait basculer la session en « porteuse de contenu non fiable » — et jamais pour sauter un contrôle. Là où il vous faut une garantie plutôt qu’une indication, placez-la dans la couche d’autorisation, le transport ou le bac à sable. L’application des règles doit se situer là où elle est applicable.

Épinglez le chemin d’installation, pas le nom dans le registre. Avec un taux de non-démarrage de 37,5 %, la plupart des entrées du registre ne sont pas des dépendances réelles — mais celles dont vous dépendez doivent être épinglées par version et empreinte d’intégrité, résolues depuis un miroir que vous contrôlez, et revérifiées à chaque reconnexion plutôt que tenues pour acquises après la première poignée de main.

Relisez vos propres indicateurs de posture. Si un rapport d’éditeur, un audit interne ou un banc d’essai de scanner a échantillonné des serveurs populaires ou de référence, considérez qu’il est optimiste d’environ 17 points, tant sur le taux de démarrage que sur la couverture d’annotations. Demandez quelle était la base de sondage avant de porter le chiffre dans un registre de risques.

Annotez ce que vous publiez. Si vous écrivez un serveur, positionnez readOnlyHint: true sur les outils en lecture seule, destructiveHint: false sur les opérations purement additives et openWorldHint: false sur les outils à domaine fermé. Cela coûte quatre booléens, et c’est le seul signal dont dispose un client avant l’appel.

Statut

Élément	Détail
Publication	arXiv:2609.10962v1 [cs.SE], 10 septembre 2026
Auteur	Haseeb Mohammed Afsar (chercheur indépendant)
Balayages du recensement	14 juillet 2026 (16 548 serveurs) et 22 août 2026 (24 135 serveurs), tous deux complets
Échantillon	400 serveurs npm/stdio, graine 20260819, base épinglée par SHA-256
Chiffres clés	48,8 % de taux de démarrage ; 58,8 % des 2 766 outils non annotés ; 0 violation fatale de schéma
Effet de curation	+17,9 pts de taux de démarrage, −17,3 pts d’omission d’annotations sur une base curée de 24 serveurs
Corroboration	arXiv:2608.00150 (31 juillet 2026), 414 serveurs exposés, 41,6 % disparus en trois jours
Limites de portée	npm/stdio uniquement (30,7 % de la population, en baisse) ; une seule sonde, sans nouvelle tentative — 48,8 % est une borne inférieure
Reproductibilité	Instrument, graine, issues par tirage et scripts publiés ; DOI de concept Zenodo 10.5281/zenodo.21347997