Model Context Protocol (MCP) spiegato in modo comprensibile – con esempio in n8n

Chi costruisce agenti IA conosce il problema: per ogni funzione di un servizio collegato va definito uno strumento a sé. Cercare, creare, modificare, cancellare una voce di calendario – sono subito quattro elementi separati, e solo per un unico servizio. Con molti collegamenti l’onere di manutenzione cresce di conseguenza. Il Model Context Protocol (MCP) segue un approccio diverso: standardizza il modo in cui un modello linguistico comunica con un servizio – e riduce drasticamente il numero di elementi necessari. Questo articolo riassume il concetto e un esempio pratico concreto con n8n.

Quale problema risolve davvero MCP

L’idea di base del Model Context Protocol sta nel nome: un modello linguistico deve comprendere il contesto di un’applicazione. In concreto: che cosa sa fare questa applicazione? A che cosa serve? E come vi eseguo delle azioni?

Nella costruzione classica di un agente si collega ogni strumento singolarmente – ogni funzione è un elemento a sé. Con Google Calendar, ad esempio: uno strumento per cercare voci, uno per aggiornarle, uno per cancellarle, uno per crearle. Quattro funzioni per un servizio. Con agenti complessi e molti servizi collegati si arriva in fretta a decine di elementi.

Server, client e lo schema uniforme

MCP lavora con due ruoli:

• Server MCP: si interpone davanti al servizio vero e proprio (ad es. Airbnb o Google Calendar) e descrive come si può interagire con esso.
• Client MCP: risiede nell’agente, recupera le funzioni del server e le richiama.

Nell’implementazione attuale – ad esempio in n8n – bastano due passaggi al posto di molti strumenti singoli:

1. List Tools (elencare): l’agente chiede al server quali funzioni siano disponibili.
2. Execute Tool (eseguire): l’agente richiama una funzione concreta con i parametri adatti.

Decisivo è lo schema uniforme. Qualunque sia il servizio dietro: la risposta a una richiesta List Tools è sempre strutturata allo stesso modo. Contiene per ogni funzione il nome, una descrizione e uno schema con i parametri ammessi. Contenuti e parametri variano da servizio a servizio – la struttura resta costante. È esattamente questo che il protocollo prescrive e standardizza.

Un esempio con lo strumento Airbnb

Se si chiede all’agente quali possibilità offra lo strumento Airbnb, si procura da sé l’elenco delle funzioni tramite il tool List Tools. Tornano indietro, tra le altre:

• Airbnb Search: ricerca di offerte con filtri e paginazione – ad esempio località, data di check-in e check-out, numero di adulti, bambini, neonati e animali domestici nonché fascia di prezzo.
• Airbnb Listing Details: informazioni dettagliate su una determinata offerta tramite il suo listing ID.

All’agente qui non è stato necessario fornire nulla in anticipo – si è procurato da sé le funzioni disponibili, le loro descrizioni e lo schema dei parametri. Nello schema si vede ad esempio un campo di testo location (città, regione ecc.), i campi data per check-in e check-out, il numero di adulti nonché prezzo minimo e massimo.

Se poi si formula una richiesta concreta – ad esempio un alloggio a Bangkok per sei persone a un massimo di 50 euro a notte –, l’agente procede in due fasi: richiama prima List Tools (non ha memorizzato nulla, perché non è attiva alcuna memoria), riconosce dallo schema i parametri necessari ed esegue la ricerca tramite Execute Tool. Il risultato – ad esempio un alloggio con tre letti per circa 35 euro a notte – torna indietro, e questo con soli due strumenti aggiunti. Se Airbnb offrisse più funzioni, ad esempio per gestire i propri annunci, si potrebbero rappresentare con lo stesso schema, senza definire ulteriori elementi.

Come replicare MCP in n8n

I passaggi seguenti mostrano la configurazione sull’esempio di Airbnb. Si presta bene alla sperimentazione, perché non richiede alcuna chiave API.

1. Impostare la variabile d’ambiente: imposti N8N_COMMUNITY_PACKAGES_ALLOW_TOOL_USAGE su true. Questo consente alle community node di accedere ai tool. Con un’installazione Docker (ad es. su un server Hetzner) lo inserisca nella sezione environment del file docker-compose e riavvii l’istanza.
2. Creare un AI-Agent: crei un AI-Agent e vi associ un modello (nel video GPT-4.1 Mini).
3. Installare la community node: in Settings → Community Nodes installi il pacchetto n8n-nodes-mcp e confermi l’avviso sull’installazione di codice non verificato proveniente da fonti pubbliche.
4. Aggiungere il tool MCP client: tramite il più accanto a Tools cerchi «MCP». Attenzione: non lo confonda con l’MCP Client Tool proprio di n8n – la variante della community si riconosce dal simbolo della scatola ed è attualmente più completa.
5. Creare le credenziali: come tipo di connessione si può scegliere tra Command Line, Server-Sent Events e HTTP Streamable. Nell’esempio si resta su Command Line. I valori corretti si trovano nel repository del rispettivo server MCP, nella sezione sull’installazione. Per Airbnb: command npx, argomenti inseriti passo per passo – -y, il pacchetto @openbnb/mcp-server-airbnb e, facoltativamente, --ignore-robots-txt.

Nota su robots.txt: l’opzione --ignore-robots-txt ignora le regole di accesso di un sito web. Per una demo è accettabile – negli ambienti di produzione dovrebbe rispettare il robots.txt dei rispettivi servizi.

Configurare le due operazioni

Successivamente Le servono due tool MCP client con operazioni diverse:

• List Tools: chiami il tool ad esempio «Airbnb List Tools» e indichi come descrizione che serve a recuperare tutti gli strumenti Airbnb disponibili. Un clic di prova (Execute Step) dovrebbe restituire il noto elenco di funzioni con nome, descrizione e schema.
• Execute Tool: un secondo tool MCP client con l’operazione Execute Tool. Descrizione: serve a eseguire gli strumenti Airbnb, elencabili tramite il tool List Tools. Il nome dello strumento lo passi come expression, così che sia l’agente a decidere quale funzione richiamare; i parametri dello strumento li lasci liberi, in modo che li determini da sé.

Dopo aver riordinato e salvato si può testare l’agente – ad esempio di nuovo con la richiesta su Bangkok. Recupera l’elenco delle funzioni, lo restituisce al modello, opta per la ricerca e fornisce alloggi adatti. Esattamente il comportamento descritto nella parte concettuale, ora nel proprio flusso di lavoro.

Oltre n8n – e una parola sulla sicurezza

MCP non si limita alle piattaforme di automazione. Anche applicazioni desktop come Claude Desktop si possono collegare a server MCP. In questo modo si possono delegare dalla chat compiti a programmi installati localmente – un esempio molto citato è il controllo del software 3D Blender tramite MCP, in cui una persona senza conoscenze di Blender realizza dei rendering. Il server MCP gira in locale, mentre il modello linguistico continua a passare per il servizio cloud.

Con tutto l’entusiasmo vale però questo: MCP è uno sviluppo giovane. Esistono già preoccupazioni di sicurezza e sono state trovate vulnerabilità. Proprio negli ambienti di produzione la tecnologia va presa con cautela – conviene osservare l’evoluzione ulteriore prima di fondarvi processi critici.

Conclusione

Il Model Context Protocol è un approccio pragmatico alla standardizzazione: tramite un server MCP un modello linguistico apprende da sé che cosa sa fare un servizio e come lo si interpella – invece di predefinire ogni funzione singolarmente. Per gli agenti IA complessi ciò significa sensibilmente meno elementi e meno manutenzione; nell’esempio n8n bastano due passaggi: elencare ed eseguire. L’approccio è convincente, ma ancora giovane. Chi lo prova dovrebbe iniziare con servizi non critici e, negli ambienti di produzione, prendere sul serio le questioni di sicurezza aperte.

Fonte: Model Context Protocol (MCP): Erklärung & n8n Tutorial (Deutsch) – canale YouTube di Philip Thomas.