Nel panorama attuale dell’IA, un concetto sta generando un notevole fermento: MCP, o Model Context Protocol. Sorprendentemente, l’attenzione che circonda questo sistema di protocollo ha oscurato persino le ultime versioni dei modelli di OpenAI, diventando un punto focale delle discussioni del settore.
L’aumento di popolarità della tecnologia Agent, stimolato dall’ascesa di Manus, ha alimentato l’entusiasmo degli sviluppatori globali. MCP, posizionato come un ‘protocollo unificato’ per l’invocazione di strumenti Agent, ha rapidamente guadagnato terreno, assicurandosi il supporto dei principali attori dell’IA come OpenAI e Google in soli due mesi. Questa rapida ascesa ha trasformato MCP da una specifica tecnica relativamente oscura a uno standard fondamentale all’interno dell’ecosistema IA, segnando un ‘evento fenomenale’ nel regno dell’infrastruttura IA.
Tuttavia, con il placarsi dell’eccitazione iniziale, emergono domande critiche: MCP è davvero universalmente applicabile? Le aspettative per le sue capacità sono diventate gonfiate?
Questa esplorazione approfondisce le origini di MCP, sezionando i suoi punti di forza e le sue limitazioni fondamentali, chiarendo le idee sbagliate prevalenti ed esaminando la sua potenziale traiettoria futura. L’obiettivo non è quello di respingere il valore intrinseco di MCP, ma piuttosto di promuovere una comprensione più radicata del suo ruolo e dei suoi confini. È solo attraverso tale chiarezza che il suo potenziale può essere pienamente realizzato.
Svelare MCP: Un Protocollo Unificato di Invocazione di Strumenti
Definizione di MCP
MCP è un protocollo tecnico aperto progettato per standardizzare il modo in cui i Large Language Models (LLM) interagiscono con strumenti e servizi esterni. Pensatelo come un traduttore universale all’interno del mondo dell’IA, che consente ai modelli di IA di ‘conversare’ con un’ampia gamma di strumenti esterni. Fornisce un linguaggio e una struttura comuni per consentire agli LLM di richiedere e utilizzare le funzionalità offerte da diverse applicazioni e servizi.
La Necessità di MCP
Prima dell’avvento di MCP, l’invocazione di strumenti AI era afflitta da due sfide principali:
- Frammentazione dell’Interfaccia: Ogni LLM impiegava formati di istruzioni distinti, mentre ogni API di strumenti aveva le sue strutture di dati univoche. Gli sviluppatori erano costretti a scrivere codice di connessione personalizzato per ogni combinazione, portando a un processo di sviluppo complesso e inefficiente.
- Inefficienza dello Sviluppo: Questo approccio di ‘traduzione uno-a-uno’ si è rivelato costoso e difficile da scalare. Era come assumere un traduttore dedicato per ogni cliente straniero, ostacolando la produttività e l’agilità.
MCP affronta questi punti dolenti fornendo un quadro standardizzato per consentire agli LLM di interagire con strumenti esterni, semplificando il processo di sviluppo e consentendo una maggiore scalabilità.
Comprensione della Funzionalità di MCP
L’architettura tecnica di MCP può essere concettualizzata come un sistema composto da tre componenti principali: MCP Host, MCP Client e MCP Server. Questi elementi lavorano in sinergia per facilitare una comunicazione senza interruzioni tra i modelli di IA e il mondo esterno.
Per comprendere il ruolo di MCP, si consideri un moderno ambiente aziendale. In questa analogia:
- Gli Utenti rappresentano i dirigenti senior, responsabili della comprensione delle esigenze degli utenti e dell’assunzione delle decisioni finali.
- I Large Language Models (LLM) (come Claude o GPT) comprendono le istruzioni dei dirigenti, pianificano le fasi delle attività, determinano quando utilizzare servizi esterni e consolidano le informazioni per fornire risposte.
- I Sistemi Agent funzionano come assistenti personali o segretari esecutivi, eseguendo le attività come indicato.
- MCP funge da piattaforma di comunicazione standardizzata o sistema di accesso ai servizi aziendali utilizzato dai segretari. Non prende decisioni, ma segue invece le istruzioni, comunicando con vari fornitori di servizi in un formato e un protocollo unificati.
Prima di MCP, l’interazione dell’IA con strumenti esterni era simile a un’era di standard di comunicazione caotici. Ogni volta che un segretario (Agent) aveva bisogno di contattare un diverso dipartimento o fornitore esterno, doveva utilizzare un diverso dispositivo o software di comunicazione. Ciò richiedeva familiarità con diversi sistemi, con conseguenti inefficienze. Gli sviluppatori dovevano scrivere codici di connessione separati per ogni strumento, portando a tempo sprecato e scalabilità limitata.
MCP semplifica questo processo fornendo una piattaforma di comunicazione unificata, consentendo ai segretari di contattare qualsiasi dipartimento o fornitore di servizi utilizzando lo stesso sistema e protocollo di comunicazione. Gli sviluppatori devono solo implementare l’interfaccia MCP una volta, consentendo ai sistemi AI di interagire con tutti gli strumenti che supportano il protocollo.
MCP: Una Cassetta degli Attrezzi Basata su Function Call
È fondamentale capire che MCP non è un sostituto del tradizionale Function Call; piuttosto, è un componente complementare che ne aumenta le capacità.
Function Call è il meccanismo principale con cui gli LLM interagiscono con strumenti o API esterni. È una capacità fondamentale degli LLM, che consente loro di identificare quando è necessario uno strumento e quale tipo di strumento è richiesto.
MCP funge da sistema di classificazione degli strumenti, fornendo un quadro strutturato per l’organizzazione e l’accesso a vari strumenti. Pertanto, MCP non sostituisce Function Call ma piuttosto funziona in combinazione con gli Agent per svolgere compiti complessi.
Il processo completo di invocazione degli strumenti comporta una combinazione di ‘Function Call + Agent + Sistema MCP’.
In sostanza, l’LLM esprime la necessità di chiamare uno strumento specifico tramite Function Call. L’Agent segue le istruzioni per eseguire l’invocazione dello strumento, mentre MCP fornisce una specifica standardizzata per l’invocazione dello strumento.
Si consideri la seguente analogia: un capo (utente) vuole un caffè. In ufficio (MCP Host), il responsabile dell’ufficio (LLM) incarica il segretario (Agent) di acquistare un americano (Function Call). Il segretario controlla l’elenco dei fornitori e scopre che un fornitore di caffè americano si è integrato con Meituan o con il sistema di approvvigionamento unificato dell’azienda (MCP Server implementato). Il segretario quindi individua il fornitore nel sistema di approvvigionamento (MCP Client) ed effettua un ordine.
In precedenza, senza MCP, quando l’LLM emetteva una Function Call, l’Agent avrebbe tradotto e si sarebbe connesso direttamente all’API per invocare lo strumento. Ogni API richiedeva una modalità di invocazione separata e un elenco di strumenti e una modalità di invocazione definiti per consentire all’Agent di interpretare. Con MCP, molte API possono essere ordinate direttamente tramite il Client MCP del fornitore, risparmiando tempo e fatica all’Agent. Tuttavia, la Function Call dell’LLM rimane invariata, ancora nel formato {tool: ‘buy coffee’, ‘type’: ‘Americano’}.
Distinguendo tra Function Call e MCP, diventa chiaro che MCP non determina quale strumento utilizzare, né gestisce la pianificazione delle attività o l’intento dell’utente. Questi aspetti rientrano nella competenza del livello Agent. MCP fornisce semplicemente un’interfaccia di strumenti unificata, diventando un protocollo standard riconosciuto nel settore.
Sfide di Sviluppo e Panorama del Mercato di MCP
L’Enigma dello Sviluppo
Da febbraio, la comunità di sviluppo dell’IA ha assistito a una ‘corsa all’oro di MCP’. In assenza di un app store ufficiale, migliaia di strumenti si sono volontariamente integrati con il protocollo MCP in tre mesi.
Questa rapida crescita ha proiettato MCP sotto i riflettori del settore, ma ha anche esposto il divario tra aspirazione e realtà. Gli sviluppatori inizialmente vedevano MCP come una ‘chiave universale’, ma hanno scoperto che si trattava più di una ‘chiave inglese specializzata’, eccellente in alcuni scenari, ma meno efficace in altri.
I partecipanti a MCP possono essere classificati come applicazioni client locali, applicazioni client cloud e sviluppatori di server MCP. Le applicazioni locali sono simili agli assistenti AI locali, mentre le applicazioni client cloud assomigliano a versioni web di ChatGPT. Gli sviluppatori di server MCP sono i fornitori effettivi di strumenti, che devono riconfezionare le loro API per conformarsi alle regole MCP.
L’emergere di MCP è stato inizialmente accolto con favore dalle applicazioni client locali, ma le applicazioni client cloud e gli sviluppatori di server MCP hanno dovuto affrontare delle sfide.
MCP ha avuto origine dall’applicazione Claude Desktop di Anthropic, inizialmente progettata come protocollo di interfaccia per l’invocazione di file e funzioni locali, profondamente radicata nelle esigenze lato client.
Per gli utenti client locali, MCP ha rappresentato una rivoluzione, offrendo una cassetta degli attrezzi infinitamente espandibile che consentiva agli utenti di estendere continuamente le capacità dei propri assistenti AI.
Le applicazioni client locali come Cursor e Claude Desktop hanno sfruttato MCP per consentire agli utenti di aggiungere dinamicamente strumenti in base alle esigenze individuali, ottenendo un’espansione illimitata delle capacità dell’assistente AI.
MCP affronta un problema fondamentale nello sviluppo di client locali: come consentire alle applicazioni AI di interagire senza problemi con ambienti locali e strumenti esterni senza sviluppare interfacce separate per ogni strumento. Questo protocollo unificato riduce significativamente i costi di integrazione, fornendo a piccole startup e singoli sviluppatori una scorciatoia per la creazione di applicazioni AI ricche di funzionalità con risorse limitate.
Tuttavia, l’appeal di MCP diminuisce se si considerano lo sviluppo lato server (MCP Server) e i client cloud. Le prime versioni di MCP impiegavano un meccanismo a doppio collegamento per i server cloud (remoto), utilizzando una connessione lunga SSE per il push di messaggi unidirezionale dal server al client e una connessione breve HTTP per l’invio di messaggi.
Questo approccio ha funzionato bene per il feedback e l’intervento tempestivi dell’utente, ma ha creato una serie di sfide ingegneristiche negli ambienti lato server.
Innanzitutto, l’implementazione dell’interfaccia MCP rappresenta un carico di lavoro aggiuntivo per i grandi fornitori di servizi aziendali, senza necessariamente produrre vantaggi corrispondenti. Questi servizi hanno spesso sistemi API maturi e la fornitura di un ulteriore livello di adattamento MCP può solo aumentare i costi di manutenzione senza creare un valore sostanziale. Molte applicazioni di livello aziendale preferiscono meccanismi di invocazione di strumenti chiusi e controllabili rispetto all’ecosistema aperto di MCP.
Inoltre, per gestire le invocazioni ad alta concorrenza, i servizi MCP devono spesso essere scalati ad architetture multi-server. Il modello a doppia connessione di MCP introduce la complessità dell’indirizzamento cross-machine. Quando viene stabilita una connessione lunga su un server e una richiesta viene instradata a un altro server, è necessario un meccanismo di coda di trasmissione aggiuntivo per coordinare queste connessioni distribuite, aumentando significativamente la difficoltà di implementazione e i costi di manutenzione.
In secondo luogo, MCP ha delle limitazioni nel regno delle applicazioni cloud. Gli Agent AI cloud (Agent lato server) in genere vengono eseguiti in servizi stateless, elaborando le attività dopo l’accettazione e rilasciando le risorse al completamento. L’utilizzo di MCP Client sul lato server richiede la creazione temporanea di un collegamento SSE, l’invio di una richiesta di invocazione dello strumento, la ricezione del risultato dall’SSE e quindi la chiusura del collegamento SSE, che è un approccio inefficiente che aumenta la complessità e riduce le prestazioni. Una singola richiesta RPC dovrebbe essere sufficiente in questo scenario.
In pratica, le applicazioni cloud che utilizzano MCP spesso si basano su set di strumenti preimpostati e non utilizzano la capacità di firma di MCP di individuazione dinamica degli strumenti e caricamento flessibile.
La modalità di interazione dei dati degli ambienti cloud limita la capacità di utilizzare liberamente gli strumenti come previsto da MCP. Richiede un processo altamente standardizzato per l’invocazione di strumenti specifici e hard-coded, sacrificando la flessibilità.
Il team MCP ha dimostrato reattività al feedback degli utenti. Dopo aver ricevuto feedback dagli sviluppatori lato server, MCP ha aggiornato il suo protocollo il 26 marzo, sostituendo il trasporto SSE originale con il trasporto HTTP in streaming. Il nuovo protocollo supporta sia scenari di servizi stateless che richiedono solo singole richieste di invocazione di strumenti, sia requisiti di push in tempo reale che in precedenza erano soddisfatti tramite collegamenti doppi HTTP + SSE.
Questi miglioramenti suggeriscono che gli attuali problemi di MCP derivano da limitazioni di progettazione iniziali, ma non sono insormontabili.
Il Disordine del Mercato
Un’altra sfida che deve affrontare MCP è la bassa usabilità di molte implementazioni sul mercato.
L’attuale mercato MCP sta vivendo un tipico ciclo di hype tecnologico. Simile al caos dei primi App Store, meno del 20% delle migliaia di strumenti MCP attualmente disponibili ha un valore pratico. Molte implementazioni presentano problemi seri, che vanno da semplici errori di configurazione a una completa inutilizzabilità. Alcuni vengono lanciati sul mercato in fretta senza test adeguati, mentre altri sono prodotti sperimentali mai destinati a un uso pratico.
Un problema più fondamentale è che molte implementazioni MCP potrebbero non essere necessarie al mercato. Molti strumenti offerti tramite MCP sono semplicemente API riconfezionate che erano già disponibili e utilizzate prima dell’emergere di MCP, aggiungendo poco valore univoco.
Ad esempio, decine di servizi di ricerca sono offerti tramite MCP, ma la loro qualità varia in modo significativo. Alcuni servizi possono essere imprecisi o lenti, rendendoli meno desiderabili delle soluzioni esistenti.
Inoltre, MCP manca di un sistema di valutazione robusto, rendendo difficile per gli Agent selezionare lo strumento più adatto in base a metriche affidabili. Questo inefficiente processo di selezione spreca risorse di calcolo, estende i tempi di completamento delle attività e degrada l’esperienza dell’utente.
La mancanza di un sistema di valutazione rende difficile per gli agenti selezionare lo strumento più adatto. Se più servizi MCP offrono strumenti con nomi e descrizioni simili, l’agente potrebbe avere difficoltà a scegliere l’opzione migliore, portando a token sprecati e a una ridotta efficienza.
Le applicazioniAI di maggior successo spesso adottano l’approccio opposto, fornendo strumenti più precisi piuttosto che una maggiore quantità di strumenti. Manus, ad esempio, ha scelto di creare applicazioni interne invece di adottare il protocollo MCP, nonostante la sua esistenza. Manus ha dato la priorità all’accuratezza e alla stabilità delle chiamate rispetto all’integrazione con l’ecosistema MCP.
Gli editor di codice come Cursor hanno funzioni di sviluppo integrate, rendendo la maggior parte degli strumenti MCP esterni ridondanti.
L’attuale stato caotico del mercato MCP non è necessariamente un segno di fallimento, ma piuttosto una fase necessaria di crescita per qualsiasi ecosistema tecnologico emergente. I precedenti storici suggeriscono che questa sovraespansione iniziale convergerà gradualmente attraverso meccanismi di selezione del mercato, lasciando dietro di sé gli elementi più preziosi.
Questo processo consentirà al settore di imparare dalle sfide attuali e creare un framework MCP più forte e affidabile. Simile a come la bolla delle dot-com ha portato a innovazioni rivoluzionarie nell’e-commerce e nei social media, la tendenza MCP può portare a un ecosistema di strumenti più snello e prezioso.
L’atteggiamento aperto del team MCP nei confronti del feedback degli utenti è incoraggiante e il settore ha bisogno di strumenti migliori per valutare e garantire la qualità dei servizi MCP, il che contribuirà a rendere l’ecosistema più utilizzabile.
MCP È Buono, Non una Panacea
I problemi menzionati sopra derivano dalle limitazioni e dalle carenze di MCP, evidenziando ciò che può realisticamente ottenere. Tuttavia, altre critiche derivano da aspettative irrealistiche.
Una recente critica definisce MCP un protocollo difettoso perché non detta i modelli di interazione tra LLM e MCP.
Alcuni si aspettano che MCP migliori automaticamente il processo decisionale del sistema AI o aumenti l’efficienza della pianificazione delle attività. Questa aspettativa confonde gli strumenti con gli artigiani.
Il problema deriva da una mancata corrispondenza cognitiva: aspettarsi che un protocollo di comunicazione svolga compiti di un sistema intelligente. È come biasimare l’USB per non aver modificato le foto o criticare gli standard 5G per non aver scritto codice. MCP è principalmente un ‘socket per strumenti’ standardizzato, che garantisce la compatibilità della spina piuttosto che dettare quale elettrodomestico utilizzare o come.
L’efficacia dell’invocazione Agent-strumento dipende da fattori come la competenza nella selezione degli strumenti, le capacità di pianificazione delle attività e la comprensione del contesto, nessuno dei quali rientra nella competenza di MCP. MCP garantisce solo un’interfaccia di strumenti standardizzata, non come tali strumenti verranno scelti e combinati.
Cerchiamo spesso proiettili d’argento nella tecnologia, soluzioni universalmente applicabili. Come l’assioma dell’ingegneria del software ‘nessun proiettile d’argento’, l’uso di strumenti AI non ha una soluzione magica. Un sistema AI forte ha bisogno di componenti progettati: LLM per la comprensione e la generazione, framework Agent per la pianificazione e l’esecuzione e MCP focalizzato su interfacce di strumenti unificate.
MCP mostra una buona progettazione del protocollo: concentrarsi su un problema e risolverlo bene, piuttosto che tutti. La sua moderazione lo aiuta a progredire nell’integrazione degli strumenti lato client.
Entità come Qwen di Alibaba, ‘Xinxiang’ di Baidu e Kouzi Space di ByteDance abbracciano il protocollo MCP, tentando di stabilire ecosistemi MCP interni più efficienti.
Tuttavia, ci sono differenze fondamentali nella distribuzione: Baidu e ByteDance sono più aggressivi. Baidu tenta un approccio C-end, integrando diversi modelli AI e strumenti esterni attraverso ‘Xinxiang’ (Kokone) sfruttando il protocollo MCP, principalmente per dispositivi mobili, per integrarsi nella vita quotidiana dell’utente e incoraggiare l’adozione.
Kouzi Space di ByteDance ha oltre 60 plugin di estensione MCP. Accessibile tramite una pagina web, ha anche lanciato un IDE nativo AI, Trae, che supporta MCP, rivolgendosi principalmente a scenari di produttività.
Alibaba ha integrato il protocollo MCP in prodotti come Alipay, consentendo l’invocazione di strumenti AI con un clic, e ha open source il modello Qwen3, che supporta il protocollo MCP, migliorando le sue capacità Agent.
Gli sviluppatori di Tencent Cloud hanno rilasciato una suite di sviluppo AI che supporta i servizi di hosting di plugin MCP. Il grande motore di conoscenza del modello di Tencent Cloud consente agli utenti di chiamare i plugin MCP. L’agente intelligente di sviluppo software Craft lanciato da CodeBuddy di Tencent Cloud è compatibile con l’ecosistema aperto MCP. Inoltre, Tencent Maps e Tencent Cloud Storage hanno rilasciato il proprio MCP SERVER.
L’uso di strumenti AI può evolversi dal funzionamento diretto con un singolo strumento alla collaborazione con Agent professionisti, proprio come gli stili di programmazione si sono evoluti dal linguaggio assembly all’orientamento agli oggetti.
In questo paradigma, MCP può semplicemente diventare parte dell’infrastruttura sottostante, invece di un’interfaccia rivolta all’utente o allo sviluppatore. Un piano più completo può richiedere architetture come Agent to Agents (A2A) per migliorare la pianificazione delle attività e l’efficienza della selezione degli strumenti aumentando i livelli di astrazione.
Riportando MCP al suo ruolo di ‘protocollo’, possiamo riconoscere il suo vero potere di guidare la standardizzazione del settore: questo può essere il momento di ‘de-mistificazione’ più apprezzato nell’evoluzione della tecnologia.