Il tuo agente AI si impalla su uno strumento ‘summarize’. Due secondi svaniscono nel nulla. Colpa del codice? Dell’API? Oppure — nascosto — dell’LLM a cui il server ha delegato il lavoro?
Per gli sviluppatori che assemblano workflow agentici, questa è la routine con i server MCP. Senza visibilità sulle chiamate di sampling, era tutto un gioco d’indovinelli sulle performance. Ora? Le tracce illuminano quei fantasmi, le metriche sul dashboard dicono tutta la verità, e ottimizzare smette di essere magia nera.
Perché il Sampling MCP Rompeva le Tue Tracce
Le specifiche MCP permettono ai server — privi di chiavi API — di rimandare il lavoro LLM ai client. Furbo, no? Il tuo orchestratore chiama ‘summarize’; il server ha bisogno di GPT-4o per masticare il testo; fa sampling sull’LLM del client. La risposta torna indietro. Delega pulita.
Ma le tracce? Silenzio totale. Il middleware cattura bene le chiamate tool. Lo sampling? Una invocazione di metodo sepolta nelle viscere dell’handler. Niente span. Uno strumento da 2,1 secondi dove 1,8 secondi bruciano sulla generazione — invisibili. Ti metti a ottimizzare i 300 ms sbagliati.
«La chiamata tool innesca una chiamata LLM invisibile nella traccia. Il middleware dell’articolo #7 traccia tools/call summarize — ma la chiamata sampling al suo interno? Fantasma. Niente span, niente durata, niente nome modello.»
Quella era la scatola nera che hanno scoperchiato la volta scorsa. Questa? Il seguito che la rende pronta per la demo.
Guardate, questo film l’abbiamo già visto. All’inizio i microservizi soffocavano su RPC non tracciati — vi ricordate l’ascesa di Zipkin? Lo sampling MCP è l’RPC dell’AI agentica. Lo ignori, e i tuoi tool diventano misteri distribuiti. Lo sistemi ora, e sei avanti sulla mandria multi-agente in arrivo.
Come Hanno Avvolto Quelle Chiamate Fantasma
Quattro ritocchi. Semplicissimi.
Prima, toadEyeMiddleware per le basi — span su ogni tool.
Poi, il wrapper traceSampling intorno a ctx.mcpReq.requestSampling(). Passa modello, token. Boom: span SpanKind.CLIENT chiamato “chat gpt-4o”. Cattura durata (1834 ms!), gen_ai.request.model, persino mcp.server.name.
Nidificazione perfetta:
tools/call summarize 2.1s └── chat gpt-4o (sampling) 1.8s
Logica vera? 300 ms. Ottimizza quella, non i fantasmi.
Il codice è un’import in una riga. Nel body dell’handler: wrappa il tuo sampling. Cinque minuti per provarlo — server su, agente client che pinga, tracce che fioccano nel tuo backend OTel.
Ma le metriche? Lì diventa affilato come Bloomberg. Query Prometheus integrate. Niente contatori vaghi.
Il Dashboard che Risponde a ‘Cosa Sta Saltando?’
Tabella sbirciabile in cima:
Tasso Chiamate Tool | Durata Media | Tasso Errori | Letture Risorse 12.4 req/s | 45.2 ms | 2.3% | 3.1 req/s
Rosso sugli errori? Scava dentro.
Timeseries per tassi di chiamata per tool. L’agente passa da calculate a search? Le linee lo mostrano. Durate P50/P95 per tool — P95 di search che schizza a 2s? Pager duty in arrivo.
Errori impilati: RateLimitError su search (8.7%), Validation su calculate (0%). Risorse per URI — fonti dati roventi.
In fondo: tabella unificata per tool.
| Tool | Tasso | Media (ms) | P95 (ms) | Errori |
|---|---|---|---|---|
| calculate | 8.2 | 12.3 | 24.1 | 0% |
| get-weather | 3.1 | 145.2 | 312.8 | 3.2% |
| search | 1.1 | 890.4 | 2134 | 8.7% |
Non è roba di contorno. È la vista per la sala riunioni: costi legati alle durate, errori a perdite di revenue. Scala gli agenti? Ringrazierai queste quattro statistiche.
È Questo il Momento Zipkin per gli Agenti AI?
Ecco il mio asso: nessuno lo dice, ma l’osservabilità MCP è anni luce dietro a LangChain — quegli ecosistemi tracciano tutto, hype o no. La specifica MCP più pura brilla, ma i tool nascondevano gemme come lo sampling.
Previsione? Con gli agenti che incatenano server (multi-MCP in arrivo), questo tracciamento diventa requisito base. Lo ignori, i tuoi agenti in prod vanno al buio sotto ca
