Un'analisi approfondita degli MCP, Parte 1: Ma cos'è MCP, in fin dei conti?
Se ti interessa l'IA, avrai sicuramente sentito parlare del Model Context Protocol (MCP). Da quando Anthropic ha detto di questo nuovo standard nel novembre 2024, è diventato super popolare. Ci sono MCP per mandare e-mail, MCP per cercare sul web, MCP che fanno funzionare altri MCP. Gli MCP stanno permettendo agli umili LLM di fare richieste di pull e prenotazioni di voli. A maggio, Microsoft ha anche detto che avrebbe creato un registro MCP per Windows che permette alle app di esporre le loro funzionalità agli agenti di IA.
Ottimo! Ma come? Cos'è MCP? Come si usa? Perché è diventato così più popolare rispetto ai tentativi precedenti? Come fa a far fare cose ai chatbot nel mondo reale? E come puoi crearne uno tutto tuo?
Quando abbiamo deciso di creare il nostro server MCP per API di DeepL, ci è sembrato un po' complicato. Ma una volta che capisci davvero come funzionano gli MCP, come permettono agli agenti di trovare e usare gli strumenti e come puoi creare un server MCP di base con 10 righe di codice, non è poi così complicato. In questa serie di post, cercheremo di chiarire questo argomento. Vedremo:
- cos'è MCP
- Come usare MCP in un client IA
- come creare un server MCP
Andiamo!
Cosa vuol dire MCP?
MCP sta per ModelContextProtocol.
Il "modello" è un modello di IA. Può essere qualsiasi tipo di superficie IA, ma di solito è fatta su un LLM. Qui lo chiameremo agente IA o assistente IA.
"Contesto"vuol dire il contesto in cui lavora l'agente IA. Nell'ambito dell'IA, si parla spesso di "finestra contestuale", che è tutto il contesto che un LLM tiene in considerazione quando risponde a una richiesta: la cronologia della conversazione, la richiesta del sistema e altro ancora. Perché MCP funzioni, una superficie IA dà al LLM sottostante un'ulteriore indicazione su quali strumenti può usare e come usarli.
Il "protocollo"è un insieme di regole che spiegano come due entità comunicano su una rete. Un protocollo che usi tutti i giorni è l'HTTP (HyperText Transfer Protocol), che regola come un server web e un client web comunicano tra loro.
Riassumendo: Il "Model Context Protocol" è un protocollo che dà il contesto che permette ai modelli di IA di usare strumenti e risorse esterni.
MCP è uno standard aperto creato da due ingegneri di Anthropic. Usa JSON-RPC, un protocollo molto usato per definire le chiamate di funzione. Ed è ispirato al Language Server Protocol, creato da Microsoft per separare la logica alla base della gestione dei linguaggi di programmazione dagli IDE.
MCP non è un software, un'app o un'API. Ma dà agli agenti IA accesso a tutte queste cose!
Cosa fa MCP?
Gli LLM possono dare risposte intelligenti e utili a quello che gli utenti chiedono. Ma non possono usare servizi esterni, non possono comunicare con altri software, non hanno modo di prendere informazioni aggiornate. MCP permette a qualsiasi superficie IA di mandare richieste a qualsiasi servizio software e ricevere una risposta. Dà a un agente IA un modo standard per accedere a strumenti, risorse e dati esterni.
Senza MCP, un client IA è solo un cervello senza corpo, senza modo di comunicare con il mondo esterno. Con MCP, un client IA può diventare un agente!
Chi può usare MCP?
Dato che MCP è uno standard aperto, chiunque può mettere su un client MCP o un server MCP.
Il client può essere qualsiasi app che usa un LLM. Puoi usare gli MCP in app come Claude Desktop, VSCode, Windsurf e Cursor. Oppure puoi usare gli MCP con un agente IA che hai creato con un framework come LangChain o CrewAI.
Perché MCP è diventato così famoso?
Uno dei motivi è che si tratta di uno standard aperto. Qualsiasi agente IA può usare MCP, e lo stesso vale per qualsiasi strumento. Questo lo rende più interessante rispetto alle soluzioni pensate per i prodotti di una specifica azienda, come OpenAI's Chiamata di funzioni.
Nel creare questa soluzione universale, i creatori di MCP si sono ispirati al Language Server Protocol (LSP). Prima di LSP, quando un IDE voleva implementare funzionalità come il completamento automatico o l'evidenziazione della sintassi per un determinato linguaggio di programmazione, doveva sviluppare la propria integrazione. Il risultato è stato quello che i creatori hanno recentemente definito un problema m × n, in cui era necessario implementare servizi linguistici separatamente per ogni possibile combinazione IDE/linguaggio. Con LSP, ogni linguaggio di programmazione ha bisogno solo di una libreria di integrazione. E un IDE che offre supporto a LSP può supportare qualsiasi linguaggio di questo tipo. Allo stesso modo, una volta che un servizio ha messo in piedi un server MCP, qualsiasi client IA che supporta MCP può usarlo. Il cliente deve solo ricevere supporto clienti per MCP.
MCP è flessibile anche in altri modi. Può funzionare in locale o su una rete. E viene da Anthropic, che è molto rispettata e che condividerebbe i vantaggi di uno standard aperto.
Perché gli agenti IA hanno bisogno di un protocollo standard?
Visto che gli LLM sono così bravi a capire e usare le informazioni, non potrebbero già usare qualsiasi servizio software che sia descritto nei loro dati di addestramento? Dopotutto, gli LLM sanno già come usare un sacco di API famose, come puoi vedere se chiedi aiuto a un assistente di programmazione tipo Copilot o Sourcegraph.
Ma se dessi a un LLM accesso a tutte le API nei suoi dati di addestramento, sarebbe il caos. Come fa a sapere quali API chiamare e quando? Come farebbe a prendere la tua chiave API e le tue credenziali, e come userebbe i servizi che richiedono altri tipi di accesso? E se volessi sapere quanto è lontano in macchina da Kansas City a Des Moines o che temperatura c'è adesso a Bangkok? Ci sono un sacco di modi per trovare queste informazioni. Come utente, vuoi avere il controllo sulle azioni che il tuo LLM sceglie di fare. Questo è vero soprattutto quando non si tratta di recuperare informazioni, ma di fare cose che cambiano il mondo, tipo mandare un'e-mail o ordinare una pizza.
È vero, un agente potrebbe leggere e capire una specifica OpenAPI di basso livello, o tutta la documentazione API, e poi fare le chiamate API di conseguenza. Ma MCP permette ai produttori di strumenti di definire servizi di livello superiore che sarebbero particolarmente utili per un agente IA, indirizzando tale agente in una direzione utile. Finora, questo è un campo in cui gli esseri umani sono ancora i migliori.
Quindi, sembra che per ora la cosa migliore sia definire chiaramente quali strumenti e risorse può usare l'LLM e come può usarli. MCP lo fa alla vecchia maniera, in modo deterministico, non usando la magia dell'LLM, ma tramite codice e JSON.
Ma come può un LLM usare gli strumenti?
In pratica, un LLM è una macchina che crea dei token, cioè cose che noi vediamo come testo, immagini, audio e così via. Allora, come può una macchina del genere avere accesso a strumenti e risorse? Come fa a sapere che ha questo accesso e come fa a sapere quale usare?
Il punto è che, come dice Maximilian Schwarzmüller, gli LLM possono comunicare con il mondo esterno solo tramite token. Prendono i token come input e producono token come output. E questi simboli possono includere cose che significano "Voglio usare uno strumento". Quindi, per dire che vuole usare uno strumento o una risorsa, e per usarlo davvero, un LLM crea dei token standard che il software intorno a lui riconoscerà come una chiamata allo strumento e intercetterà. Il software poi chiama un servizio e manda il risultato all'LLM.
L'LLM potrebbe usare dei token speciali qui. Ma di solito usa solo dei delimitatori e un linguaggio specifici: così puoi aggiungere questa funzionalità a un LLM già esistente, sistemandolo un po'. Per esempio, puoi usare i tag di inizio e fine tra parentesi quadre che racchiudono JSON, come in questo modello di output dell'agente:
Certo! Posso prepararti un nuovo foglio di calcolo. Aspetta un attimo...
[tool-start]
{
"tool": "spreadsheets",
"action": "create"
}
[tool-end]
Questo è proprio quello che hanno fatto i ricercatori nel il loro articolo Toolformer del 2023, che ha mostrato, come dice il titolo, che "i modelli linguistici possono imparare da soli a usare gli strumenti". In questo studio, gli autori hanno creato dei dati di addestramento che includevano rappresentazioni in testo semplice delle chiamate API e dei loro risultati. Mettendo a punto un LLM con questi dati extra, hanno creato un LLM che chiama quelle API per dare una risposta interessante a una richiesta.
Hanno usato un formato semplice:
[function_name(data) → result]
Per esempio, sapendo che gli LLM fanno fatica con la matematica, hanno aggiunto uno strumento come la calcolatrice. Hanno poi aggiunto nei dati di addestramento stringhe come questa:
Su 1.400 partecipanti, 400 (ovvero [Calcolatrice (400 / 1400) → 0,29] il 29%) hanno superato il test.
e
Il nome viene da "la tortuga", che in spagnolo vuol dire [MT("tortuga") → tartaruga] tartaruga.
Ottimizzando un LLM con questi dati, hanno creato un LLM in grado di richiamare le API per generare la risposta più promettente a un determinato prompt.
Ma non serve mettere a punto un LLM per fargli usare gli strumenti. A quanto pare basta solo un suggerimento. Questo articolo mostra come insegnare a un LLM a usare strumenti che usano JSON delimitato da [[qwen-tool-start]] e [[qwen-tool-end]], semplicemente dandogli un prompt adatto.
Puoi provarlo tu stesso! Basta andare sul tuo chatbot salvato e dirgli:
Congratulazioni! Ora puoi usare uno strumento per fare le moltiplicazioni. Quando devi fare un calcolo, basta inserire la seguente sintassi:
[Math]
{
"arg1": {value},
"arg2": {value}
}
[/Math]
dove, ovviamente, ogni {valore} è il valore che vuoi moltiplicare. OK?
Poi dai al LLM un problema di matematica e guarda come riproduce fedelmente la sintassi che gli hai dato per il tuo strumento matematico.
I moderni LLM usano ancora gli strumenti più o meno allo stesso modo. Per esempio, Anthropic spiega qui come hanno creato un sistema di prompt per far usare a Claude gli strumenti nella loro API.
Come fa un LLM a gestire i risultati di uno strumento?
Come fa un LLM a ricevere i risultati degli strumenti? Ancora una volta, è tutta una questione di gettoni. Quando il client IA riceve un output da uno strumento, lo rimanda all'LLM come input, ma in modo che l'LLM capisca che si tratta dell'output dello strumento e non dell'input dell'utente finale.
Mettendo tutto insieme
Per riassumere, ecco cosa succede quando un LLM usa uno strumento:
- Tipi di utenti nell'input
- LLM elabora questo input
- Mentre sta creando qualcosa, l'LLM "decide" che usare uno strumento è il modo migliore per finire il suo lavoro. Questo vuol dire che genera una serie di token che, grazie all'addestramento, gli permettono di richiamare uno strumento.
- Il client IA capisce che quei token servono per chiamare uno strumento, li intercetta, analizza il JSON in parametri e tutto il resto nella richiesta, e manda il tutto allo strumento giusto.
- Lo strumento crea dei risultati, che possono o meno usare un'API. Lo rimanda al client IA, che lo manda all'LLM.
- LLM elabora i risultati degli strumenti
- LLM usa questo risultato per continuare a creare una risposta per l'utente.
Ecco, questo è il mio tour veloce su cos'è MCP e come funziona nei modelli di linguaggio grande (LLM). Nel prossimo post ti mostrerò come usare gli MCP nel tuo client IA personale!
A proposito dell'autore
Come Developer Evangelist di DeepL, Ben Morss aiuta chiunque a usare l'API di DeepL per accedere alle sue traduzioni AI di altissimo livello. Prima, lavorava in Google come Product Manager per Chrome e Developer Advocate per un web migliore. Prima di allora era ingegnere informatico al New York Times e ad AOL, e un tempo era musicista a tempo pieno. Ha preso una laurea in Informatica ad Harvard e un dottorato in Musica all'Università della California a Davis. Potresti ancora trovarlo a suonare con la band Ancient Babies, o a fare analisi di canzoni pop su Rock Theorye a scrivere un musical che in realtà non parla di Steve Jobs.