Trasporti Server MCP
MCP supporta meccanismi di trasporto per la comunicazione tra Bob e i server MCP.
Panoramica
MCP offre tre opzioni di trasporto, ciascuna adatta a diversi scenari di distribuzione:
- Trasporto STDIO (server locali)
- Trasporto HTTP Streamable (standard moderno per server remoti)
- Trasporto SSE (rimosso)
Ogni trasporto ha caratteristiche, vantaggi e casi d'uso diversi.
Trasporto STDIO
Il trasporto STDIO viene eseguito localmente sul tuo computer e comunica tramite flussi di input/output standard.
Come funziona il trasporto STDIO
- Bob avvia un server MCP come processo figlio
- La comunicazione avviene tramite flussi di processo: Bob scrive su STDIN del server, il server risponde su STDOUT
- Ogni messaggio è delimitato da un carattere di nuova riga
- I messaggi sono formattati come JSON-RPC 2.0
Client Server
| |
|---- Messaggio JSON ---->| (tramite STDIN)
| | (elabora richiesta)
|<---- Messaggio JSON ----| (tramite STDOUT)
| |Caratteristiche 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 trasporto STDIO è ideale per:
- Integrazioni e strumenti locali che vengono eseguiti sulla stessa macchina
- Operazioni critiche per la sicurezza
- Requisiti a bassa latenza
- Scenari a client singolo (un'istanza di Bob per server)
- Strumenti da riga di comando o estensioni IDE
Esempio di implementazione STDIO
const server = new Server({name: 'local-server', version: '1.0.0'});
// Registra strumenti...
// Usa trasporto STDIO
const transport = new StdioServerTransport(server);
transport.listen();Trasporto HTTP Streamable
Il trasporto HTTP Streamable è lo standard moderno per la comunicazione con server MCP remoti, sostituendo il vecchio trasporto HTTP+SSE. Opera su HTTP/HTTPS e consente implementazioni server più flessibili.
Come funziona il trasporto HTTP Streamable
- Il server fornisce un singolo endpoint HTTP (endpoint MCP) che supporta sia metodi POST che GET
- Bob invia richieste a questo endpoint MCP con HTTP POST
- Il server elabora la richiesta e invia una risposta
- Opzionalmente, il server può utilizzare Server-Sent Events (SSE) sulla stessa connessione per trasmettere più messaggi o notifiche a Bob
Questo consente sia interazioni base richiesta-risposta che streaming avanzato e comunicazione avviata dal server.
Client Server
| |
|---- HTTP POST /mcp_endpoint ---->| (Richiesta client)
| | (elabora richiesta)
|<--- HTTP Response / SSE Stream --| (Risposta server / Stream)
| |Caratteristiche HTTP Streamable
- Standard moderno: Metodo preferito per nuove implementazioni di server MCP remoti
- Accesso remoto: Può essere ospitato su una macchina diversa da Bob
- Scalabilità: Può gestire più connessioni client simultaneamente
- Protocollo: Funziona su HTTP/HTTPS standard
- Flessibilità: Supporta sia richiesta-risposta semplice che streaming avanzato
- Endpoint singolo: Utilizza un singolo percorso URL per tutta la comunicazione MCP
- Autenticazione: Può utilizzare meccanismi di autenticazione HTTP standard
- Retrocompatibilità: I server possono mantenere la compatibilità con client HTTP+SSE più vecchi
Quando usare HTTP Streamable
Il trasporto HTTP Streamable è ideale per:
- Tutti i nuovi sviluppi di server MCP remoti
- Server che richiedono comunicazione robusta, scalabile e flessibile
- Integrazioni che possono coinvolgere dati in streaming o notifiche inviate dal server
- Servizi pubblici o strumenti centralizzati
- Sostituzione di implementazioni di trasporto SSE legacy
Negoziazione del protocollo
Quando Bob si connette a un server HTTP Streamable, utilizza l'opzione protocolNegotiation per determinare come concordare una versione del protocollo. I server HTTP usano "auto" come predefinito.
| Valore | Descrizione |
|---|---|
"auto" | Bob invia una sonda server/discover prima di initialize per negoziare la versione del protocollo più alta supportata da entrambi. Predefinito per i server HTTP. |
"legacy" | Bob salta la sonda e si connette direttamente usando l'handshake initialize, compatibile con tutti i server MCP. |
{ "pin": "<versione>" } | Bob si connette usando una versione specifica del protocollo (per esempio, { "pin": "2024-11-05" }). |
Se un server HTTP va in timeout con MCP connection timed out after 10000ms, il server potrebbe non rispondere alla sonda server/discover. Imposta "protocolNegotiation": "legacy" per saltare la sonda:
{
"mcpServers": {
"my-server": {
"url": "https://tuo-url-server.com/mcp",
"protocolNegotiation": "legacy"
}
}
}Per maggiori dettagli, vedi Negoziazione del protocollo in "Utilizzare MCP in Bob".
Esempio di implementazione HTTP Streamable
Configurazione in settings.json:
{
"mcpServers": {
"StreamableHTTPMCPName": {
"type": "streamable-http",
"url": "http://localhost:8080/mcp"
}
}
}Per l'implementazione lato server, consulta la documentazione MCP SDK per StreamableHTTPClientTransport.
Retrocompatibilità con HTTP+SSE
Il client MCP di Bob non ricade sul trasporto HTTP+SSE. Le indicazioni seguenti sono per gli autori di server che desiderano che il loro server Streamable HTTP rimanga accessibile ai client più vecchi che non supportano ancora Streamable HTTP.
I server che devono supportare client più vecchi dovrebbero continuare a ospitare sia gli endpoint SSE (/events) che POST (/message) del vecchio trasporto accanto al nuovo endpoint MCP definito per il trasporto HTTP Streamable.
Trasporto SSE (rimosso)
Il client MCP di Bob non supporta più il trasporto HTTP+SSE standalone (specifica MCP 2024-11-05). I server che usano solo il trasporto HTTP+SSE non possono connettersi a Bob.
SSE come canale di risposta all'interno di una connessione Streamable HTTP è ancora supportato. Bob può ricevere stream SSE da un server Streamable HTTP. Solo il trasporto HTTP+SSE standalone (con endpoint /events e /message separati) è stato rimosso.
Migrazione dal trasporto SSE
Se hai un server esistente che usa il trasporto HTTP+SSE, esegui la migrazione al trasporto HTTP Streamable o al trasporto STDIO:
- Streamable HTTP: Esponi un singolo endpoint MCP che accetta richieste HTTP POST. Questo è il percorso consigliato per i server remoti. Vedi Trasporto HTTP Streamable.
- STDIO: Se il server viene eseguito localmente sulla stessa macchina di Bob, convertilo in un server STDIO. Vedi Trasporto STDIO.
Considerazioni sulla distribuzione
La scelta tra STDIO e il trasporto HTTP Streamable influisce direttamente su come distribuisci e gestisci i tuoi server MCP.
STDIO: Distribuzione locale
I server STDIO vengono eseguiti localmente sulla stessa macchina di Bob:
- Installazione: Il file eseguibile del server deve essere installato sul computer di ogni utente
- Distribuzione: Devi fornire pacchetti di installazione per diversi sistemi operativi
- Aggiornamenti: Ogni istanza deve essere aggiornata separatamente
- Risorse: Utilizza CPU, memoria e disco della macchina locale
- Controllo accessi: Si basa sui permessi del filesystem della macchina locale
- Integrazione: Facile integrazione con risorse di sistema locali (file, processi)
- Esecuzione: Si avvia e si ferma con Bob (ciclo di vita del processo figlio)
- Dipendenze: Tutte le dipendenze devono essere installate sul computer dell'utente
Esempio di caso d'uso:
Uno strumento di ricerca file locale con STDIO:
- Verrebbe eseguito sul computer dell'utente
- Avrebbe accesso diretto al filesystem locale
- Verrebbe avviato da Bob quando necessario
- Non richiederebbe configurazione di rete
- Dovrebbe essere installato insieme a Bob o tramite un gestore di pacchetti
Remoto: Distribuzione ospitata
I server remoti (HTTP Streamable) possono essere distribuiti su server remoti e richiamati attraverso la rete:
- Installazione: Installato una volta su un server, richiamato da molti utenti
- Distribuzione: Una singola distribuzione serve più client
- Aggiornamenti: Aggiornamenti centralizzati influenzano tutti gli utenti immediatamente
- Risorse: Utilizza risorse del server, non risorse 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 continuamente)
- Dipendenze: Gestite sul server, non sulle macchine degli utenti
Esempio di caso d'uso:
Uno strumento di query database con trasporto remoto:
- Verrebbe eseguito su un server centrale
- Si connetterebbe ai database con credenziali lato server
- Sarebbe continuamente disponibile per più utenti
- Richiederebbe una corretta configurazione della sicurezza di rete
- Verrebbe distribuito con tecnologie container o cloud
Approcci ibridi
Alcuni scenari beneficiano di 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 funzionalità specializzate
Confronto trasporti
| Considerazione | STDIO | HTTP Streamable |
|---|---|---|
| Posizione | Solo macchina locale | Locale o remoto |
| Client | Client singolo | Client multipli |
| Prestazioni | Latenza inferiore | Latenza superiore (overhead di rete) |
| Complessità configurazione | Più semplice | Più complessa (richiede server HTTP) |
| Sicurezza | Intrinsecamente sicuro | Richiede misure di sicurezza esplicite |
| Accesso di rete | Non richiesto | Richiesto |
| Scalabilità | Limitato alla macchina locale | Può essere distribuito attraverso la rete |
| Distribuzione | Installazione per utente | Installazione centralizzata |
| Aggiornamenti | Aggiornamenti distribuiti | Aggiornamenti centralizzati |
| Utilizzo risorse | Utilizza risorse client | Utilizza risorse server |
| Dipendenze | Dipendenze lato client | Dipendenze lato server |
Configurare i trasporti in Bob
Per informazioni dettagliate sulla configurazione dei trasporti in Bob, incluse configurazioni di esempio, consulta MCP in Bob.
Comprendere MCP
Il Model Context Protocol (MCP) è un protocollo di comunicazione standardizzato che consente ai sistemi AI di interagire con strumenti e servizi esterni.
Utilizzare MCP in Bob
Il Model Context Protocol (MCP) estende le capacità di Bob connettendosi a strumenti e servizi esterni. Questa guida ti mostra come configurare, gestire e utilizzare i server MCP con Bob.