Model Context Protocol (MCP), e note sull'implementazione del server MCP in Go

Articolo dettagliato sulle specifiche e sull'implementazione di MCP in GO

Indice

Ecco una descrizione del Model Context Protocol (MCP), note brevi su come implementare un server MCP in Go, inclusa la struttura dei messaggi e le specifiche del protocollo.

Robots e MCP

Panoramica del Model Context Protocol (MCP)

Il Model Context Protocol (MCP) è un framework aperto e standardizzato (introdotto da Anthropic alla fine del 2024) per collegare i modelli linguistici AI a fonti di dati esterne, strumenti e sistemi. L’obiettivo è risolvere il problema dell’“N×M integrazione” fornendo un’interfaccia universale per attività come la lettura di file, l’esecuzione di funzioni (strumenti) e l’uso di prompt contestuali in diversi applicazioni. L’MCP non è un protocollo proprietario o interno; è uno standard aperto con una specifica ufficiale e un’implementazione di riferimento open source. Infatti, i principali fornitori di AI (tra cui OpenAI e Google DeepMind) hanno annunciato il supporto per l’MCP dopo la sua introduzione, sottolineando che è inteso come uno standard ampiamente adottato e non come una soluzione specifica per un fornitore.

Scopo e Architettura dell’MCP

L’MCP mira a standardizzare il modo in cui le applicazioni forniscono contesto ai LLM – l’analogia spesso utilizzata è “una porta USB-C per le applicazioni AI”. Definendo un protocollo comune, l’MCP permette agli assistenti AI e agli strumenti di interfacciarsi in modo fluido a database, sistemi di file, API e ad altri risorse senza integrazioni personalizzate. Questo aiuta i modelli linguistici a generare risposte più rilevanti e aggiornate, fornendo loro un accesso sicuro ai dati di cui hanno bisogno.

Architettura: L’MCP segue un modello client-server con una chiara separazione dei ruoli:

  • MCP Host: L’applicazione principale (ad esempio, un client di chat o un IDE) che gestisce le connessioni. Contiene uno o più MCP client (connector).
  • MCP Client: Un’istanza del connector all’interno dell’host che stabilisce una sessione 1:1 con un server MCP. Il client gestisce il ciclo di vita della sessione, instrada i messaggi e applica eventuali permessi utente o politiche di sicurezza.
  • MCP Server: Un servizio leggero che espone determinate capacità (accesso a certi dati o funzioni) tramite il protocollo MCP. Ogni server potrebbe avvolgere una fonte di dati (file, DB, API, ecc.) o uno strumento. Più server possono essere eseguiti in parallelo, ciascuno che fornisce diverse integrazioni.
  • Fonti di dati/servizi: Le risorse reali con cui i server interagiscono – possono includere file locali e database o servizi remoti (API web, app SaaS, ecc.). Il server MCP agisce come un adattatore per queste risorse, assicurando che il LLM acceda ai dati solo attraverso il protocollo standardizzato.

Questo design è ispirato al Language Server Protocol (LSP) del mondo IDE. Proprio come LSP permette a qualsiasi editor di supportare qualsiasi linguaggio di programmazione tramite un protocollo comune, l’MCP permette a qualsiasi applicazione AI di connettersi a qualsiasi integrazione di dati/strumenti che parla MCP. Questa decoupling significa che gli sviluppatori di strumenti AI possono scrivere un server MCP una volta e farlo funzionare con molti client AI, e gli sviluppatori di applicazioni AI possono aggiungere nuove integrazioni semplicemente collegando un server MCP, evitando il codice di integrazione personalizzato.

Protocollo e Struttura dei Messaggi

Comunicazione: La comunicazione MCP è costruita su sessioni persistenti e stateful utilizzando JSON-RPC 2.0. Tutte le richieste e le risposte si conformano al formato JSON-RPC (con un campo "jsonrpc": "2.0", nomi dei metodi, parametri e ID correlati). Sia il lato client che il lato server possono inviare richieste o notifiche, abilitando un’interazione bidirezionale. Una sessione MCP inizia tipicamente con un handshake:

  • Il client inizia con una richiesta initialize, proponendo una versione del protocollo e annunciano le sue capacità (quali funzionalità supporta). Ad esempio, il client potrebbe indicare che può gestire richieste server-driven “sampling” o fornire certi root per l’accesso ai file. Il server risponde con la sua versione del protocollo supportata e le capacità, finalizzando quali funzionalità sono abilitate per questa sessione (l’MCP utilizza un sistema di negoziazione delle capacità simile alle funzionalità opzionali in LSP). Se le capacità critiche o la versione non sono compatibili, la connessione viene interrotta in modo elegante.
  • Dopo l’accordo, il client invia una notifica initialized per segnalare la prontezza. Dopo questo, le operazioni normali possono procedere. La sessione rimane aperta per uno scambio continuo di messaggi JSON-RPC fino a quando un lato non emette un comando di chiusura.

Trasporti: L’MCP non impone un singolo trasporto – funziona su qualsiasi canale che possa trasportare testo JSON. Di solito, un server MCP viene eseguito come sottoprocesso e comunica tramite STDIO (tubi stdin/stdout) per le integrazioni locali. Questo è analogo a come funzionano i server linguistici e è conveniente per gli strumenti locali (l’host può avviare il processo del server e instradare i messaggi). In alternativa, i server MCP possono essere eseguiti come servizi indipendenti accessibili tramite HTTP. La specifica MCP definisce un trasporto streaming HTTP dove il server espone un singolo endpoint HTTP per le chiamate JSON-RPC (i client POST le richieste e il server può rispondere o stream risultati tramite Server-Sent Events per operazioni a lunga durata). In entrambi i casi, i messaggi sono righe JSON UTF-8 e il protocollo supporta risposte streaming e messaggi iniziativi dal server (l’approccio HTTP+SSE permette al server di spingere notifiche o risultati parziali in modo asincrono). Le linee guida sulla sicurezza raccomandano che i server locali si legano a localhost e validino gli header Origin per prevenire l’accesso remoto non desiderato, e che si usi un’autenticazione corretta (ad esempio token o flussi OAuth) per i server remoti.

Formato del messaggio: L’MCP sfrutta i tre tipi di messaggi JSON-RPC: Richieste, Risposte e Notifiche. Una richiesta contiene un id, una stringa method e (opzionalmente) params (di solito un oggetto JSON di argomenti). Il ricevente deve rispondere con una risposta corrispondente (con un id matching) che contiene un result o un oggetto error. Le notifiche sono come messaggi unidirezionali con un method e params ma senza id (così non ricevono una risposta). L’MCP impone alcune regole aggiuntive rispetto al JSON-RPC base (ad esempio, id deve essere non nullo e non riutilizzato durante una sessione) per mantenere la chiarezza.

Sessione e stato: La connessione è considerata stateful – il client e il server mantengono il contesto sulle capacità l’uno dell’altro e possibilmente alcuni stati di sessione (ad esempio, sottoscrizioni a modifiche, operazioni in corso, ecc.). Ci sono anche procedure definite per la chiusura graziosa (ad esempio, un client può inviare una richiesta di chiusura o semplicemente chiudere il trasporto; i server devono gestire la pulizia, e entrambi i lati implementano timeout per le operazioni in sospeso). La gestione degli errori segue le convenzioni JSON-RPC (le risposte di errore hanno un codice e un messaggio) e la specifica definisce codici di errore standard per certe condizioni (ad esempio, permesso negato, strumento non trovato, ecc.). L’MCP fornisce anche utilità per questioni trasversali: ad esempio, ci sono notifiche integrate per gli aggiornamenti di progresso, l’annullamento di una richiesta a lunga durata (CancelledNotification), messaggi di log/debug e modifiche di configurazione. Queste aiutano a gestire interazioni lunghe o complesse (il client può annullare un chiamata strumento in corso, o il server può inviare avvisi di warning al client, ecc.).

Funzionalità e Operazioni dell’MCP

Una volta inizializzato, una sessione MCP consente lo scambio di contesto e comandi in modo strutturato. Le funzionalità lato server principali dell’MCP sono Prompts, Resources e Tools (ciascuna delle quali il server dichiara se supporta durante l’inizializzazione):

  • Prompts: Modelli di prompt predefiniti o istruzioni che il server può fornire al client. Sono tipicamente triggerati dall’utente (l’utente sceglie esplicitamente un prompt da inserire nella conversazione, ad esempio tramite un comando slash nell’interfaccia utente). L’MCP fornisce metodi per elencare i prompt disponibili e recuperare il contenuto di un prompt. Ad esempio, un client può chiamare prompts/list per ottenere un elenco di modelli di prompt (ciascuno con un nome, una descrizione e parametri opzionali). Per recuperare un prompt, il client utilizza prompts/get con il nome del prompt e i valori degli argomenti; il server restituisce quindi il contenuto del prompt (spesso come un set di messaggi che il client inietta nel contesto dell’LLM). I prompt consentono il riutilizzo di istruzioni complesse o flussi di lavoro (ad esempio, “modello di revisione del codice”) che un utente può richiamare su richiesta. I server indicano una capacità prompts (con sottocaratteristiche opzionali come listChanged per notificare al client se l’insieme dei prompt cambia dinamicamente).

  • Resources: Dati strutturati o contenuti che forniscono contesto al modello. I resources sono tipicamente cose come file, documenti, voci di database – informazioni che un assistente AI potrebbe leggere o riferire. L’MCP standardizza come vengono identificati e trasferiti i resources: ogni resource ha un identificatore URI (ad esempio, file:///path/to/file.txt o uno schema personalizzato per i database). I client possono interrogare cosa risorse sono disponibili tramite resources/list (il server potrebbe esporre un albero di directory, un elenco di documenti recenti, ecc.). La risposta del server include metadati per ogni risorsa (URI, nome, tipo, descrizione, ecc.). Poi il client può richiedere il contenuto di una risorsa specifica con resources/read, passando l’URI. Il server risponde con il contenuto della risorsa, che potrebbe essere testo (per i file), o dati strutturati (l’MCP supporta diversi tipi di contenuto, come testo, JSON, binario, ecc., con tipi MIME). C’è anche supporto per modelli di risorsa (risorse parametrizzate identificate da URI di modello, che il client può compilare, ad esempio una query su un database dove l’utente fornisce un parametro). Se abilitato, i server possono inviare notifiche quando le risorse cambiano (ad esempio, notifications/resources/updated) o permettere ai client di sottoscrivere modifiche su una risorsa (resources/subscribe). Nell’architettura dell’MCP, le risorse sono controllate dall’applicazione: l’applicazione ospite (client) decide tipicamente quale contenuto di risorsa fornire effettivamente al prompt del modello (spesso dopo la conferma dell’utente o in base al contesto dell’interfaccia utente).

  • Tools: Funzioni eseguibili o azioni che il server espone per il modello per invocare. I tools rappresentano operazioni che l’AI può eseguire – ad esempio, chiamare un’API esterna, eseguire una query su un database, inviare un’email o modificare un file. Ogni tool ha un nome e uno schema JSON per i suoi input (e opzionalmente output), così l’AI (o il client) sa quali argomenti aspettare. I tools sono tipicamente controllati dal modello: l’idea è che il modello linguistico (agente) decida se e quando utilizzare un tool durante una conversazione per soddisfare la richiesta dell’utente. Tuttavia, per la sicurezza, un utente umano o l’applicazione ospite potrebbe mediare l’uso del tool (ad esempio, richiedere un clic di conferma). L’uso di tools nell’MCP coinvolge due operazioni principali: elenco e chiamata. Un client può chiamare tools/list per ottenere gli strumenti disponibili e i loro schemi. Ad esempio, un server potrebbe elencare un tool get_weather con una descrizione e uno schema di input che richiede una stringa “location”. Poi, quando il modello decide di utilizzare un tool (o l’utente lo invoca), il client invia una richiesta tools/call con il nome del tool e un oggetto JSON degli argomenti. Il server esegue la funzione e restituisce il risultato, tipicamente come un campo result.content che può contenere testo o dati strutturati (l’MCP supporta il ritorno di più parti di contenuto, ad esempio testo più un’immagine, ecc., sebbene il testo sia comune). Un esempio semplice: chiamare un tool get_weather potrebbe restituire un payload di testo come “Meteo attuale a New York: 72°F, parzialmente nuvoloso” come contenuto per l’assistente da presentare. I tools possono anche indicare errori (la risposta ha un flag isError o un oggetto di errore se qualcosa è andato storto). Come per i prompt e le risorse, la capacità tools può avere un flag opzionale listChanged per notificare quando gli strumenti disponibili cambiano in tempo reale (ad esempio, un plugin dinamico caricato/scaricato).

Oltre alle funzionalità sopra menzionate offerte dal server, l’MCP definisce anche funzionalità offerte dal client (capacità che i server possono sfruttare se il client le supporta). Queste includono Sampling, Roots e Elicitation:

  • Sampling permette al server di richiedere al client (e al suo LLM) di eseguire l’inferenza del modello all’interno della sessione. Ad esempio, un server potrebbe iniziare una chiamata LLM (forse per continuare una catena di pensiero o per riassumere qualcosa) inviando una richiesta come sampling/request – il client quindi promuoverebbe il modello e restituirebbe il risultato. Questo abilita comportamenti agenziali in cui il server può guidare l’AI per aiutarlo a completare i propri sottotask. (Tutte queste azioni sono soggette all’approvazione dell’utente e alle politiche – ad esempio, un utente potrebbe dover optare per permettere al server di attivare il modello per ulteriori query.)

  • Roots permette al server di interrogare o operare all’interno di certe radici del sistema di file o URI consentite. Il client può fornire un elenco di “radici” di directory/URI che il server è autorizzato ad accedere, tramite roots/list. Questo è una funzione di sicurezza che assicura al server di conoscere i limiti (ad esempio, quali alberi di cartelle può leggere).

  • Elicitation permette al server di chiedere al client di ottenere ulteriori informazioni dall’utente se necessario. Ad esempio, se uno strumento ha bisogno di un pezzo mancante di informazioni che non è stato fornito, il server può inviare una richiesta di elicitazione, che il client (interfaccia utente) tradurrebbe in un prompt all’utente (“L’integrazione X richiede la tua chiave API, per favore inseriscila”). In questo modo il server può raccogliere input interattivamente tramite il client.

Queste funzionalità sono tutte opzionali e negoziate in anticipo. Un aspetto chiave del design dell’MCP è che la negoziazione delle capacità avviene durante l’inizializzazione – il client e il server annunciano quali delle funzionalità sopra menzionate supportano, così entrambi i lati sanno quali operazioni sono disponibili nella sessione. Ad esempio, se un server non dichiara la capacità tools, il client non cercherà di eseguire alcuna operazione tools/list o tools/call con esso. Questa estensibilità significa che l’MCP può evolvere con nuove funzionalità nel tempo mantenendo la compatibilità all’indietro (i metodi non supportati semplicemente non saranno utilizzati se non negoziazionati).

Implementazioni, SDK e Creazione di un Server MCP (soprattutto in Go)

Specifiche ufficiali e documentazione: La specifica ufficiale dell’MCP è disponibile pubblicamente, inclusa una schema formale di tutti i tipi di messaggi. È mantenuta sul sito del Model Context Protocol e su GitHub. La specifica è definita in un file schema TypeScript (con un corrispondente JSON Schema) che documenta in modo preciso tutte le richieste, le risposte e le strutture. Il sito di documentazione (modelcontextprotocol.io) fornisce guide, un FAQ e analisi dettagliate di ogni funzionalità e tipo di messaggio, nonché uno strumento “MCP Inspector” per il debug interattivo. Sebbene l’MCP non sia (ancora) uno standard IETF o ISO, è sviluppato come uno standard aperto con input della comunità e utilizza terminologia familiare RFC 2119 per i requisiti. È un protocollo in evoluzione (le versioni sono contrassegnate con la data; ad esempio, 2025-06-18 è una revisione recente), con una politica di versionamento per gestire i cambiamenti.

Implementazioni di riferimento: Anthropic ha open-sourced un certo numero di connessioni server MCP e SDK quando ha introdotto l’MCP. C’è un’organizzazione GitHub modelcontextprotocol che ospita la specifica e diversi repository. In particolare, un repository “servers” contiene una raccolta di implementazioni pre-built di server MCP per servizi e fonti di dati comuni. Queste servono come integrazioni di riferimento e spesso possono essere utilizzate “out-of-the-box” o come modelli per server personalizzati. Ad esempio, il repository ufficiale include server per Google Drive (accesso ai file e ricerca in Google Drive), Slack (messaging del workspace e contenuti dei canali), GitHub/Git (contesto dei repository di codice), PostgreSQL (query del database in sola lettura con informazioni sullo schema), Google Maps (API per posizione e direzioni), Puppeteer (navigazione web e scraping), e molti altri. Installando o eseguendo questi server, un’applicazione AI come Claude o Cursor può immediatamente ottenere quell’integrazione. C’è anche un servizio di registrazione MCP gestito dalla comunità (open-source in Go) per indicizzare i server disponibili, e molte contribuzioni di terze parti che estendono l’MCP a vari domini (dai CRM ai dati blockchain).

SDK e librerie: Per facilitare la creazione dei propri server/client MCP, ci sono SDK ufficiali in diversi linguaggi. A partire dal 2025, il progetto fornisce SDK per TypeScript/Node, Python, Java (e Kotlin), C# (sviluppato con Microsoft), Ruby (con Shopify), Swift, e altri. Queste librerie gestiscono il plumbing del protocollo – ad esempio, gestendo il trasporto JSON-RPC, implementando lo schema della specifica e fornendo API helper per registrare strumenti o servire risorse. Ad esempio, lo SDK TypeScript può essere utilizzato per scrivere rapidamente un server in Node.js, e lo SDK Python permette di integrare l’MCP in applicazioni Python. L’approccio SDK significa che gli sviluppatori non devono costruire manualmente i messaggi JSON-RPC o implementare l’intero automa di stato; invece, chiamano metodi ad alto livello per inviare richieste o pubblicare capacità.

Implementazione in Go: Go è diventato una scelta popolare per i server MCP grazie alle sue forze di prestazioni e concorrenza (buone per gestire richieste multiple simultanee). È ora disponibile un SDK ufficiale in Go, mantenuto in collaborazione con il team Go di Google. (Questo è stato annunciato intorno ad aprile 2025 e la prima versione stabile è prevista per agosto 2025.) L’SDK in Go fornisce un pacchetto mcp per costruire client/server e un helper jsonschema per gli schemi degli strumenti. Utilizzando l’SDK in Go, gli sviluppatori possono creare un server MCP con poche chiamate. Ad esempio, puoi istanziare un nuovo server con un nome e una versione, quindi aggiungere strumenti tramite AddTool fornendo una definizione dello strumento (nome, descrizione, schema di input) insieme a una funzione Go per eseguire quando viene chiamato quell’strumento. L’SDK si occupa di esporre lo strumento nel protocollo (annunciandolo in tools/list e gestendo le richieste tools/call). Allo stesso modo, potresti esporre risorse o prompt con API analoghe. Infine, esegui il server – ad esempio, server.Run(ctx, mcp.NewStdioTransport()) avvierà il processing dei messaggi JSON-RPC su stdio fino a quando il client non si disconnette. Dal lato client, l’SDK in Go può generare un processo figlio e connettersi tramite mcp.NewCommandTransport(exec.Command("myserver")), quindi il client può chiamare session.CallTool(ctx, params) per invocare uno strumento e ottenere facilmente il risultato nel codice Go.

Esempio: La documentazione ufficiale dello SDK in Go mostra un semplice “server greeter”. Il server registra uno strumento "greet" che prende un nome e restituisce una stringa di saluto. Il client chiama quindi questo strumento per nome e stampa il risultato. Questo illustra il modello di base: definisci lo strumento -> il client chiama lo strumento -> ottieni il risultato. Dietro le quinte, ciò corrisponde a messaggi JSON-RPC ("method": "tools/call", params: {"name": "greet", ...} e la risposta che contiene result.content con testo) come definiti dalla specifica MCP.

Prima che l’SDK ufficiale in Go fosse rilasciato, la comunità ha creato le proprie librerie in Go. In particolare, il progetto mcp-go di Ed Zynda (mark3labs/mcp-go) è stato ampiamente utilizzato e ha influenzato il design dell’SDK ufficiale. Un’altra libreria, mcp-golang di Metoro, ha fornito un’implementazione e un’API in Go (l’articolo del blog Dev di Elton Minetto utilizza questa libreria a partire dall’inizio del 2025). Queste librerie della comunità hanno permesso agli sviluppatori Go di sperimentare con l’MCP in anticipo – ad esempio, un tutorial mostra come costruire un server MCP che cerca codici postali brasiliani (CEP) esponendo uno strumento “zipcode” tramite la libreria mcp-golang di Metoro. In quell’esempio, il server Go registra una funzione che chiama un’API esterna per trovare un indirizzo da un ZIP e restituisce il risultato come testo – permettendo a un assistente AI di recuperare informazioni sull’indirizzo su richiesta tramite l’MCP. Un’altra guida dimostra come avvolgere un database in-memory personalizzato (DiceDB) come un server MCP utilizzando l’SDK mcp-go di mark3labs: definisce un tool ping per verificare la connettività del DB e altri strumenti per le operazioni dati. Questi esempi evidenziano quanto possa essere semplice creare un’integrazione MCP: la maggior parte del codice è solo la logica aziendale (chiamate API, query DB, ecc.), mentre l’SDK gestisce il wiring JSON-RPC.

Costruire un server MCP in Go (Punti chiave del tutorial)

Per illustrare il processo, ecco un flusso tipico utilizzando il Go SDK o una libreria simile:

  1. Configurare il server: Inizializza un’istanza di server con informazioni di base (nome, versione e dichiara le funzionalità supportate). Ad esempio, in Go: server := mcp.NewServer("MyServer", "1.0.0", nil) creerà un server che, per default, supporta le funzionalità principali del protocollo. È possibile abilitare funzionalità specifiche come prompt/risorse/strumenti tramite opzioni o semplicemente registrando quelle funzionalità (aggiungere uno strumento o una risorsa implica che quella funzionalità è attiva).

  2. Registrare le funzionalità: Aggiungi le funzionalità che desideri esporre:

    • Se si espongono Strumenti, definisci lo schema di ogni strumento e il relativo gestore. Ad esempio, utilizzando AddTool del Go SDK: fornisci un mcp.Tool{Name: "...", Description: "..."} e una funzione gestore che riceve la richiesta di chiamata e restituisce un risultato (che potrebbe includere testo o altri contenuti). Il SDK genererà automaticamente uno schema JSON per gli input in base ai tipi dei parametri della funzione gestore (o puoi specificarlo tu).
    • Se si espongono Risorse, potresti utilizzare un’API per registrare elenchi di risorse o un callback per leggere il contenuto. Nel Python SDK, ad esempio, puoi sottoclasse un ResourceProvider; in Go, il SDK è ancora in evoluzione, ma probabilmente fornirai funzioni per elencare e leggere le risorse. Ogni risorsa dovrebbe avere un URI stabile.
    • Se si espongono Prompt, definisci i modelli di prompt (potrebbero essere file statici o stringhe) e registrali con nomi e parametri opzionali. Il server li annuncerà in modo che il client possa recuperarli e mostrarli agli utenti.

  3. Implementare il trasporto: Decidi come il server dovrà funzionare. Il modo più semplice per l’uso locale è stdio – ad esempio, in Go server.Run(ctx, mcp.NewStdioTransport()) inizierà a leggere JSON-RPC da stdin. Se il server dovrà essere accessibile in rete, potresti implementare un gestore HTTP che utilizzi il Go SDK per accettare JSON-RPC via HTTP (il Go SDK ufficiale potrebbe presto includere un helper per il trasporto HTTP/SSE).

  4. Test del client: È possibile testare il server con un client compatibile MCP. Ad esempio, Anthropic’s Claude 2 (Claude per Desktop) supporta il caricamento di server MCP locali; configureresti Claude per avviare o connettersi al tuo eseguibile del server. Esiste anche uno strumento CLI chiamato mcp-cli e l’MCP Inspector GUI per testare i server senza un client AI completo – questi strumenti invieranno richieste MCP al tuo server e mostreranno i risultati, aiutando nel debug.

  5. Sicurezza e autorizzazioni: Quando si costruisce un server, considera l’autenticazione e l’ambito. Per i server locali, l’host potrebbe eseguirlo con determinati permessi del sistema operativo o fornire chiavi API tramite l’ambiente. Per i server remoti, utilizza intestazioni di autenticazione o flussi OAuth. L’MCP include una specifica di autorizzazione per i trasporti HTTP (il server può richiedere un token e il client può inviarlo). Assicurati sempre che il server acceda solo ai dati che l’utente ha autorizzato (ad esempio, rispetta le directory radice fornite dal client e non divulga dati altrove) – le linee guida MCP sottolineano il consenso dell’utente, la privacy dei dati e la sicurezza degli strumenti come fondamentali.

In sintesi, MCP è un protocollo formale ma flessibile per collegare i modelli linguistici con il mondo esterno. Non è un’API interna legata a una sola azienda, ma uno standard aperto con un crescente adozione e un’ampia ecosistema di integrazioni. Il protocollo definisce strutture di messaggi chiare (basate su JSON-RPC) e un insieme di operazioni (metodi per prompt, strumenti, risorse, ecc.) che qualsiasi client/server conforme può implementare. La documentazione ufficiale e le specifiche sono disponibili, e numerosi SDK, librerie e server di esempio (inclusi in Go) rendono più semplice l’implementazione. Utilizzando MCP, gli sviluppatori possono costruire applicazioni AI alimentate da dati e servizi esistenti in modo sicuro, senza dover riscrivere la logica di integrazione per ogni nuovo modello o dataset.