Introduzione
MCP separa il cosa (i messaggi JSON‑RPC: initialize, tools/list, tools/call…) dal come (il canale su cui quei messaggi viaggiano). Quel "come" è il transport, e la scelta non è neutrale: cambia dove gira il server, come lo autentichi, quanto è affidabile e — dettaglio spesso trascurato — come lo monitori.
In questo articolo mettiamo a confronto i tre transport che incontri più spesso, gli stessi che MCPSonar sa gestire: stdio, http e SSE.
Questo pezzo chiude la serie su MCP e monitoring: prima abbiamo visto perché l'uptime non basta e l'anatomia dell'handshake.
stdio — il transport locale
Con il transport stdio, il client lancia il server come processo figlio e comunica con lui tramite standard input e standard output. I messaggi JSON‑RPC scorrono su stdin/stdout, riga per riga.
È il transport nato con MCP ed è ancora il più comune per i tanti server distribuiti come pacchetti:
npx -y @modelcontextprotocol/server-everything
Vantaggi:
- Zero networking: nessuna porta, nessun TLS, nessun problema di firewall.
- Isolamento naturale: il server vive e muore col processo che lo lancia.
- Semplicissimo da distribuire (un comando
npxouvx).
Svantaggi:
- È locale: il server deve girare sulla stessa macchina del client.
- Non è pensato per essere condiviso tra più client contemporaneamente.
- Richiede l'ambiente giusto sull'host (Node per
npx, Python peruvx).
Uso tipico: tool per assistenti desktop (es. Claude Desktop), integrazioni locali, sviluppo.
http — il transport di rete
Il transport basato su HTTP espone il server dietro una URL. Il client invia i messaggi JSON‑RPC con richieste HTTP e riceve le risposte nel corpo della risposta. È l'approccio moderno per i server MCP remoti, ospitati su un server o in cloud.
servers:
my-http-server:
url: "https://example.com/mcp"
transport: "http"
headers:
Authorization: "Bearer <token>"
Vantaggi:
- Remoto e condivisibile: un solo server per molti client, ovunque nel mondo.
- Si appoggia a tutta l'infrastruttura HTTP che già conosci: TLS, reverse proxy, load balancer, header di autenticazione.
- Facile da mettere dietro autenticazione (Bearer token, API key).
Svantaggi:
- Devi gestire networking, certificati e sicurezza.
- Introduce latenza di rete, da tenere d'occhio.
Uso tipico: server MCP in produzione, multi‑utente, esposti come servizio.
SSE — lo streaming server → client
SSE (Server‑Sent Events) è il transport HTTP che aggiunge un canale di streaming dal server verso il client: il server può inviare messaggi in modo asincrono su una connessione persistente, mentre il client invia le sue richieste con normali POST.
servers:
my-sse-server:
url: "https://example.com/sse"
transport: "sse"
Vantaggi:
- Supporta messaggi push dal server (notifiche, risultati in streaming).
- Sempre su HTTP: eredita TLS e infrastruttura web.
Svantaggi:
- La connessione persistente è più fragile: può droppare, e va gestita la riconnessione.
- Reverse proxy e load balancer vanno configurati con attenzione (buffering, timeout).
- È il modello HTTP "storico" di MCP, progressivamente affiancato/superato dai transport HTTP più recenti con streaming integrato.
Uso tipico: scenari remoti dove serve streaming dal server, o compatibilità con server MCP che espongono ancora l'endpoint SSE.
Nota sulle versioni: l'ecosistema dei transport HTTP di MCP si è evoluto (da HTTP+SSE verso lo Streamable HTTP). Verifica sempre cosa espone il server che stai integrando e cosa richiede la versione della spec che usi.
Il confronto in una tabella
| Aspetto | stdio | http | SSE | |---|---|---|---| | Dove gira il server | Locale (processo figlio) | Remoto (URL) | Remoto (URL) | | Networking | Nessuno | HTTP/TLS | HTTP/TLS | | Multi‑client | No | Sì | Sì | | Streaming server→client | Limitato | Dipende | Sì (nativo) | | Autenticazione | Ambiente locale | Header HTTP | Header HTTP | | Affidabilità connessione | Alta (locale) | Alta | Media (connessione persistente) | | Uso tipico | Desktop, dev | Produzione remota | Streaming remoto |
Cosa cambia per il monitoring
Ogni transport si rompe in modo diverso, e un monitoring protocol‑aware deve tenerne conto:
- stdio — il rischio non è la rete ma l'ambiente:
npx/uvxnon installati, comando sbagliato, processo che non parte. MCPSonar lancia il comando a ogni check, quindi intercetta proprio questi fallimenti di avvio. - http — qui contano latenza di rete, scadenza dei certificati e header di auth. Un check deve verificare non solo che l'endpoint risponda, ma che l'handshake si completi entro le soglie di latenza.
- SSE — la stabilità della connessione persistente è il punto debole: droppa? si riconnette? Un monitoring che apre davvero il canale se ne accorge, un ping no.
È questo il motivo per cui in MCPSonar il transport è un parametro esplicito nella configurazione del server: il check si adatta al canale.
servers:
local-tool:
transport: "stdio"
command: "npx"
args: ["-y", "@modelcontextprotocol/server-everything"]
remote-api:
transport: "http"
url: "https://example.com/mcp"
headers:
Authorization: "Bearer <token>"
Quale scegliere
Una regola pratica:
- Sviluppo locale o tool desktop? → stdio. Semplice, zero networking.
- Server in produzione, multi‑utente? → http. Remoto, autenticabile, scalabile.
- Serve streaming dal server o compatibilità con endpoint esistenti? → SSE (verificando sempre cosa supporta la versione della spec).
Non c'è un vincitore assoluto: c'è il transport giusto per il tuo scenario. E qualunque scegli, il monitoraggio dovrebbe parlarne la lingua.
Conclusione
stdio, http e SSE sono tre modi diversi di far viaggiare gli stessi messaggi MCP, con trade‑off diversi su località, affidabilità e streaming. Sapere come si comportano — e come falliscono — ti aiuta sia a progettare la tua integrazione sia a monitorarla come si deve.
Con questo si chiude la serie su MCP e monitoring. Se vuoi passare dalla teoria alla pratica, parti dal tutorial per installare MCPSonar con Docker e configura i tuoi server, qualunque transport usino.
MCPSonar è open source e supporta tutti e tre i transport: dai un'occhiata al repository.