Transport dei server MCP
MCP supporta meccanismi di trasporto per la comunicazione tra Bob Shell e i server MCP.
Panoramica
MCP offre tre opzioni di trasporto, ciascuna adatta a diversi scenari di deployment:
- Transport STDIO (server locali)
- Transport HTTP Streamable (standard moderno per server remoti)
- Transport SSE (opzione remota legacy)
Ogni transport ha caratteristiche, vantaggi e casi d'uso distinti.
Transport STDIO
Il transport STDIO viene eseguito localmente sulla tua macchina e comunica tramite flussi di input/output standard.
Come funziona il transport STDIO
- Bob avvia un server MCP come processo figlio
- La comunicazione avviene attraverso i flussi del processo: Bob scrive sullo STDIN del server, il server risponde sullo STDOUT
- Ogni messaggio è delimitato da un carattere di nuova riga
- I messaggi sono formattati come JSON-RPC 2.0
Client Server
| |
|---- messaggio JSON ---->| (via STDIN)
| | (elabora la richiesta)
|<---- messaggio JSON ----| (via STDOUT)
| |Caratteristiche di STDIO
- Località: Viene eseguito sulla stessa macchina di Bob
- Prestazioni: Latenza e overhead molto bassi (nessuno stack di rete coinvolto)
- Semplicità: Comunicazione diretta tra processi senza configurazione di rete
- Relazione: Relazione uno-a-uno tra client e server
- Sicurezza: Intrinsecamente più sicuro senza esposizione di rete
Quando usare STDIO
Il transport STDIO è ideale per:
- Integrazioni locali e strumenti in esecuzione sulla stessa macchina
- Operazioni sensibili alla sicurezza
- Requisiti di bassa latenza
- Scenari a client singolo (un'istanza Bob per server)
- Strumenti e script da riga di comando
Esempio di implementazione STDIO
const server = new Server({name: 'local-server', version: '1.0.0'});
// Registra gli strumenti...
// Usa il transport STDIO
const transport = new StdioServerTransport(server);
transport.listen();Transport HTTP Streamable
Il transport HTTP Streamable è lo standard moderno per la comunicazione remota con i server MCP, che sostituisce il precedente transport HTTP+SSE. Opera su HTTP/HTTPS e consente implementazioni server più flessibili.
Come funziona il transport HTTP Streamable
- Il server fornisce un singolo endpoint HTTP (endpoint MCP) che supporta sia il metodo POST che GET
- Bob invia richieste a questo endpoint MCP tramite HTTP POST
- Il server elabora la richiesta e invia una risposta
- Facoltativamente, il server può usare Server-Sent Events (SSE) sulla stessa connessione per inviare in streaming più messaggi o notifiche a Bob
Questo consente interazioni base richiesta-risposta così come comunicazioni in streaming e avviate dal server più avanzate.
Client Server
| |
|---- HTTP POST /mcp_endpoint ---->| (richiesta client)
| | (elabora la richiesta)
|<--- Risposta HTTP / Stream SSE --| (risposta / stream server)
| |Caratteristiche di HTTP Streamable
- Standard moderno: Metodo preferito per le nuove implementazioni di server MCP remoti
- Accesso remoto: Può essere ospitato su una macchina diversa da Bob
- Scalabilità: Può gestire più connessioni client contemporaneamente
- Protocollo: Funziona su HTTP/HTTPS standard
- Flessibilità: Supporta richiesta-risposta semplice e streaming avanzato
- Endpoint singolo: Usa un singolo percorso URL per tutta la comunicazione MCP
- Autenticazione: Può usare meccanismi di autenticazione HTTP standard
- Compatibilità con le versioni precedenti: I server possono mantenere la compatibilità con i client HTTP+SSE più vecchi
Quando usare HTTP Streamable
Il transport HTTP Streamable è ideale per:
- Tutti i nuovi sviluppi di server MCP remoti
- Server che richiedono comunicazione robusta, scalabile e flessibile
- Integrazioni che potrebbero coinvolgere dati in streaming o notifiche inviate dal server
- Servizi pubblici o strumenti centralizzati
- Sostituzione delle implementazioni legacy del transport SSE
Esempio di implementazione HTTP Streamable
Configurazione in ~/.bob/mcp_settings.json (globale) o .bob/mcp.json (progetto):
{
"mcpServers": {
"StreamableHTTPMCPName": {
"httpURL": "http://localhost:8080/mcp"
}
}
}Per l'implementazione lato server, consulta la documentazione dell'MCP SDK per StreamableHTTPClientTransport.
Compatibilità con le versioni precedenti di HTTP+SSE
Client e server possono mantenere la compatibilità con il transport HTTP+SSE deprecato.
I server che vogliono supportare i client più vecchi dovrebbero continuare a ospitare sia gli endpoint SSE (/events) che POST (/message) del vecchio transport, accanto al nuovo endpoint MCP definito per il transport HTTP Streamable.
Transport SSE (legacy)
Il transport Server-Sent Events (SSE) viene eseguito su un server remoto e comunica su HTTP/HTTPS. Per i nuovi server remoti, usa invece il transport HTTP Streamable.
Come funziona il transport SSE
- Bob si connette all'endpoint SSE del server tramite richiesta HTTP GET
- Questo stabilisce una connessione persistente tramite cui il server può inviare eventi a Bob
- Per la comunicazione dal client al server, Bob effettua richieste HTTP POST a un endpoint separato
- La comunicazione avviene su due canali:
- Flusso di eventi (GET): Aggiornamenti dal server al client
- Endpoint dei messaggi (POST): Richieste dal client al server
Client Server
| |
|---- HTTP GET /events ----------->| (stabilisce la connessione SSE)
|<---- flusso di eventi SSE -------| (connessione persistente)
| |
|---- HTTP POST /message --------->| (richiesta client)
|<---- evento SSE con risposta ----| (risposta server)
| |Caratteristiche di SSE
- Accesso remoto: Può essere ospitato su una macchina diversa da Bob
- Scalabilità: Può gestire più connessioni client contemporaneamente
- Protocollo: Funziona su HTTP standard (nessun protocollo speciale richiesto)
- Persistenza: Mantiene una connessione persistente per i messaggi dal server al client
- Autenticazione: Può usare meccanismi di autenticazione HTTP standard
Quando usare SSE
Il transport SSE è adatto per:
- Accesso remoto attraverso le reti
- Scenari multi-client
- Servizi pubblici
- Strumenti centralizzati a cui molti utenti devono accedere
- Integrazione con servizi web
Esempio di implementazione SSE
import express from 'express';
const app = express();
const server = new Server({name: 'remote-server', version: '1.0.0'});
// Registra gli strumenti...
// Usa il transport SSE
const transport = new SSEServerTransport(server);
app.use('/mcp', transport.requestHandler());
app.listen(3000, () => {
console.log('Server MCP in ascolto sulla porta 3000');
});Considerazioni sul deployment
La scelta tra STDIO e transport remoti (HTTP Streamable o SSE) influisce direttamente su come distribuisci e gestisci i tuoi server MCP.
STDIO: Deployment locale
I server STDIO vengono eseguiti localmente sulla stessa macchina di Bob:
- Installazione: L'eseguibile del server deve essere installato sulla macchina di ogni utente
- Distribuzione: Devi fornire pacchetti di installazione per diversi sistemi operativi
- Aggiornamenti: Ogni istanza deve essere aggiornata separatamente
- Risorse: Usa la CPU, la memoria e il disco della macchina locale
- Controllo accessi: Si basa sui permessi del filesystem della macchina locale
- Integrazione: Facile integrazione con le risorse del sistema locale (file, processi)
- Esecuzione: Si avvia e si arresta con Bob (ciclo di vita del processo figlio)
- Dipendenze: Tutte le dipendenze devono essere installate sulla macchina dell'utente
Esempio di caso d'uso:
Uno strumento di ricerca file locale che usa STDIO:
- Viene eseguito sulla tua macchina
- Ha accesso diretto al filesystem locale
- Si avvia quando necessario da Bob
- Non richiede configurazione di rete
- Deve essere installato accanto a Bob o tramite un package manager
Remoto: Deployment ospitato
I server remoti (HTTP Streamable o SSE) possono essere distribuiti su server remoti e accessibili tramite rete:
- Installazione: Installato una volta su un server, accessibile da molti utenti
- Distribuzione: Un singolo deployment serve più client
- Aggiornamenti: Gli aggiornamenti centralizzati interessano immediatamente tutti gli utenti
- Risorse: Usa le risorse del server, non quelle della macchina locale
- Controllo accessi: Gestito tramite sistemi di autenticazione e autorizzazione
- Integrazione: Integrazione più complessa con risorse specifiche dell'utente
- Esecuzione: Viene eseguito come servizio indipendente (spesso in modo continuo)
- Dipendenze: Gestite sul server, non sulle macchine degli utenti
Esempio di caso d'uso:
Uno strumento di query su database che usa il transport remoto:
- Viene eseguito su un server centrale
- Si connette ai database con credenziali lato server
- È continuamente disponibile per più utenti
- Richiede una corretta configurazione della sicurezza di rete
- Viene distribuito tramite tecnologie container o cloud
Approcci ibridi
Alcuni scenari traggono vantaggio da un approccio ibrido:
- STDIO con accesso di rete: Un server STDIO locale che funge da proxy per servizi remoti
- Remoto con comandi locali: Un server remoto che può attivare operazioni sulla macchina client tramite callback
- Pattern gateway: Server STDIO per operazioni locali che si connettono a server remoti per funzioni specializzate
Confronto tra transport
| Considerazione | STDIO | HTTP Streamable / SSE |
|---|---|---|
| Posizione | Solo macchina locale | Locale o remoto |
| Client | Client singolo | Più client |
| Prestazioni | Latenza minore | Latenza maggiore (overhead di rete) |
| Complessità di configurazione | Più semplice | Più complessa (richiede server HTTP) |
| Sicurezza | Intrinsecamente sicuro | Richiede misure di sicurezza esplicite |
| Accesso di rete | Non necessario | Obbligatorio |
| Scalabilità | Limitata alla macchina locale | Può distribuirsi sulla rete |
| Deployment | Installazione per utente | Installazione centralizzata |
| Aggiornamenti | Aggiornamenti distribuiti | Aggiornamenti centralizzati |
| Uso delle risorse | Usa le risorse del client | Usa le risorse del server |
| Dipendenze | Dipendenze lato client | Dipendenze lato server |
Configurare i transport in Bob Shell
Per informazioni dettagliate sulla configurazione dei transport in Bob Shell, inclusi esempi di configurazione, consulta MCP in Bob Shell.