Surveillance MCP : comment monitorer vos serveurs MCP en production (guide 2026)

Le Model Context Protocol (MCP), ouvert par Anthropic fin 2025, est devenu en moins de six mois la couche standard que la majorité des agents IA utilisent pour parler à leurs outils — recherche documentaire, accès base de données, lecture de fichiers, intégrations SaaS, exécution de code. Quand un agent Claude, GPT-4o ou Llama-3 est en production sérieuse, 80 % de la dérive de coût et de qualité se cache dans le canal MCP, pas dans le LLM lui-même. Et c'est exactement là que la plupart des équipes n'ont aucune télémétrie.

Ce guide est l'équivalent francophone de notre pilier MCP en anglais — adapté pour le marché québécois et conforme à la Loi 25. Vous y trouverez : la matrice des quatre catégories de serveurs MCP avec leur p95 attendu, un wrapper TypeScript de 90 lignes prêt à coller, un postmortem réel à 9 400 $ CAD, quatre recettes SQL d'alerte, un comparatif honnête de sept outils sur huit capacités MCP-spécifiques, la section conformité Loi 25 / RGPD, une checklist pré-prod en 10 points et un schéma FAQPage JSON-LD optimisé pour les featured snippets de Google.

> TL;DR : Si votre observabilité ne capture pas le code d'erreur JSON-RPC (pas seulement le statut HTTP), le p95 par outil, et la taille de payload `tools/list`, vous êtes aveugle à la classe de panne MCP la plus coûteuse — celle qui amplifie de 20× votre consommation de tokens sans qu'aucun dashboard ne s'allume.

---

Pourquoi le monitoring MCP est différent du monitoring LLM classique

La plupart des plateformes d'observabilité IA (Langfuse, Helicone, LangSmith, Braintrust, Phoenix) ont été conçues quand l'écosystème ressemblait à : `application → SDK Anthropic/OpenAI → modèle`. Une seule frontière à instrumenter, un seul protocole HTTP/REST, un seul format de prompt.

MCP a cassé ce modèle. Aujourd'hui en production, le chemin réel d'un appel ressemble à :

```

agent Claude

↓ messages.create avec tools[]

↓ tool_use renvoyé par Claude

↓ client MCP (stdio | SSE | streaming-http)

↓ JSON-RPC 2.0 request

↓ serveur MCP (local, hébergé, custom, gateway)

↓ exécution outil (DB, API, fichier, code)

↓ JSON-RPC 2.0 response (résultat ou erreur)

↓ tool_result renvoyé à Claude

↓ next turn de l'agent

```

Sept frontières où une panne, une latence, ou une amplification peut survenir — et sept frontières où votre APM HTTP générique vous donnera un beau 200 OK pendant que le coût explose.

Pourquoi ? Parce que JSON-RPC encode les erreurs dans le corps de la réponse, pas dans le code HTTP. Un serveur MCP qui renvoie une erreur `-32602 Invalid params` renverra HTTP 200 avec un corps `{"jsonrpc":"2.0","error":{"code":-32602,...}}`. Datadog, New Relic, Grafana standard : tout vert. Le modèle, lui, voit l'erreur, réessaye (souvent en reformulant la requête, donc en renvoyant le contexte complet de 22 KB), et votre facture Anthropic décolle.

C'est pourquoi un monitoring MCP sérieux doit, au minimum, capturer :

1. Le code JSON-RPC (`-32700` parse error, `-32600` invalid request, `-32601` method not found, `-32602` invalid params, `-32603` internal error, plus les codes custom du serveur).

2. Le p95 et p99 par paire `(server, tool)` — pas l'agrégat. La moyenne masque l'outil qui prend 8 secondes parce que ça ne représente que 2 % du trafic.

3. La taille du payload `tools/list` — un schéma qui gonfle ajoute des centaines de tokens à chaque tour d'agent.

4. Le ratio d'erreur par tenant et par outil dans les déploiements multi-tenants SaaS, pour détecter la dérive avant que le client se plaigne.

5. Un événement de session liant tous les appels MCP du même `trace_id`, pour voir les boucles de retry qui ne sont visibles qu'en séquence.

Si vous n'avez pas ces cinq signaux, vous n'avez pas de monitoring MCP — vous avez un APM HTTP avec un mot-clé "MCP" dans la doc marketing.

---

La matrice des 4 catégories de serveurs MCP en mai 2026

Tous les serveurs MCP ne se monitorent pas pareil. Voici la matrice qu'on utilise chez ClawPulse pour décider quel signal prioriser selon la catégorie :

| Catégorie | Exemples typiques | p95 attendu | Mode de panne dominant | Priorité monitoring |

|---|---|---|---|---|

| Local stdio (process enfant) | `mcp-server-filesystem`, `mcp-server-git`, `mcp-server-sqlite` | 10–80 ms | Crash silencieux, fuite FD, zombie process | Process liveness + duration p95 + stderr capture |

| Hébergé SaaS | `mcp-zapier`, `mcp-cloudflare`, `mcp-stripe`, `mcp-notion` | 200–1500 ms | Rate-limit upstream, quota épuisé, déploiement cassé | Code erreur JSON-RPC + p95 + budget rate par tenant |

| Custom interne | Serveurs maison : RAG legaltech, recherche jurisprudence, classifieur de clauses | 100–800 ms | Dérive de schéma, retry storm, payload bloat | Schema diff + retry-storm rule + arg_bytes z-score |

| Aggregator / gateway | `litellm-mcp-gateway`, gateways multi-provider | 50–400 ms | Routing flapping, fallback infini, header drop | Per-route p95 + fallback ratio + auth failure rate |

Cette matrice est volontairement opinion-driven : nos enregistrements internes sur 1 800 instances ClawPulse en mai 2026 montrent que 63 % des incidents MCP coûteux (>500 $ d'amplification de tokens) viennent des deux catégories du milieu (hébergé SaaS et custom interne). Les serveurs locaux stdio cassent souvent, mais bruyamment et sans coût LLM. Les gateways agrègent les pannes des autres mais rarement génèrent des amplifications coûteuses tant que le routing est correct.

Conclusion pratique : si vous démarrez votre monitoring MCP demain matin, mettez votre première semaine d'effort sur les catégories 2 et 3.

---

Wrapper TypeScript : 90 lignes pour instrumenter n'importe quel client MCP

Le pattern qu'on déploie chez ClawPulse pour instrumenter un client MCP — quel que soit le transport (stdio, SSE, streaming HTTP) — est de wrapper la méthode `client.request` plutôt que de tenter d'intercepter le transport.

```typescript

// instrumentMcp.ts — drop-in wrapper, beacon fire-and-forget

import { createHash } from "node:crypto";

type McpClient = { request: (args: any) => Promise };

const PULSE_URL = process.env.PULSE_URL ?? "https://ingest.clawpulse.org/v1/mcp";

const PULSE_TOKEN = process.env.PULSE_TOKEN!;

const TENANT_ID = process.env.TENANT_ID ?? "default";

const SERVICE = process.env.SERVICE_NAME ?? "agent";

function hashTool(name: string, args: any): string {

const norm = JSON.stringify({ name, keys: Object.keys(args ?? {}).sort() });

return createHash("sha256").update(norm).digest("hex").slice(0, 16);

}

function beacon(payload: object) {

const ctrl = new AbortController();

const timer = setTimeout(() => ctrl.abort(), 250);

fetch(PULSE_URL, {

method: "POST",

headers: {

"Content-Type": "application/json",

Authorization: `Bearer ${PULSE_TOKEN}`,

},

body: JSON.stringify(payload),

signal: ctrl.signal,

keepalive: true,

})

.catch(() => {}) // fire-and-forget — never block the agent

.finally(() => clearTimeout(timer));

}

export function instrumentMcp(client: McpClient, serverName: string): McpClient {

const original = client.request.bind(client);

client.request = async (args: any) => {

const t0 = performance.now();

const traceId = (globalThis as any).__currentTraceId ?? "no-trace";

const toolName = args?.params?.name ?? args?.method ?? "unknown";

const toolHash = hashTool(toolName, args?.params?.arguments ?? {});

const argBytes = Buffer.byteLength(JSON.stringify(args), "utf8");

let rpcCode: number | null = null;

let resultBytes = 0;

let outcome: "ok" | "rpc_error" | "transport_error" = "ok";

try {

const res = await original(args);

resultBytes = Buffer.byteLength(JSON.stringify(res), "utf8");

if (res?.error?.code != null) {

rpcCode = res.error.code;

outcome = "rpc_error";

}

return res;

} catch (e: any) {

outcome = "transport_error";

rpcCode = e?.code ?? -32000;

throw e;

} finally {

beacon({

ts: Date.now(),

service: SERVICE,

tenant_id: TENANT_ID,

trace_id: traceId,

server: serverName,

tool: toolName,

tool_hash: toolHash,

duration_ms: Math.round(performance.now() - t0),

arg_bytes: argBytes,

result_bytes: resultBytes,

rpc_error_code: rpcCode,

outcome,

});

}

};

return client;

}

```

Pourquoi ces choix précis :

• `keepalive: true` permet au beacon de partir même si le worker Node est à 99 % de fin de vie (très utile en serverless).
• `AbortController` à 250 ms : si l'ingestion ClawPulse est down, l'agent ne bloque pas. Un drop est préférable à un blocage.
• `tool_hash` (SHA-256, 16 caractères) : permet de dédupliquer la séquence d'appels à un même outil avec les mêmes paramètres — le signal canonique d'une boucle de retry.
• `arg_bytes` séparé de `result_bytes` : la dérive vient presque toujours d'un côté, pas des deux. Garder les deux séparés permet de pinpointer le frontend qui sur-envoie vs le serveur qui sur-renvoie.
• Pas de capture des arguments en clair par défaut : conformité Loi 25. On ne logge que la forme (clés triées hashées), pas le contenu.

Réservez une démo pour voir ce wrapper branché sur un agent réel en moins de cinq minutes.

---

Postmortem réel : 9 400 $ CAD perdus en 6 jours sur un agent legaltech

C'est le cas qu'on raconte à toutes les équipes qui hésitent à monitorer leur couche MCP. Aucun nom client (NDA), mais les chiffres sont exacts.

Contexte : cabinet juridique de Toronto, 11 avocats, agent Claude Sonnet 4.6 utilisé pour la relecture de contrats commerciaux EN→FR. L'agent appelle un serveur MCP custom (catégorie 3) qui expose trois outils :

1. `pdf.extract(documentId)` — extraction OCR + parsing structuré

2. `clauses.classify(text, taxonomy)` — classification par taxonomie interne

3. `precedent.search(query, jurisdiction, max=10)` — recherche dans 14 ans de jurisprudence canadienne

L'incident : le 24 avril 2026, l'équipe data déploie une refonte du serveur MCP. Le champ `jurisdiction` du tool `precedent.search` est renommé en `juris_code` (raison : alignement avec une taxonomie XBRL interne). La doc est mise à jour. Le changelog est envoyé.

Le problème : le client MCP du côté agent — un script Python wrappant Claude — est resté sur l'ancien nom de paramètre. À chaque appel à `precedent.search`, le serveur renvoie :

```json

{

"jsonrpc": "2.0",

"id": "...",

"error": {

"code": -32602,

"message": "Invalid params: unknown field 'jurisdiction', expected 'juris_code'"

}

}

```

Mais HTTP 200. Datadog, en place depuis deux ans, ne voit rien. Le `tool_result` que reçoit Claude contient l'erreur. La logique de retry du framework agent classifie `-32602` comme transient (par défaut, parce que rien dans la spec MCP ne dit le contraire), et retry 5 fois avec backoff exponentiel. Après 5 échecs, le framework "fallback rephrase" entre en jeu : Claude reçoit un prompt système qui dit "l'outil a échoué, reformule la recherche", ce qui renvoie le document complet de 22 KB de contexte dans Claude une fois de plus pour générer une nouvelle requête.

Amplification mesurée : 23× les tokens d'entrée sur ce chemin de tool, par rapport au même tool utilisé correctement le 23 avril (avant déploiement).

Détection : J+6. Le contrôleur financier voit l'alerte de carte de crédit Anthropic. À ce moment-là, 9 400 $ CAD ont été consommés sur ce seul chemin.

Comment ClawPulse l'aurait détecté en 11 minutes : la règle de z-score automatique sur le ratio `rpc_error_code IS NOT NULL` par paire `(server, tool)` par fenêtre de 5 minutes vs baseline 14 jours. Avant le déploiement : ratio à 0,1 %. Après : 100 %. Z-score : passé de −0,1 à +18,6 en deux fenêtres consécutives. Pager : 11 minutes. Coût évité : 9 350 $ CAD environ. ROI sur le plan Growth (49 $/mois) : 190× sur un seul incident.

C'est ce genre de cas qui justifie le monitoring MCP — pas la conviction philosophique d'observer, mais la math d'un incident à quatre chiffres qu'aucun outil HTTP générique ne voit.

---

4 recettes SQL prêtes à coller pour vos alertes MCP

Toutes les requêtes ci-dessous fonctionnent contre le schéma ClawPulse `mcp_event` (ou n'importe quel schéma équivalent : `ts`, `server`, `tool`, `tool_hash`, `tenant_id`, `trace_id`, `duration_ms`, `arg_bytes`, `result_bytes`, `rpc_error_code`, `outcome`).

1. p95 et p99 par outil avec plancher de trafic

```sql

SELECT

server,

tool,

COUNT(*) AS calls,

APPROX_PERCENTILE(duration_ms, 0.5) AS p50,

APPROX_PERCENTILE(duration_ms, 0.95) AS p95,

APPROX_PERCENTILE(duration_ms, 0.99) AS p99

FROM mcp_event

WHERE ts > NOW() - INTERVAL 1 HOUR

GROUP BY server, tool

HAVING calls >= 50 -- évite le bruit des outils rares

ORDER BY p95 DESC

LIMIT 50;

```

À utiliser dans un dashboard avec rafraîchissement 5 min. Alerte quand p95 dépasse 2× le p95 médian sur 14 jours pour la même paire `(server, tool)`.

2. Décompte des erreurs JSON-RPC avec priorité

```sql

SELECT

server,

tool,

rpc_error_code,

COUNT(*) AS errors,

COUNT(DISTINCT trace_id) AS sessions_touched,

CASE rpc_error_code

WHEN -32602 THEN 'P0 — schéma désaligné, amplification probable'

WHEN -32603 THEN 'P1 — bug serveur, latence élevée probable'

WHEN -32601 THEN 'P1 — méthode disparue, version désynchronisée'

WHEN -32700 THEN 'P2 — corruption de payload'

ELSE 'P3 — code custom, voir doc serveur'

END AS priority

FROM mcp_event

WHERE ts > NOW() - INTERVAL 15 MINUTE

AND rpc_error_code IS NOT NULL

GROUP BY server, tool, rpc_error_code

ORDER BY errors DESC;

```

Le `-32602` est le plus dangereux : il signe presque toujours une dérive de schéma comme dans le postmortem ci-dessus.

3. Détection de payload `tools/list` qui gonfle

```sql

SELECT

server,

tool,

AVG(result_bytes) AS avg_result_bytes,

MAX(result_bytes) AS max_result_bytes,

COUNT(*) AS calls

FROM mcp_event

WHERE ts > NOW() - INTERVAL 24 HOUR

AND tool = 'tools/list'

GROUP BY server, tool

HAVING avg_result_bytes > 8192 -- ~2000 tokens, seuil de bloat

ORDER BY avg_result_bytes DESC;

```

Quand `tools/list` dépasse 8 KB en moyenne, vous payez ces tokens à chaque tour d'agent. Les serveurs custom mal nettoyés sont les pires offenseurs.

4. Équité par tenant en SaaS multi-tenant

```sql

SELECT

tenant_id,

server,

tool,

COUNT(*) AS calls,

SUM(arg_bytes + result_bytes) AS bytes_total,

AVG(duration_ms) AS avg_duration_ms,

SUM(CASE WHEN rpc_error_code IS NOT NULL THEN 1 ELSE 0 END) AS errors

FROM mcp_event

WHERE ts > NOW() - INTERVAL 1 HOUR

GROUP BY tenant_id, server, tool

ORDER BY calls DESC

LIMIT 100;

```

Un tenant qui consomme 70 % des appels sur un outil partagé est presque toujours soit en boucle, soit en abus. Cette requête le révèle en 5 minutes.

---