Trasporti 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 (opzione remota legacy)

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

1. Bob avvia un server MCP come processo figlio
2. La comunicazione avviene tramite flussi di processo: Bob scrive su STDIN del server, il server risponde su STDOUT
3. Ogni messaggio è delimitato da un carattere di nuova riga
4. 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

1. Il server fornisce un singolo endpoint HTTP (endpoint MCP) che supporta sia metodi POST che GET
2. Bob invia richieste a questo endpoint MCP con HTTP POST
3. Il server elabora la richiesta e invia una risposta
4. 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

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

Client e server possono mantenere la retrocompatibilità con il trasporto HTTP+SSE obsoleto.

I server che desiderano supportare client più vecchi dovrebbero continuare a ospitare sia gli endpoint SSE (/events) che POST (/message) del vecchio trasporto, oltre al nuovo endpoint MCP definito per il trasporto HTTP Streamable.

Trasporto SSE (Legacy)

Il trasporto Server-Sent Events (SSE) viene eseguito su un server remoto e comunica tramite HTTP/HTTPS. Per nuovi server remoti, usa invece il trasporto HTTP Streamable.

Come funziona il trasporto SSE

1. Bob si connette all'endpoint SSE del server tramite una richiesta HTTP GET
2. Questo stabilisce una connessione persistente attraverso la quale il server può inviare eventi a Bob
3. Per la comunicazione client-server, Bob invia richieste HTTP POST a un endpoint separato
4. La comunicazione avviene su due canali:
   • Flusso di eventi (GET): Aggiornamenti server-client
   • Endpoint messaggi (POST): Richieste client-server

Client                             Server
  |                                  |
  |---- HTTP GET /events ----------->| (Stabilisce connessione SSE)
  |<---- Flusso eventi SSE -----------| (connessione persistente)
  |                                  |
  |---- HTTP POST /message --------->| (Richiesta client)
  |<---- Evento SSE con risposta ----| (Risposta server)
  |                                  |

Caratteristiche SSE

• Accesso remoto: Può essere ospitato su una macchina diversa da Bob
• Scalabilità: Può gestire più connessioni client simultaneamente
• Protocollo: Funziona su HTTP standard (nessun protocollo speciale richiesto)
• Persistenza: Mantiene una connessione persistente per messaggi server-client
• Autenticazione: Può utilizzare meccanismi di autenticazione HTTP standard

Quando usare SSE

Il trasporto SSE è adatto per:

• Accesso remoto attraverso reti
• Scenari multi-client
• Servizi pubblici
• Strumenti centralizzati a cui devono accedere molti utenti
• 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 strumenti...

// Usa trasporto SSE
const transport = new SSEServerTransport(server);
app.use('/mcp', transport.requestHandler());
app.listen(3000, () => {
  console.log('Server MCP in ascolto sulla porta 3000');
});

Considerazioni sulla distribuzione

La scelta tra trasporti STDIO e remoti (HTTP Streamable o SSE) 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 o SSE) 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:

1. STDIO con accesso di rete: Un server STDIO locale che funge da proxy per servizi remoti
2. Remoto con comandi locali: Un server remoto che può attivare operazioni sulla macchina client tramite callback
3. Pattern gateway: Server STDIO per operazioni locali che si connettono a server remoti per funzionalità specializzate

Confronto trasporti

Configurare i trasporti in Bob

Per informazioni dettagliate sulla configurazione dei trasporti in Bob, incluse configurazioni di esempio, consulta MCP in Bob.