Convention 3 impose { success: false, error, tool }, mais le champ tool n'etait
ajoute que par le wrapper de src/index.js. Les enveloppes construites
localement dans src/tools/ ne le portaient pas : call_query_api avec
query_type: 7 repondait { success: false, error: "query_type invalide : ..." },
sans tool. Le contrat etait donc respecte ou non selon le chemin d'erreur --
alors qu'il est lu par Claude, pas par un humain.
Balayage des 8 modules : 15 enveloppes success:false au total, 11 y ont gagne
le champ tool (ad-tools, config-tools, wms-query-tools et workflow-tools
l'avaient deja via le catch de leur executeTool). Les champs additionnels sont
conserves et passent apres tool : warning de resolution d'api-tools,
availableCount + hint de get_entity_metadata, listes de profils de
profile-tools.
Grep de controle -- 15 enveloppes, 0 sans tool :
src/tools/ad-tools.js:140 tool: name
src/tools/api-tools.js:170 tool: 'call_query_api'
src/tools/api-tools.js:217 tool: 'execute_command'
src/tools/config-tools.js:179 tool: 'get_system_parameters'
src/tools/log-tools.js:116 tool: 'list_log_files'
src/tools/log-tools.js:157 tool: 'read_recent_logs'
src/tools/log-tools.js:227 tool: 'search_logs'
src/tools/metadata-tools.js:110 tool: 'get_entity_metadata'
src/tools/metadata-tools.js:154 tool: 'get_entity_metadata'
src/tools/metadata-tools.js:197 tool: 'generic_search'
src/tools/profile-tools.js:111 tool: 'get_current_wms_profile'
src/tools/profile-tools.js:129 tool: 'switch_wms_profile'
src/tools/profile-tools.js:159 tool: 'switch_wms_profile'
src/tools/wms-query-tools.js:169 tool: name
src/tools/workflow-tools.js:117 tool: name
Verifie en execution (protocole, LIMAGRAIN sauf mention) -- 11 enveloppes
declenchees, toutes avec tool :
call_query_api query_type: 7 -> tool: call_query_api
get_entity_metadata entite inconnue -> tool + availableCount + hint
query_wms_entities entite inconnue -> tool: query_wms_entities
get_workflow_details id inconnu -> tool: get_workflow_details
get_ad_elements type inconnu -> tool: get_ad_elements
switch_wms_profile profil inconnu -> tool + profiles
read_recent_logs fichier inexistant -> tool: read_recent_logs
list_log_files / search_logs /
read_recent_logs sur EUROTRAFIC -> tool, garde SaaS D9 (sans reseau)
Trois catch restent couverts statiquement, faute de declencheur : celui
d'execute_command (interdit d'appel, il ecrit dans le WMS), celui de
generic_search (l'API tolere categorie inexistante comme limit negative :
elle repond success), et celui de get_current_wms_profile (inatteignable tant
qu'un profil par defaut se charge au demarrage).
Baseline preservee : 23 outils, 6 resources.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Mesure V1 (24/08/2026) : le SDK MCP ignore additionalProperties: false —
read_recent_logs({lines: 5}) avec la clause sur le schéma répondait
success: true, returnedLines: 100 (retombée silencieuse sur le défaut).
La validation vit donc dans le wrapper tools/call de src/index.js,
pilotée par les schémas de la table de routage (D22) : paramètre inconnu
ou requis manquant -> erreur structurée nommant le fautif et les
paramètres valides, avant tout dispatch.
Les 23 schémas portent additionalProperties: false — inerte côté SDK,
mais c'est le contrat que lisent les clients. Pas de renommage de
paramètres (écarté, cf. ROADMAP).
Mesures (via le protocole) :
- read_recent_logs({"lines": 5}) -> "Paramètre(s) inconnu(s) pour
read_recent_logs : lines. Paramètres valides : count, log_file."
- read_recent_logs({"count": 5}) -> succès, returnedLines: 5
- boucle sur 22 outils avec {} (execute_command vérifié statiquement) :
22/22 répondent, aucun Unknown tool, les 11 outils à paramètres requis
échouent avec le message actionnable
- handshake : 23 outils, 6 resources
Docs : D23 dans DECISIONS.md, L2.2 retirée de la ROADMAP.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Arthur Ria