Negli ultimi sei mesi ogni progetto AI che abbiamo portato in produzione ha avuto, prima o poi, lo stesso problema: l’agente deve parlare con il CRM. Con il gestionale. Con Slack, con un database, con un endpoint custom che il cliente ha scritto nel 2019. E ogni volta che cambia il modello — Claude diventa GPT, Gemini diventa Llama — bisogna riscrivere tutto il livello di tool calling.
MCP, Model Context Protocol, risolve questo. È un protocollo aperto, lanciato da Anthropic, che disaccoppia l’agente dai suoi strumenti. Pensalo come LSP per i tool: un client (l’agente) parla con un server (lo strumento) tramite un set di messaggi standardizzati. Cambia il modello, gli strumenti restano.
Cosa c’era prima
Prima di MCP, ogni framework di agenti aveva il suo modo di esporre i tool. OpenAI funzioni con JSON schema, LangChain con i suoi Tool objects, Anthropic con il content block "tool_use". Il codice del tool calling era duplicato su ogni provider, e ogni cambio di modello significava ricompilare l’adattatore.
In un nostro progetto recente per uno studio legale, l’agente di redazione contratti aveva 12 tool: ricerca giurisprudenza, lettura del DMS interno, verifica anagrafica, generazione del documento finale. La prima versione era scritta con i function calling di OpenAI. Quando il cliente ha chiesto di spostarsi su Claude per via dei limiti di rate-limit, abbiamo dovuto riscrivere 800 righe di adapter. Una settimana di lavoro, per ottenere zero valore nuovo.
Cosa cambia con MCP
Con MCP, gli strumenti diventano server stand-alone. Ogni tool gira come un processo Node, Python, Go — quello che vuoi — che espone una manciata di endpoint via JSON-RPC su stdio o HTTP. L’agente è un client MCP. Si connette al server, scopre i tool disponibili, li chiama. Punto.
Per noi questo significa tre cose:
1. Strumenti riusabili. Il server MCP che parla con il PMS di una catena alberghiera lo abbiamo scritto una volta e lo usiamo in tre progetti diversi, con tre modelli diversi. 2. Provider swap istantaneo. Quando il cliente vuole testare se Gemini risparmia il 40% sul billing del mese, basta cambiare due righe nell’orchestratore. Gli MCP server restano in piedi. 3. Sicurezza migliore. Il server MCP è un confine di trust naturale. Lo isoliamo, lo monitoriamo, e gli passiamo solo i secret che gli servono. L’agente non vede mai le credenziali.
Cosa abbiamo imparato a sbattere il naso
Tre lezioni dalle nostre prime integrazioni.
Schema first, sempre. Gli SDK MCP ti permettono di esporre tool con JSON Schema dettagliato. Investi tempo nel descrivere ogni argomento. Il modello fa quello che gli dici, e se la descrizione è ambigua chiama lo strumento male. Una giornata in più sullo schema vale tre giornate di debug a runtime.
Idempotency keys ovunque. Gli agenti retry-ano. Se chiami "crea fattura" senza idempotency key e l’agente decide che è andato in timeout, ti ritrovi con due fatture identiche. Ogni tool che fa scrittura ne ha bisogno.
Logging strutturato dei tool call. Salva ogni chiamata: input, output, latenza, errore. Senza questo, debuggare un agente è impossibile. Noi mandiamo tutto in un database append-only con tre indici: per agente, per tool, per timestamp.
Quando NON usare MCP
MCP è eccellente per agenti che orchestrano molti strumenti. Per use case più semplici — un singolo modello che genera testo, una pipeline batch che processa documenti — è over-engineering. Se hai un solo strumento, esponilo direttamente con il function calling del provider e finita lì.
In produzione
Oggi tutti i nostri agenti di "Cerchio 3 — Orchestrazione" girano su MCP. La pipeline tipica è: un orchestratore Claude o GPT che si connette a 4-8 server MCP, ciascuno responsabile di un sistema cliente. I server stanno nel tenant del cliente quando possibile (così i dati non escono mai dal loro perimetro), o nel nostro quando il cliente non ha infrastruttura.
Il protocollo si sta muovendo veloce — siamo già alla v2 — ma la backward compatibility è stata rispettata. Vale la pena investire.