Sovraccarico di Responsabilità dell’MCP
Una critica comune è che all’MCP vengono assegnate troppe responsabilità. Si argomenta che l’MCP dovrebbe servire principalmente come gateway per l’accesso e l’interazione dei Large Language Models (LLM) con risorse esterne. Considerarlo semplicemente una ‘porta’ o un ‘ponte’ aiuta a chiarire il suo scopo e i suoi limiti.
Attribuire direttamente all’MCP problemi come l’esposizione accidentale di dati, le vulnerabilità di prompt injection e le carenze nel controllo dei costi è un errore. Questi sono problemi che gli sviluppatori dovrebbero affrontare entro i confini che controllano. Gli sviluppatori devono implementare limiti di frequenza e monitorare l’utilizzo, indipendentemente dal protocollo utilizzato. Paragonare questo all’incolpare la strada per l’eccesso di velocità è appropriato: l’infrastruttura non è responsabile del comportamento individuale.
In definitiva, molte delle preoccupazioni sollevate sono questioni più ampie relative alla delega di compiti agli agenti AI. Gli sviluppatori devono assumersi la responsabilità di gestire queste sfide all’interno delle loro specifiche applicazioni, piuttosto che aspettarsi che l’API stessa gestisca tutto.
L’Arma a Doppio Taglio degli LLM e della Prompt Injection
Le recenti discussioni sull’MCP spesso assomigliano ad avvertimenti sui pericoli intrinseci dei coltelli affilati: possono tagliare se maneggiati male. La prompt injection, una preoccupazione significativa, è una conseguenza della natura degli LLM stessi. I tentativi di eliminare il rischio di prompt injection rischiano di degradare le stesse capacità che rendono preziosi gli LLM.
La nozione di separazione ‘controllo vs. dati’, comune nei sistemi tradizionali, non esiste naturalmente negli LLM. Gli LLM guadagnano la loro potenza e generalità proprio perché mancano di questa rigida separazione. Questa caratteristica intrinseca li rende vulnerabili agli attacchi di prompt injection.
Sebbene gli MCP remoti come servizio possano presentare dei rischi, la colpa non è del protocollo stesso, ma dell’affidare compiti sensibili a terzi non affidabili. Questa analogia si estende all’idea di attaccare un coltello a un Roomba erratico: il problema non è il coltello in sé, ma la decisione di attaccarlo a un dispositivo imprevedibile.
Ammonimenti a ‘fare attenzione’ o suggerimenti di dispositivi di protezione, pur essendo tecnicamente accurati, mancano il punto centrale: la decisione sconsiderata di combinare uno strumento affilato con un sistema incontrollato.
Sfide di Scalabilità
Oltre alle preoccupazioni per la sicurezza, l’MCP affronta limiti fondamentali di scalabilità. Si evidenzia la correlazione negativa tra l’affidabilità degli LLM e la quantità di contesto istruzionale fornito. Questo mette in discussione la convinzione comune che l’aggiunta di più dati e integrazioni risolverà automaticamente i problemi. Con l’aumentare del numero di strumenti e integrazioni, le prestazioni di un agente possono peggiorare, aumentando contemporaneamente il costo di ogni richiesta.
Si sottolinea che l’MCP non scala oltre una certa soglia. Tentare di aggiungere un numero illimitato di strumenti al contesto di un agente avrà inevitabilmente un impatto negativo sulle sue capacità. Questa limitazione è inerente al concetto di MCP e richiede maggiore attenzione rispetto ai problemi di autenticazione.
Gli utenti potrebbero alla fine sperimentare un declino delle prestazioni abilitando più server MCP, portando a interferenze tra di loro. Questo è in netto contrasto con i tipici sistemi di gestione dei pacchetti, in cui la non interferenza è una proprietà fondamentale.
Il problema principale con l’MCP è che il suo comportamento effettivo si discosta dalle aspettative degli utenti. È fondamentale riconoscere che l’MCP non è una soluzione plug-and-play che integra perfettamente un numero illimitato di strumenti senza conseguenze.
Affrontare i Limiti con l’UI e la Gestione degli Strumenti
Una soluzione proposta ai limiti dell’MCP è quella di migliorare l’interfaccia utente. Se uno strumento viene eseguito involontariamente, l’UI dovrebbe fornire un modo semplice per disabilitarlo o modificare la sua descrizione per chiarire il suo uso previsto.
Si nota anche che la crescita del contesto spesso porta a un miglioramento delle prestazioni e delle capacità di utilizzo nel mondo reale, contraddicendo la nozione di una correlazione strettamente negativa. Tuttavia, si riconosce che in alcuni casi d’uso o con contesti mal progettati, può verificarsi un degrado delle prestazioni.
Per affrontare l’eccessiva scelta di strumenti, viene suggerito un approccio ‘dividi e conquista’. Questo implica l’aggiunta di uno strumento specificamente progettato per selezionare gli strumenti più rilevanti per un determinato compito. Questo ‘strumento di scelta degli strumenti’ potrebbe essere un’altra chiamata LLM, incaricata di restituire un sottoinsieme di strumenti disponibili all’agente ‘genitore’. Questo approccio a strati aggiunge ulteriori livelli di indirezione per gestire la complessità.
Tuttavia, la semplice presenza di strumenti nel contesto può alterare significativamente l’output di un modello. Mentre gli strumenti contestualmente rilevanti (ottenuti attraverso tecniche come Retrieval-Augmented Generation o RAG) sono vantaggiosi, nascondere tutti gli strumenti dietro una richiesta ‘get_tools’ può essere dannoso.
MCP come Livello di Trasporto e Autorizzazione
L’MCP funziona principalmente come formato di trasporto e wire con un ciclo di vita richiesta/risposta, concentrandosi sull’autorizzazione a livello di strumento. Si argomenta che il problema principale dell’MCP è la sua incapacità di consentire agli agenti AI di comporre funzionalmente gli strumenti.
Si postula che l’MCP potrebbe non essere necessario in primo luogo, poiché gli LLM possiedono già la capacità di interagire con le API documentate utilizzando le specifiche OpenAPI. L’elemento mancante è l’autorizzazione: la capacità di controllare a quali API un’AI può accedere. Invece dell’MCP, si suggerisce di consentire alle AI di effettuare richieste HTTP applicando l’autorizzazione a endpoint specifici. Questo approccio si allinea con l’attuale tendenza di avvolgere le API esistenti con sottili strumenti MCP.
Un aspetto particolarmente fastidioso dell’MCP è la sua mancanza di supporto per lo streaming dei risultati delle chiamate agli strumenti. La singola coppia richiesta/risposta costringe i client a chiamare ripetutamente gli strumenti per la paginazione, ostacolando i processi di lunga durata. L’implementazione di una capacità di streaming, magari utilizzando gRPC, potrebbe migliorare significativamente l’efficienza dell’MCP.
La Facilità di Esposizione dei Dati Sensibili
Una preoccupazione significativa con l’MCP è il potenziale per una facile esposizione di dati sensibili. Inoltre, l’MCP non rende intrinsecamente gli agenti AI più affidabili; concede semplicemente loro l’accesso a più strumenti, il che può paradossalmente diminuire l’affidabilità in determinate situazioni.
Si riconosce che non ci si aspetta che l’MCP risolva o sia responsabile di tutti questi problemi. Piuttosto, l’MCP crea una superficie più ampia per questi problemi, richiedendo agli sviluppatori di app e agli utenti di essere vigili.
Analogie e Pianificazione Urbana
Si utilizza l’analogia della pianificazione urbana per illustrare il problema. Paragonare l’MCP a una strada cittadina a sei corsie con un limite di velocità di 40 km/h evidenzia la disconnessione tra design e uso previsto. Semplicemente imporre multe o aggiungere ‘correzioni’ superficiali non affronta il problema sottostante di una progettazione scadente.
Un’efficace pianificazione urbana implica la progettazione di strade che incoraggino naturalmente il rispetto dei limiti di velocità. Allo stesso modo, l’MCP dovrebbe essere progettato per mitigare intrinsecamente i potenziali rischi, piuttosto che fare affidamento esclusivamente su controlli esterni.
LLM che Intraprendono Azioni Indesiderate
L’articolo passa a una critica più ampia dei protocolli che consentono agli LLM di eseguire azioni sui servizi. Si identifica un problema centrale: gli LLM possono intraprendere azioni che gli utenti non intendono che intraprendano. Si distingue tra le azioni che gli LLM possono intraprendere in modo indipendente e quelle che richiedono un prompting da parte dell’utente.
Mentre l’obiettivo finale potrebbe essere quello di avere LLM che gestiscono intere aziende, la tecnologia non è ancora pronta per tale autonomia. Attualmente, gli utenti potrebbero non volere nemmeno che le AI inviino e-mail senza una previa revisione.
Si rifiuta la soluzione di richiedere all’utente una conferma, citando il rischio che gli utenti cadano in un modello di conferma automatica (‘modalità YOLO’) quando la maggior parte degli strumenti appaiono innocui. Questo è paragonato al fenomeno psicologico delle persone che spendono di più con le carte che con i contanti: un problema radicato nel comportamento umano, non nella tecnologia.
La Domanda Fondamentale: Perché Non Usare Semplicemente le API?
Una domanda ricorrente nelle discussioni sull’MCP è perché non usare semplicemente le API direttamente.
L’MCP consente ai client LLM che gli utenti non controllano direttamente (ad esempio, Claude, ChatGPT, Cursor, VSCode) di interagire con le API. Senza l’MCP, gli sviluppatori dovrebbero creare client personalizzati utilizzando le API LLM, un’impresa molto più costosa rispetto all’utilizzo di client esistenti con un abbonamento e all’insegnamento di come utilizzare strumenti specifici.
Uno sviluppatore condivide la sua esperienza di costruzione di un server MCP per connettersi al suo sintetizzatore hardware FM via USB, consentendo la progettazione del suono guidata dall’AI.
Integrazione del Client LLM e Standardizzazione
Il problema principale è che non tutti i client LLM supportano nativamente l’interazione diretta con le API, con le azioni GPT personalizzate di ChatGPT che sono una notevole eccezione. Anthropic, Google e OpenAI hanno concordato di adottare l’MCP come protocollo condiviso per semplificare il processo per i client basati su LLM come Claude, ChatGPT e Cursor.
L’MCP semplifica il processo per coloro che costruiscono client LLM. Se si desidera che un LLM interagisca con un’API, non si può semplicemente fornire una chiave API e aspettarsi che funzioni: è necessario creare un agente.
L’MCP può essere visto come un modo per documentare le API e descrivere come chiamarle, insieme a strumenti standardizzati per esporre tale documentazione e facilitare le chiamate. Fornisce una quantità sufficiente di astrazione per avvolgere le API senza inutili complicazioni, ma questa semplicità può anche portare gli utenti a ‘spararsi sui piedi’.
L’Efficienza e la Riutilizzabilità dell’MCP
Senza l’MCP, gli sviluppatori dovrebbero spiegare ripetutamente all’LLM come utilizzare uno strumento ogni volta che viene invocato. Ciò comporta il rischio che l’LLM non riesca a utilizzare lo strumento correttamente a causa di informazioni dimenticate o di un comportamento API non standard.
Questa costante spiegazione e duplicazione spreca token nel contesto, aumentando i costi e il tempo. L’MCP semplifica questo processo raggruppando tutte le informazioni necessarie, rendendo l’utilizzo degli strumenti più efficiente e facilitando la condivisione degli strumenti.
Dicendo a un fornitore di LLM ‘ecco uno strumento che puoi utilizzare’ insieme alla documentazione dell’API, gli utenti possono riutilizzare tale strumento in più chat senza ripetuti promemoria. Ciò consente anche ai client LLM desktop di connettersi a programmi in esecuzione localmente, affrontando il problema dei processi di esecuzione specifici del sistema operativo.
MCP e Accesso alle Risorse Locali
L’MCP facilita l’accesso alle risorse locali come file, variabili d’ambiente e accesso alla rete per gli LLM. È progettato per essere eseguito localmente, concedendo all’LLM un accesso controllato a queste risorse.
La ‘forma’ standard della chiamata allo strumento LLM rispecchia da vicino la ‘forma’ della chiamata allo strumento MCP, rendendolo uno standard semplice per collegare gli strumenti agli agenti.
L’MCP funge da ponte tra lo schema di chiamata delle funzioni esposto al modello AI e le API sottostanti. Traduce le chiamate di funzioni in strumenti, consentendo una comunicazione senza interruzioni.
Se sei un fornitore di strumenti, l’MCP offre un protocollo standardizzato per i frontend degli agenti AI per connettersi al tuo strumento. Questo risponde alla domanda sul perché il protocollo standard non può essere semplicemente HTTP e OpenAPI.
L’MCP è una meta-API che incorpora endpoint e i loro dettagli operativi nella specifica, consentendo agli LLM di interagire con essi in modo più efficace.
MCP in Scenari Specifici
L’MCP può risolvere i problemi quando gli utenti pongono domande o non sono sicuri di quali API utilizzare. Può anche elaborare le richieste in base ai messaggi precedenti.
Un utente condivide la propria esperienza di voler recuperare una ‘X’ di un utente e inviarla a un endpoint. Hanno scoperto che l’MCP è eccessivo per un compito così semplice, indicando che non è sempre necessario per le interazioni API di base.
L’MCP è paragonato a un framework di app web FastAPI per la creazione di software in grado di comunicare sulla rete, specificamente progettato per esperienze agentiche. Può essere visto come ‘Rails-for-Skynet’, fornendo un framework standardizzato per lo sviluppo di agenti AI.
Preoccupazioni sul Controllo del Fornitore
Ci sono preoccupazioni che l’MCP sia spinto per aumentare il controllo lato fornitore sul sistema. I fornitori di LLM potrebbero alla fine limitare l’accesso alle API, in modo simile a come Google ha reso difficile l’utilizzo di IMAP/SMTP con Gmail.
L’utilizzo di OpenAPI consente agli agenti di recuperare le specifiche API da /openapi.json.
L’MCP consente interazioni rapide, consentendo agli utenti di eseguire attività in pochi secondi piuttosto che dedicare tempo alla preparazione dei dati di input, all’invio all’API, all’analisi dell’output e alla ripetizione del processo per ogni messaggio.
Sandboxing e Rischi per la Sicurezza
Uno dei maggiori problemi è come l’output di uno strumento del server MCP può influenzare altri strumenti nello stesso thread di messaggi. Ciò richiede il sandboxing tra gli strumenti per prevenire conseguenze indesiderate. I laboratori Invariant hanno affrontato questo problema con le descrizioni degli strumenti, mentre altri hanno utilizzato gli allegati di risorse MCP. La mancanza di sandboxing aggrava i rischi di prompt injection.
Questo è paragonato all’SQL injection: un sistema messo insieme in cui le vulnerabilità possono essere sfruttate in qualsiasi punto con una minima osservabilità.
L’interfaccia prompt è anche suscettibile a una forma di SQL injection, poiché il modello non può distinguere le parti affidabili del prompt dall’input contaminato dall’utente. La risoluzione di questo problema richiede modifiche fondamentali alla codifica, alla decodifica e all’addestramento del modello.
Ciò consente sia l’iniezione di prompt che l’iniezione di strumenti, portando potenzialmente all’esecuzione di codice non affidabile.
Containerizzazione e Accesso Controllato
Uno sviluppatore ha creato un server MCP che avvia un container Docker con il codice del progetto montato. Questo approccio consente all’LLM di accedere all’intero set di strumenti Unix e agli strumenti specifici del progetto all’interno di un ambiente sandboxed.
Questo flusso di lavoro agentico, guidato attraverso un’interfaccia basata sulla chat, si è dimostrato più efficace dei metodi tradizionali.
La chiave è concedere agli agenti MCP l’accesso a ciò di cui hanno bisogno, e niente di più. La containerizzazione e l’UX trasparente degli strumenti sono fondamentali per mitigare i rischi per la sicurezza.
Macchine Virtuali e Accesso a Internet
Dare agli agenti un computer con un’installazione Linux minima (come una VM o un container) può produrre risultati migliori, consentendo loro di recuperare informazioni da Internet. Tuttavia, ciò solleva preoccupazioni per la sicurezza riguardanti istruzioni dannose e esfiltrazione di dati.
Limitare l’accesso a siti web affidabili può mitigare alcuni rischi, ma anche fonti affidabili possono ospitare contenuti dannosi. Il compromesso tra la probabilità di incontrare istruzioni dannose e i vantaggi in termini di produttività deve essere attentamente considerato.
Le differenze tra dipendenti e agenti AI sono significative. I dipendenti sono persone giuridiche soggette a leggi e contratti, fornendo responsabilità. Gli agenti AI mancano di questo quadro giuridico, rendendo la fiducia più difficile.
Le Prime Fasi dello Sviluppo dell’MCP
L’MCP è stato annunciato solo nel novembre 2024 e l’RFC è in continua evoluzione.
Alcuni vedono l’intero concetto di assistente personale AI, incluso l’MCP, come fondamentalmente imperfetto.
La spinta iniziale per gli assistenti AI alla fine degli anni ‘90 e all’inizio degli anni 2000 è fallita perché gli aggregatori di contenuti con integrazione verticale e potere d’acquisto all’ingrosso si sono dimostrati più efficaci. Ciò ha portato all’ascesa di piattaforme come Expedia ed eBay.
I sistemi multi-agente richiedono ai programmatori di influenzare lo stato degli agenti, un compito di programmazione impegnativo.
I Limiti del Valore Gratuito
Il desiderio di ‘classificare i risultati in base alla disponibilità di parcheggio’ evidenzia il problema dell’accesso ai dati dietro le API a pagamento o i frontend supportati dalla pubblicità. È improbabile che le aziende forniscano liberamente l’accesso al loro intero set di dati attraverso un’API.
Sebbene non tutte le aziende integreranno i loro dati negli agenti AI, il potenziale per combinare vari strumenti per alimentare i flussi di lavoro rimane significativo.
Le aziende che danno la priorità al mantenimento di un fossato di dati probabilmente resisteranno alle nuove tecnologie che minacciano tale fossato.
Se booking.com avesse un’API, probabilmente restituirebbe gli stessi risultati del suo sito web, possibilmente con formattazione JSON o XML.
Aggirare l’Intermediario
Non ha molto senso che un intermediario come booking.com consenta agli utenti di aggirare completamente i propri servizi.
Tuttavia, i singoli hotel potrebbero trovare vantaggioso aggirare booking.com, un intermediario che spesso non amano.
Un AI di Ricerca Approfondita potrebbe scansionare gli hotel in base a criteri specifici e interagire con i server MCP di Hotel Discovery gestiti da singoli hotel, aggirando la necessità di navigare nell’interfaccia e negli annunci di booking.com.
Casi d’Uso Pratici
L’MCP può facilitare compiti come il recupero dei log da Elasticsearch o l’interrogazione dei database in modo più strutturato.
La natura statica della configurazione del server MCP, in cui i nuovi server richiedono la modifica di un file .json e il riavvio dell’app, può essere limitante.
Modelli Fine-Tuned
L’MCP può essere visto come un piccolo modello fine-tuned che comprende numerosi strumenti MCP e sceglie quelli giusti per ogni conversazione.
La regolazione dinamica degli strumenti in base al contesto potrebbe essere necessaria per determinati scenari.
Conversazioni Aperte e Problemi Aziendali
L’MCP è adatto a sistemi di conversazione generali e aperti senza un flusso predefinito. Tuttavia, non è una soluzione valida per ogni problema aziendale. Non è destinato a sostituire framework come LangChain.
L’alternativa all’MCP, uno standard aperto guidato dalla comunità, è rappresentata da protocolli frammentati, proprietari e bloccati dal fornitore. Uno standard imperfetto ma in evoluzione è preferibile a nessun standard.
Il modo migliore per vedere l’MCP è come un passaggio da singoli sviluppatori che creano wrapper client attorno alle API a fornitori di API o wrapper gestiti dalla comunità che li costruiscono. Questo fornisce un ampio toolbox, simile a NPM o PyPi. Tuttavia, sono ancora necessari orchestrazione, sicurezza e definizione dell’utilizzo.
La prossima generazione di Langchain beneficerà di questo toolbox più ampio, ma è ancora necessaria innovazione.
Strumenti Specifici dell’Utente
In alcuni casi, gli strumenti potrebbero essere specifici dei dati dell’utente, come gli strumenti per sezionare e manipolare i file CSV caricati.
Un problema spesso trascurato è che l’MCP può affollare il contesto del modello con troppe opzioni. La prioritizzazione e l’esposizione dei metadati sono fondamentali per evitare un uso dispendioso dei token e un comportamento erratico del modello.
Standard e Tecnologia in Evoluzione
Nuovi standard emergono nel tempo, ed è passato così tanto tempo dall’ultima volta che gli standard hanno veramente avuto importanza che le persone hanno dimenticato come si sviluppano.
Scaricare piccoli programmi server da sviluppatori casuali per aggiungere ‘strumenti’ ai client LLM può essere rischioso.
I problemi sollevati sono problemi legittimi che l’ecosistema MCP deve affrontare. Alcune soluzioni saranno all’interno delle specifiche MCP, mentre altre saranno esterne.
Codice Claude e Utilizzo nel Mondo Reale
Ci sono opinioni contrastanti sul successo dell’MCP. Alcuni hanno sentito storie di aziende che si integrano con l’MCP, mentre altri hanno sentito da utenti che lo hanno trovato deludente.
Questo evidenzia lo svantaggio dell’hype e dell’adozione precoce.
Alcuni sviluppatori ritengono che le API HTTP siano superiori all’MCP per la maggior parte dei casi d’uso. Sostengono che l’uso di ‘strumenti’ si riduce agli endpoint API per le capacità e la funzionalità.
Le API non sono autodescrittive per impostazione predefinita, il che rappresenta un’opportunità persa per i sostenitori di REST e HATEOAS di mostrare i loro approcci.
MCP come Alternativa a LangChain?
L’MCP è stato descritto come avente un ‘odore di LangChain’: non risolvere un problema pressante, essere eccessivamente astratto e avere difficoltà a spiegare i suoi vantaggi.
Forse deve dire ‘FINE DELLA LINEA’ e bandire gli aspiranti hacker nella griglia di gioco!
Una domanda chiave è se il paradigma del Chatbot ‘generale’ persisterà. Le app specializzate con i propri strumenti potrebbero non aver bisogno dell’MCP.
Viceversa, man mano che gli LLM diventano più capaci, gli strumenti esterni potrebbero diventare meno necessari. Perché vorresti un MCP per guidare Photoshop quando l’LLM potrebbe semplicemente modificare l’immagine direttamente?
Il sogno dell’assistente robot di fantascienza potrebbe non materializzarsi e gli strumenti specializzati di manipolazione del linguaggio potrebbero essere più utili.
La Base Utenti e la Consapevolezza della Sicurezza
La base utenti dell’MCP include individui meno tecnici, il che rende i problemi di sicurezza particolarmente rilevanti. Sensibilizzare sulle migliori pratiche di sicurezza è fondamentale.
Basare Xops su OpenRPC, che richiede la definizione dello schema dei risultati, aiuta a pianificare come gli output si connettono agli input, migliorando l’affidabilità per flussi di lavoro complessi.
La tecnologia è probabile che si evolva e si assesti nel tempo.
Ridondanza e Infrastruttura Cloud
Alcuni mettono in discussione i vantaggi dell’utilizzo dell’MCP rispetto allo standard OpenAPI, considerandolo ridondante.
Cosa userà l’LLM per chiamare un sistema OpenAPI? Come si legherà alla shell? Come orchestrerà l’host dell’LLM?
L’MCP fornisce un modo strutturato per gli LLM di effettuare chiamate agli strumenti.
I server MCP sono già server HTTP.
Il più grande vantaggio dell’MCP è per i fornitori di LLM come OpenAI, non per gli sviluppatori di applicazioni.
Gli LLM sono cervelli senza strumenti e la chiamata agli strumenti li potenzia. Tuttavia, con le API normali, i fornitori di LLM non hanno accesso a tali strumenti. L’MCP concede loro l’accesso, posizionandoli come il gateway per l’AI.
CLI vs. API
Perché non utilizzare direttamente la CLI, dato che gli LLM sono addestrati sul linguaggio naturale e le CLI sono una soluzione comune leggibile e scrivibile dall’uomo?
L’MCP è emerso troppo rapidamente e ha bisogno di tempo per maturare. Manca la verifica da parte di un ente di standardizzazione convenzionale ed è guidato dall’hype.
C’è una mancanza di applicazioni nel mondo reale.
Applicazioni Chiave dell’MCP
L’MCP è utilizzato in Claude Desktop e nelle app di chat AI di nicchia, negli strumenti di automazione del codice e nei framework di automazione di agenti/LLM.
È un’altra tecnologia affrettata che probabilmente verrà scartata quando arriverà il prossimo acronimo hyped.
Esistono due tipi di protocolli di chiamata agli strumenti del modello linguistico: quelli di cui le persone si lamentano e quelli che nessuno utilizza.
Anthropic ha sviluppato questo ‘standard’ nel vuoto, portando a problemi di sicurezza.
JSON-RPC 2.0
L’MCP è basato su JSON-RPC 2.0, un protocollo leggero che consente la comunicazione client e server utilizzando JSON.
Sembra una specifica centralizzata progettata per un ecosistema specifico, che rivendica l’universalità senza guadagnarsela.
L’MCP è abbastanza potente da fare cose utili, il che solleva preoccupazioni per la sicurezza.
Non è uno standard maturo e non è stato progettato per essere sicuro.
Sebbene esistano raccomandazioni, non sono applicate o implementate.
Langchain e Chiamata degli Strumenti
Langchain è uno dei tanti framework che implementano il modello di ‘chiamata degli strumenti’.
L’MCP è una specifica per come le informazioni esterne entrano nella finestra di contesto di un modello linguistico, inclusi la chiamata agli strumenti, l’input modellato, la cancellazione, il monitoraggio dei progressi e la statefulness dei server degli strumenti.
Aiuta a standardizzare i dettagli in modo che qualsiasi combinazione assistente/integrazione sia compatibile.
Sebbene l’MCP abbia problemi legittimi, i critici dovrebbero affinare le loro argomentazioni.
L’autenticazione è fondamentale e non avrebbe dovuto essere omessa dalla versione iniziale.
Ci sono troppe complessità.