Perché il monitoring classico non basta per i server MCP

Il ping che mente

Immagina questo scenario. Hai un server MCP in produzione, dietro a un load balancer, con un bel health check che controlla HTTP 200 sulla porta. Tutto verde. Il tuo dashboard di uptime segna 99,99%. Sei tranquillo.

Peccato che, dopo l'ultimo deploy, il server abbia iniziato a rispondere all'initialize con una spec version che i tuoi client non capiscono. Oppure che uno dei tool sia ancora elencato ma vada in timeout a ogni chiamata. Il tuo monitoring non se ne accorge: la porta è aperta, il processo è vivo, l'HTTP risponde 200. Il ping ti sta mentendo.

Chi se ne accorge, invece, sono i tuoi agenti AI — e quindi i tuoi utenti. Ed è il momento peggiore per scoprirlo.

Questo articolo è la parte concettuale di una serie. Se vuoi passare subito alla pratica, c'è il tutorial per installare MCPSonar con Docker.

Cosa controlla davvero un monitoring "generico"

Gli strumenti di uptime tradizionali — UptimeRobot, un docker healthcheck, un ping TCP, una probe di Kubernetes — rispondono tutti alla stessa, unica domanda:

Il processo è in esecuzione e accetta connessioni?

È una domanda utile, ma è il livello più basso della piramide. Dice che il server esiste, non che funziona. Per un web server statico può bastare. Per un server MCP, che è una macchina a stati con un protocollo strutturato sopra, è drammaticamente insufficiente.

Il Model Context Protocol non è "una URL che risponde". È:

1. Un handshake (initialize) che negozia versione e capabilities.
2. Una superficie di tool dichiarata dinamicamente (tools/list).
3. Un contratto di esecuzione (tools/call) che deve restituire risultati validi.
4. Uno o più transport (http, SSE, stdio) con caratteristiche di affidabilità diverse.

Ognuno di questi livelli può rompersi indipendentemente dagli altri — e nessuno di essi si vede da un HTTP 200.

I quattro modi in cui un server MCP "verde" è in realtà rotto

1. Handshake fallito o incompatibile. Il server risponde, ma l'initialize va in errore, o dichiara una protocolVersion che i tuoi client non supportano. Risultato: nessun client riesce a completare la connessione, ma il tuo uptime resta al 100%.

2. Drift della superficie dei tool. Dopo un refactor, la tools/list cambia: un tool sparisce, cambia nome o cambia schema degli argomenti. Il server è "su", ma gli agenti che si aspettavano quel tool si rompono silenziosamente.

3. Tool vivi sulla carta, morti nei fatti. Il tool è ancora elencato, ma la sua implementazione dipende da un servizio esterno che è down. tools/list lo mostra; tools/call va in timeout. Solo chiamandolo davvero te ne accorgi.

4. Degrado di latenza e instabilità del transport. Il server risponde, ma in 8 secondi invece di 200 ms. Oppure la connessione SSE droppa a intermittenza. Tecnicamente "up", praticamente inutilizzabile per un agente che concatena decine di chiamate.

Il filo comune: per accorgersi di questi problemi bisogna parlare MCP, non limitarsi a bussare alla porta.

Monitoring protocol‑aware: parlare la lingua del protocollo

Un monitoring protocol‑aware non si limita a verificare la raggiungibilità. Fa quello che farebbe un vero client:

• esegue l'handshake initialize e registra la spec version dichiarata;
• chiama tools/list e tiene traccia di quali tool esistono, rilevando i cambiamenti nel tempo;
• test‑calla i tool configurati per provare che rispondano davvero, non solo che siano elencati;
• misura la latenza di ogni fase e la confronta con soglie di degraded / down;
• valida il server contro le regole specifiche della versione del protocollo.

La differenza è la stessa che passa tra "il ristorante ha le luci accese" e "ho chiamato, hanno risposto, ho prenotato e la prenotazione è confermata". Il primo è un segnale debole; il secondo è una prova.

Da qui è nato MCPSonar

MCPSonar è il tentativo di rendere concreto questo approccio in un tool self‑hosted e leggero. La filosofia in una riga la trovi già nel suo README:

Generic uptime tools tell you a process is alive. MCPSonar understands MCP.

In pratica, per ogni server configurato MCPSonar:

• esegue l'handshake e registra la spec version;
• elenca i tool e, opzionalmente, li chiama davvero per verificarne la risposta;
• traccia uptime e storico della latenza in una dashboard;
• supporta i transport http, SSE e stdio;
• si integra con Uptime Kuma, webhook generici e Prometheus per notifiche e metriche.

Il punto non è sostituire il tuo stack di observability, ma aggiungere il livello MCP che gli manca. Prometheus e Grafana restano ottimi per storico e alerting trasversale; MCPSonar aggiunge la vista che capisce l'handshake e i tool.

Quando ti serve (e quando no)

Non tutto ha bisogno di monitoring protocol‑aware. Un prototipo locale che gira sul tuo laptop probabilmente no. Ma nel momento in cui:

• esponi server MCP in produzione, usati da agenti reali;
• hai più server e più transport da tenere insieme;
• fai deploy frequenti che possono cambiare la superficie dei tool;
• hai bisogno di sapere che un problema c'è prima che lo scopra un utente,

allora il ping non basta più, e ti serve qualcosa che parli MCP.

Conclusione

Il monitoring classico risponde a "il processo è vivo?". Per i server MCP la domanda giusta è un'altra, più esigente: "l'handshake funziona, la spec version è quella attesa, i tool rispondono e la latenza è accettabile?". Sono quattro domande diverse, e solo un monitoring protocol‑aware sa rispondere a tutte.

Se vuoi vederlo all'opera, parti dal tutorial pratico con Docker. Se invece vuoi capire come funziona sotto il cofano, nei prossimi articoli scendo nel dettaglio dell'handshake MCP e del confronto tra i transport http, SSE e stdio.

MCPSonar è open source: dai un'occhiata al repository e lascia una stella se ti è utile.