Les Serveurs MCP Échouent en Silence. Votre Dashboard ne Vous le Dira Pas.

Votre serveur MCP renvoie 200 OK à chaque requête. Votre tableau de bord est au vert. Vos utilisateurs sont frustrés.

Les codes de statut HTTP ne mesurent pas ce qui compte ici. L'outil a renvoyé des données. Était-ce le bon outil ? La réponse était-elle utile ? Le modèle l'a-t-il vraiment utilisée ?

Une évaluation publique d'Anthropic sur l'utilisation d'outils par les agents (MCP Bench, fin 2025) a mesuré des taux d'erreur de sélection entre 28% et 46% sur des serveurs MCP populaires avec plus de six outils. Le même schéma apparaît en production : des serveurs avec uptime parfait, latence sous 200ms, zéro erreur 5xx — pendant que le modèle appelle le mauvais outil près de la moitié du temps.

Le serveur ne le sait pas. L'équipe ne le sait pas. Les utilisateurs disent juste que l'IA est mauvaise.

C'est la panne silencieuse. Un serveur MCP peut passer chaque check traditionnel et quand même répondre à la mauvaise question à chaque appel.

Pour une API REST, fonctionner signifie accepter des requêtes valides et renvoyer des réponses correctes. Des décennies d'outillage existent pour vérifier ça.

Pour un serveur MCP, fonctionner est une chaîne de quatre étapes. Le modèle choisit le bon outil. Il envoie les bons paramètres. Il reçoit une réponse utile. Il l'intègre dans sa réponse. Chaque étape échoue indépendamment. Aucune n'apparaît dans le monitoring traditionnel.

Mauvais outil ? 200. Paramètres qui passent la validation de schéma mais ratent l'intention de l'utilisateur ? 200. Réponse ignorée ? 200.

Vous pouvez avoir 100% de succès sur le tableau de bord et 40% de succès en production. Cet écart est là où les utilisateurs disent « l'IA ne marche pas » — et ils ont raison, même si chaque métrique SRE dit le contraire.

Une fois admis que les métriques traditionnelles sont insuffisantes, la question devient quoi mesurer à la place. Cinq choses.

**Précision de sélection d'outil.** Si vous avez `search_invoices` et `list_documents`, et qu'un utilisateur demande « les factures du mois dernier », lequel est appelé ? Suivez l'écart entre sélection prévue et réelle. C'est la métrique la plus révélatrice en observabilité MCP.

**Validité des paramètres.** Pas si les paramètres ont passé la validation de schéma — ça c'est le minimum. La plage de dates correspondait-elle à la demande ? La requête a-t-elle capté l'intention ?

**Utilisation de la réponse.** Le modèle a-t-il utilisé la réponse ? Si vous renvoyez 50 lignes et que le modèle n'en référence aucune dans sa réponse, soit la description de l'outil est mauvaise, soit le format est mauvais, soit les données sont hors sujet.

**Taux de récupération d'erreur.** Quand un appel échoue, le modèle réessaie-t-il avec des paramètres corrigés, change-t-il d'outil, ou abandonne-t-il ? Le pattern de récupération dit si vos messages d'erreur sont utiles.

**Coût par invocation réussie.** Pas coût par appel. Coût par appel qui a produit une réponse utile. Les reprises ratées et les appels au mauvais outil poussent le coût réel à 3-5x la dépense brute de l'API.

Ces cinq-là en disent plus sur la santé d'un serveur MCP que toutes les métriques traditionnelles réunies.

Datadog, New Relic et Grafana excellent dans leur domaine. Ils suivent les distributions de latence, les taux d'erreur, le débit, l'utilisation des ressources. C'est la bonne forme pour une API dont l'appelant est un navigateur ou une app envoyant des requêtes déterministes.

L'appelant d'un serveur MCP n'est pas déterministe. C'est un modèle qui prend une décision à l'inférence. Le mode de panne n'est pas « requête expirée ». C'est « le modèle a décidé que c'était le bon outil, et ce ne l'était pas ». C'est un problème de qualité de décision, et l'APM traditionnel n'est pas fait pour mesurer ça.

Concrètement : si votre agent a `get_customer` et `search_customers` et que le modèle choisit toujours `get_customer` avec un ID deviné, votre p99 reste plat, votre taux d'erreur reste plat, et chaque interaction utilisateur se termine en échec. L'outillage existant n'a aucun signal à émettre.

Vous avez besoin d'une couche d'observabilité entre le modèle et les outils — une qui corrèle intention utilisateur, sélection d'outil, paramètres et utilisation de la réponse. L'APM traditionnel est le plancher. Pour les serveurs MCP, il ne fait pas la moitié du tableau.

Trois choses concrètes pour commencer. Pas besoin de tout révolutionner.

**1. Loguez chaque invocation avec le contexte complet du prompt.** Pas seulement le nom de l'outil et les paramètres. La conversation qui a mené à l'appel, le system prompt, le dernier message de l'utilisateur. Sans contexte, impossible d'évaluer si la sélection était correcte.

**2. Suivez l'outil prévu versus l'outil sélectionné.** Il faut de la vérité terrain — étiquettes manuelles sur un échantillon, signaux pouce haut/bas des utilisateurs, ou règles heuristiques (une question qui matche « facture|facturation|paiement » finissant par un `list_contacts` est un défaut). Même les heuristiques approximatives battent rien.

**3. Mesurez l'utilisation de la réponse.** Comparez ce que l'outil a renvoyé avec ce qui est apparu dans la réponse finale du modèle. Un grand écart signifie mauvais format, données hors sujet, ou description qui n'aide pas le modèle à utiliser le résultat.

Ces trois signaux — contexte d'invocation, précision de sélection, utilisation de la réponse — vous disent si votre serveur MCP aide vraiment les utilisateurs. Les dashboards cinq-neuf vous disent si le processus tourne. Ce sont deux questions différentes.