MCP: Un Mese Dopo - Problemi, Alternative e Delusioni

Circa un mese fa, ho pubblicato un articolo dettagliato sul Model Context Protocol (MCP), presentandolo come “il nuovo standard per connettere LLM con strumenti esterni”. All’epoca, era impossibile non farsi trascinare dall’entusiasmo intorno a questa nuova specifica. Anthropic lo descriveva come “una porta USB-C per applicazioni AI”, promettendo di unificare il modo in cui i modelli linguistici interagiscono con il mondo esterno.

Ma come spesso accade con le tecnologie emergenti, dopo l’hype iniziale arriva il momento di fare i conti con la realtà dell’implementazione. Nelle ultime settimane, ho tentato di implementare un server MCP in Go, e quello che ho scoperto è stato sorprendente – e non in senso positivo.

In questo articolo, analizzerò criticamente i problemi di MCP emersi nell’ultimo mese, le alternative presentate da IBM e Google, e perché potremmo essere di fronte a un esempio di ingegneria software affrettata, con decisioni di design quanto meno discutibili.

Dalla Teoria alla Pratica: Il Viaggio Difficile di MCP

Quando ho scritto il mio primo articolo su MCP, mi sono concentrato principalmente sulla teoria del protocollo: la sua architettura, le sue promesse, i suoi possibili casi d’uso. Ma come spesso accade, i problemi emergono quando si passa dalla teoria alla pratica.

Nel mio tentativo di implementare un server MCP in Go, ho scoperto che la documentazione è lacunosa, le specifiche sono ambigue, e alcune decisioni di design sembrano prese più per dogma che per praticità.

Sono stupefatto dall’apparente mancanza di pratiche ingegneristiche mature. Aziende che spendono miliardi di dollari per addestrare e ottimizzare i loro modelli, per poi far scrivere la documentazione a stagisti, fornendo SDK scadenti e pochissime indicazioni sull’implementazione. Potrebbe essere un caso di “brillanti ricercatori AI, mediocri ingegneri software”?

Il Problema dei Trasporti: Una Discesa nella Follia

Nel mio articolo precedente, ho descritto i due meccanismi di trasporto standardizzati di MCP:

1. stdio: Comunicazione tramite standard input e output
2. HTTP Streamable: Comunicazione tramite richieste HTTP con supporto per Server-Sent Events (SSE)

Quello che non ho approfondito allora (e che è diventato drammaticamente chiaro nel frattempo) è che l’implementazione HTTP è incredibilmente problematica.

La Follia di “HTTP Streamable”

Attualmente, MCP supporta due versioni di trasporto HTTP:

1. HTTP+SSE: Il client configura una sessione SSE per leggere, riceve un URL dove scrivere, e poi usa l’endpoint fornito per inviare i messaggi.

2. Streamable HTTP: Un’evoluzione che usa un header HTTP per l’ID di sessione e semantica REST per l’endpoint.

Queste implementazioni sono così complesse che inizialmente ho pensato di averle fraintese. In “Streamable HTTP”, una nuova sessione può essere creata in TRE modi diversi, una connessione SSE può essere aperta in QUATTRO modi diversi, e una richiesta può ricevere risposta in TRE modi diversi.

Perché tutta questa complessità? Questo è tipico di un progetto che soffre di “feature creep” e di un’architettura non sufficientemente pianificata.

Ecco un semplice esempio di come funziona il trasporto “Streamable HTTP”:

1. Il client fa una richiesta GET o POST a /mcp che restituisce un header mcp-session-id=1234
2. Per inviare dati, il client fa richieste POST a /mcp aggiungendo l’header mcp-session-id=1234
3. La risposta potrebbe:
   • Aprire un nuovo stream SSE e pubblicare la risposta
   • Restituire un 200 con la risposta nel corpo
   • Restituire un 202, indicando che la risposta verrà scritta su uno qualsiasi degli stream SSE preesistenti

La complessità è tale che un’implementazione robusta richiede uno stato distribuito tra server, con implicazioni significative per la sicurezza e la scalabilità. In pratica, questo obbliga a implementare un sistema di accodamento dei messaggi solo per gestire il flusso di comunicazione.

La Soluzione Ovvia: WebSocket

La cosa più frustrante è che esiste già una soluzione perfetta per questo problema: WebSocket. Progettato specificamente per la comunicazione bidirezionale full-duplex su TCP, WebSocket è ideale per l’esatto scenario d’uso che MCP cerca di affrontare.

Eppure, gli autori di MCP hanno esplicitamente scelto di non utilizzare WebSocket, con motivazioni che sembrano più ideologiche che pratiche. In una PR su GitHub, hanno presentato argomenti contro WebSocket che sembrano facilmente confutabili o addirittura costruiti ad hoc.

Dato che abbiamo un protocollo JSON RPC, e Stdio è chiaramente preferito come protocollo di trasporto, dovremmo cercare di rendere il trasporto HTTP il più simile possibile a Stdio, e deviarne solo se assolutamente necessario.

In Stdio, abbiamo variabili d’ambiente; in HTTP, abbiamo header HTTP. In Stdio, abbiamo un comportamento socket-like con stream di input e output; in HTTP, abbiamo WebSocket.

È davvero così semplice. Perché complicare le cose?

La Competizione si Intensifica: ACP e A2A

Mentre MCP lotta con i suoi problemi di implementazione, altri attori stanno entrando nell’arena. IBM ha recentemente rilasciato l’Agent Communication Protocol (ACP), e Google ha annunciato Agent2Agent (A2A).

ACP di IBM: Realmente Necessario?

IBM descrive ACP come “ortogonale” a MCP, ma un’analisi più attenta rivela che molte delle funzionalità potrebbero essere implementate semplicemente come strumenti in un server MCP. Persino IBM sembra riconoscerlo:

“Gli agenti possono essere visti come risorse MCP e ulteriormente invocati come strumenti MCP. Tale visione degli agenti ACP consente ai client MCP di scoprire ed eseguire agenti ACP…”

Questo solleva la domanda: ACP è realmente necessario, o è semplicemente un tentativo di IBM di promuovere il proprio strumento di costruzione di agenti, BeeAI?

A2A di Google: Un’Altra Soluzione per lo Stesso Problema?

Google ha annunciato Agent2Agent (A2A), un protocollo che promette di facilitare la comunicazione tra agenti AI. Anche qui, molte delle funzionalità potrebbero probabilmente essere implementate nell’ambito di MCP con piccole aggiunte.

Tuttavia, sia ACP che A2A sembrano aver appreso dagli errori di MCP per quanto riguarda il livello di trasporto, optando per soluzioni più sane e pratiche.

Le Implicazioni per la Sicurezza

La complessa architettura di MCP Streamable HTTP introduce diverse preoccupazioni per la sicurezza:

1. Vulnerabilità nella Gestione dello Stato: Gestire lo stato della sessione tra diversi tipi di connessione (HTTP e SSE) è complesso e può portare a vulnerabilità come hijacking di sessione, attacchi di replay o attacchi DoS.

2. Superficie di Attacco Aumentata: I molteplici punti di ingresso per la creazione di sessioni e connessioni SSE espandono la superficie di attacco.

3. Confusione e Offuscamento: La varietà di modi per iniziare sessioni e consegnare risposte può essere usata per offuscare attività maligne.

Inoltre, il protocollo contiene requisiti opinabili su come dovrebbe essere gestita l’autorizzazione:

• Implementazioni che utilizzano un trasporto basato su HTTP DOVREBBERO conformarsi a questa specifica.
• Implementazioni che utilizzano un trasporto STDIO NON DOVREBBERO seguire questa specifica, ma invece recuperare le credenziali dall’ambiente.

Perché dovrei implementare OAuth2 se sto usando HTTP come trasporto, mentre una semplice API key è sufficiente per stdio?

MCP: Un Approccio Riduzionista alla Complessità

Dopo un mese di sperimentazione con MCP, sono giunto alla conclusione che il protocollo potrebbe essere vittima della sua stessa ambizione. Il tentativo di standardizzare la comunicazione tra LLM e strumenti esterni è lodevole, ma l’implementazione attuale è inutilmente complessa.

Come già detto nel post precedente, in fondo, cosa fa veramente MCP? Fornisce un modo standardizzato per dire a un LLM: “Ecco gli strumenti che puoi utilizzare, ecco come chiamarli” e potrebbe essere implementato con un semplice script Python di poche righe:

# Questo è letteralmente tutto ciò che serve, non un intero protocollo
def present_tools_to_llm(tools, user_query):
    tools_description = json.dumps([{
        "name": tool.name,
        "description": tool.description,
        "parameters": tool.parameters
    } for tool in tools])

    prompt = f"Hai a disposizione questi tool: {tools_description}\n\nDomanda dell'utente: {user_query}\n\nPuoi usare i tool se necessario per rispondere."
    return llm.generate(prompt)

È davvero necessario un intero protocollo standardizzato per qualcosa che può essere implementato in poche righe di codice?

La Reazione della Comunità

La buona notizia è che la comunità sta iniziando a riconoscere questi problemi. In un thread su GitHub, gli sviluppatori hanno iniziato a mettere in discussione le scelte di design di MCP, e alcuni hanno persino proposto alternative più semplici.

Anche se i grandi attori come Anthropic, Google e IBM continuano a promuovere i loro protocolli proprietari, gli sviluppatori sul campo stanno già cercando soluzioni più pragmatiche.

Siti come mcp.so e pulsemcp.com stanno raccogliendo implementazioni di client e server MCP, ma molti di questi sembrano concentrarsi più sulla parte facile del problema (il protocollo JSON-RPC) piuttosto che affrontare le complessità del trasporto.

MCP vs RAG: Non Sono la Stessa Cosa!

Come ho chiarito nel mio articolo precedente, MCP non è un’alternativa al RAG (Retrieval Augmented Generation). Sono tecnologie complementari che operano a livelli diversi. Questa distinzione è importante e vale la pena ribadirla:

• RAG è una tecnica per migliorare le risposte dei LLM recuperando e incorporando informazioni esterne rilevanti.
• MCP è un protocollo di comunicazione che standardizza come le applicazioni interagiscono con gli LLM e i loro strumenti.

Puoi utilizzare MCP per implementare un sistema RAG, ma MCP è molto più versatile e può supportare molti altri casi d’uso oltre al RAG.

La Specifica MCP: Manca il Collante Concettuale?

Avevo già accennato ad alcune criticità nella specifica MCP, ma ora è chiaro che il problema è più profondo. Le grandi specifiche tecniche del passato erano quasi una forma di letteratura tecnica: raccontavano una storia, non solo una tecnologia. Descrivevano il contesto, le sfide, il percorso di pensiero. La specifica MCP, al contrario, appare come un insieme di ’nozioncine appiccicate una all’altra’, priva del collante concettuale che dovrebbe tenere insieme il tutto.

Questa mancanza di visione d’insieme rende difficile per gli sviluppatori comprendere il vero scopo del protocollo e come dovrebbe essere implementato correttamente. Invece di fornire una guida chiara, la specifica sembra più un accumulo di funzionalità senza una direzione coerente.

Agenti AI: Hype o Realtà?

Nel mio articolo precedente, ho descritto gli agenti AI come una “sinergia naturale” con MCP. Un mese dopo, sono meno convinto di questa affermazione.

Qual è la differenza fondamentale tra utilizzo intelligente dei modelli e ‘agenti’?

In un’interazione normale, un utente esperto usa il modello per potenziare la propria capacità cognitiva, mantenendo il controllo e indirizzando l’interazione. Un agente, invece, è essenzialmente l’opposto: si concede al modello (ancora imperfetto) di “frullare” in autonomia, scrivendo file, leggendoli, implementando soluzioni e debuggandosi da solo.

Il risultato? Spesso un minestrone di self-debugging/coding in cui l’essere umano non contribuisce quasi nulla, e la qualità del risultato è generalmente inferiore.

Il CEO di Anthropic, tra i principali promotori di MCP, ha recentemente affermato che “la maggior parte del codice sarà scritto da LLM entro un anno”. Questa fiducia incrollabile negli agenti AI sembra essere uno dei principali motori dietro lo sviluppo di MCP, ma è davvero giustificata?

Lo Stato Attuale dell’Ecosistema

Nonostante le criticità, l’ecosistema intorno a MCP continua a crescere. Nuovi strumenti e implementazioni vengono pubblicati quotidianamente, e la comunità sta lentamente trovando modi per aggirare le limitazioni del protocollo.

Tuttavia, la frammentazione nel panorama dei protocolli AI sta diventando una preoccupazione crescente. Per la serie:

“Ci sono 14 standard concorrenti, quindi creiamo uno standard universale che li copra tutti. Ora ci sono 15 standard concorrenti.”

Per gli sviluppatori, questa frammentazione rappresenta un problema reale. Quale protocollo dovrebbero adottare? MCP, con le sue questioni di implementazione? ACP, che potrebbe essere solo un veicolo promozionale per BeeAI? A2A, l’ultimo arrivato da Google?

Conclusioni: Dove Andremo a Finire?

Io sono giunto a diverse conclusioni:

1. MCP ha un grande potenziale, ma è ostacolato da scelte di design discutibili e una documentazione lacunosa.

2. WebSocket sarebbe stata la scelta naturale per il trasporto HTTP, e il rifiuto di utilizzarlo sembra più ideologico che pratico.

3. La proliferazione di protocolli concorrenti (MCP, ACP, A2A) rischia di frammentare ulteriormente l’ecosistema.

4. La complessità di MCP non è giustificata dal valore che aggiunge rispetto a soluzioni più semplici.

Per il futuro, spero che la comunità si orienti verso soluzioni più semplici e pratiche. Occorre ottimizzare per i casi d’uso più comuni, non i casi limite.

Nel frattempo, se stai considerando di implementare MCP, ti consiglio di procedere con cautela. Il protocollo è ancora in evoluzione, e molte delle sue complessità potrebbero essere evitate con approcci più semplici e diretti.

E tu, cosa ne pensi di MCP e degli altri protocolli emergenti? Hai esperienze dirette con la loro implementazione? Condividi i tuoi pensieri nei commenti!

Nota: Questa analisi è basata sulle mie esperienze personali e sulle opinioni condivise da altri sviluppatori. Il panorama dei protocolli AI è in rapida evoluzione, e alcuni dei problemi menzionati potrebbero essere stati risolti nel momento in cui stai leggendo questo articolo.