MCP protocol: come collegare agenti AI ai sistemi aziendali

Un assistente AI che non può leggere il tuo CRM è un chatbot. Lo stesso assistente, collegato al gestionale, all’ERP e al filesystem aziendale, diventa un collega. In mezzo, oggi, c’è quasi sempre lo stesso pezzo di infrastruttura: l’MCP protocol, il Model Context Protocol che Anthropic ha rilasciato come standard aperto il 25 novembre 2024 e che nel giro di due anni è diventato il modo predefinito di collegare un modello linguistico ai sistemi che contengono i dati veri di un’azienda.

Questa guida non si ferma alla definizione, quella la trovi già nell’AI Overview di Google. Serve a rispondere alle domande che vengono dopo: come è fatto il protocollo davvero, in cosa differisce dal function calling e dalle API REST che hai già, cosa significa in concreto scrivere un connettore per Salesforce o SAP, e perché il pezzo difficile non è il protocollo ma l’onboarding.

In questo articolo scoprirai:

• Che cos'è il protocollo MCP e a cosa serve in azienda
• Come funziona MCP: architettura host, client e server
• MCP, function calling e API REST: che differenza c'è davvero
• Connettori MCP per CRM ed ERP: cosa succede quando tocchi i gestionali
• Scrivere un connettore MCP custom: cosa contiene un server aziendale fatto bene
• Sicurezza dei server MCP: i rischi che vengono con la comodità
• Dal protocollo all'agente che serve: perché il connettore è solo metà del lavoro

Che cos’è il protocollo MCP e a cosa serve in azienda

Il Model Context Protocol è uno standard aperto che definisce come un’applicazione AI chiede contesto e azioni a un sistema esterno. L’analogia che ricorre nella documentazione ufficiale è quella della porta USB-C per l’intelligenza artificiale: una presa sola, uguale per tutti, al posto di un cavo diverso per ogni dispositivo. Anche IBM lo descrive come lo standard che uniforma il modo in cui le applicazioni forniscono contesto ai large language model.

Il problema che il protocollo MCP risolve: da N×M a N+M

Il problema che risolve ha un nome preciso in letteratura: Databricks lo chiama “N×M integration problem”. Senza uno standard comune, ogni applicazione AI deve integrarsi individualmente con ogni servizio esterno: cinque modelli e venti sistemi aziendali fanno cento connettori da scrivere e mantenere. MCP riduce le integrazioni totali da N×M a N+M, perché ogni client e ogni server implementano il protocollo una volta sola. È una differenza che non si vede il primo giorno e si vede moltissimo al secondo anno di manutenzione.

Chi ha adottato il protocollo MCP finora

Al lancio Anthropic ha pubblicato server MCP pronti per Google Drive, Slack, GitHub, Git, Postgres e Puppeteer, con Block e Apollo fra i primi ad adottarlo in produzione. Da lì in poi l’adozione ha smesso di essere una questione di ecosistema: OpenAI ha adottato MCP a marzo 2025, a partire dal supporto nativo nell’Agents SDK, e oggi il protocollo è supportato trasversalmente dai principali host AI. Se stai valutando dove collocarlo rispetto agli altri standard emergenti, abbiamo dedicato un pezzo al confronto fra MCP e A2A, i due protocolli che ridisegnano l’AI agentica: il primo collega un agente ai sistemi, il secondo gli agenti fra loro.

Una precisazione che conta per chi legge documentazione: MCP si occupa solo dello scambio di contesto. Non dice come l’applicazione debba usare il modello, né come gestire il contesto ricevuto. È un protocollo di trasporto semantico, non un framework di agenti.

Come funziona MCP: architettura host, client e server

L’architettura è client-server, ma con una terminologia che vale la pena fissare perché le tre parole vengono usate a sproposito ovunque. Secondo l’architecture overview della specifica ufficiale:

• MCP Host: l’applicazione AI che coordina tutto, Claude Desktop, Visual Studio Code, ChatGPT.
• MCP Client: il componente che mantiene la connessione verso un server. Relazione 1:1.
• MCP Server: il programma che espone dati e azioni, indipendentemente da dove gira.

Se VS Code si collega al server di Sentry e a quello del filesystem locale, istanzia due client distinti. Un host con dieci integrazioni ha dieci client. Questa è la struttura che rende il sistema componibile: aggiungere una fonte dati non tocca le altre. Per la parte implementativa vera e propria, SDK, configurazione, deploy, trovi tutto nella nostra guida completa al Model Context Protocol e agli MCP server.

I due layer del protocollo MCP: dati e trasporto

MCP è diviso in un data layer basato su JSON-RPC 2.0, che definisce messaggi e semantica, e un transport layer, che definisce il canale. I trasporti sono due: stdio, per processi locali sulla stessa macchina, senza overhead di rete; e Streamable HTTP, per i server remoti, con POST HTTP e Server-Sent Events opzionali per lo streaming. Sul trasporto remoto la specifica raccomanda OAuth per ottenere i token.

La distinzione locale/remoto non è un dettaglio operativo. Cloudflare, già a marzo 2025, la descriveva come «la transizione dal software desktop al software web»: i server locali restano roba da sviluppatori, quelli remoti raggiungono un pubblico enormemente più largo. Per un’azienda che vuole dare un agente a cinquanta persone, il server remoto non è un’opzione: è l’unica strada.

Le primitive: tools, resources e prompts

Un server MCP può esporre tre primitive. I tools sono funzioni eseguibili (query, scritture, chiamate API). Le resources sono fonti di dati che forniscono contesto senza eseguire azioni (uno schema di database, il contenuto di un file). I prompts sono template riutilizzabili di interazione. Ogni primitiva ha i suoi metodi di scoperta (*/list) e di esecuzione (tools/call).

Lato client, la specifica corrente, la 2026-07-28, che è quella attuale, mantiene l’elicitation, con cui il server può chiedere all’utente un’informazione mancante o la conferma di un’azione, e ha deprecato sampling e logging. Chi trova ancora tutorial che li presentano come funzionalità correnti sta leggendo materiale vecchio.

MCP, function calling e API REST: che differenza c’è davvero

È la domanda che compare in tutte le SERP inglesi («How is MCP different from API?», «Can MCP replace REST API?») e a cui in italiano quasi nessuno risponde. Vale la pena farlo bene, perché è qui che si prendono le decisioni architetturali sbagliate.

MCP non sostituisce le API REST: le avvolge

La risposta corta è che MCP e REST non competono. Come sintetizza l’analisi di WorkOS, «gli MCP server usano internamente le API REST per fare il lavoro vero»: il server MCP sta sopra, gestisce discovery, sessione e autorizzazione; la tua API REST resta sotto e contiene la business logic. Continui a servire la web app con REST e affianchi un server MCP come nuovo strato di interfaccia per gli agenti.

Il criterio di scelta è il consumatore. REST quando il client è codice scritto da uno sviluppatore, deterministico, con throughput alto e caching HTTP. MCP quando il consumatore è un agente AI che deve scoprire a runtime cosa può fare, incatenare più passaggi e ricevere autorizzazioni granulari. Chi prova a esporre l’ERP direttamente al modello via REST scopre in fretta che manca tutto lo strato di descrizione semantica che l’LLM usa per decidere.

Rispetto al function calling: il tool esce dall’applicazione

La differenza con il function calling classico è più sottile ma più importante. Il function calling esiste da prima di MCP e funziona: descrivi una funzione al modello, il modello la invoca. Il problema è che quella descrizione vive dentro la tua applicazione e parla il dialetto di un fornitore. Come nota l’analisi tecnica di CodiLime, «senza un approccio standardizzato, ogni combinazione di modello e strumento richiede un adattatore unico».

MCP prende quella stessa idea e la sposta fuori dall’applicazione, dentro un server con un’interfaccia JSON-RPC uguale per tutti. Il guadagno concreto è triplice: lo stesso tool funziona con Claude, GPT e Gemini senza riscritture, l’autenticazione e le ACL si centralizzano nel server invece di stare sparse negli agenti, e team diversi possono contribuire nuove capacità senza reinventare l’integrazione. Il function calling è una feature del modello; MCP è un contratto fra sistemi.

Connettori MCP per CRM ed ERP: cosa succede quando tocchi i gestionali

Fin qui la teoria regge. Poi arrivi al gestionale e cambia tutto, perché i sistemi che contengono i dati che servono davvero, anagrafiche clienti, ordini, ciclo attivo, magazzino, non sono stati progettati per essere interrogati da un modello linguistico.

Il caso SAP: nessun connettore ufficiale, un server da costruire

Prendi SAP, che in Italia è ovunque nella manifattura. Non esiste un connettore ufficiale: la strada è esporre i servizi OData/REST tramite SAP Integration Suite, alzare un MCP server su BTP, proteggere l’endpoint con OAuth e registrarlo come connettore custom. E i limiti sono dichiarati: l’agente «tocca SAP solo dentro un’esecuzione che avvii tu», non reagisce autonomamente agli eventi del gestionale, e soprattutto non c’è nessun «connettore SAP supportato da OpenAI» su cui ripiegare se domani un’API cambia. La manutenzione è interamente a carico di chi l’ha costruito.

È lo scenario che abbiamo già raccontato parlando di come si integrano gli agenti AI con ERP e CRM in presenza di sistemi legacy, e che per le realtà più piccole cambia di scala ma non di natura: anche nella guida dedicata alle PMI italiane il collo di bottiglia resta lo stesso, non il protocollo, ma la mappatura fra i processi reali e ciò che il sistema espone.

Perché i vendor CRM stanno correndo

C’è un segnale di mercato che dice molto su quanto sia diventato serio. A dicembre 2025 Salesforce ha portato Agentforce dentro ChatGPT come app nativa, e la motivazione dichiarata dall’azienda, come riportato da Salesforce Devops, è la preoccupazione per gli MCP server che i clienti si costruiscono in casa e che finiscono per riversare dati verso OpenAI. Tradotto: i vendor temono che i connettori MCP custom aggirino i loro layer di governance, permessi e misurazione dei consumi. Dal lancio dell’SDK OpenAI di ottobre 2025, oltre 35 vendor hanno pubblicato integrazioni ChatGPT.

Per chi compra, la lettura è utile in due direzioni. Il connettore ufficiale del vendor ti dà governance e supporto, ma ti lega al suo perimetro e al suo modello di consumo. Il connettore custom ti dà esattamente i processi che ti servono, inclusi gli oggetti personalizzati e i workflow che nessun vendor ha previsto, al prezzo di doverlo mantenere tu.

Scrivere un connettore MCP custom: cosa contiene un server aziendale fatto bene

Il malinteso più diffuso è pensare che un server MCP sia un wrapper delle API. Tecnicamente lo è; utilmente non basta. Un server che espone cinquanta endpoint tradotti uno a uno produce un agente peggiore di uno che ne espone otto, perché il modello deve scegliere, e più opzioni indistinguibili gli dai, più sbaglia.

Progettare i tools intorno ai processi, non agli endpoint

Il lavoro di design consiste nel salire di livello: non getCustomerById più getOpenOrders più getPaymentStatus, ma situazione_cliente, che fa le tre chiamate e restituisce un oggetto già interpretabile. Il nome del tool, la sua description e il suo inputSchema sono a tutti gli effetti prompt engineering: sono l’unica cosa che il modello legge per decidere. La specifica stessa raccomanda nomi qualificati come calculator_arithmetic invece di calculate, proprio per ridurre l’ambiguità quando un host federa più server.

Le resources vanno usate per ciò che è contesto e non azione, lo schema del database, il listino, la tassonomia dei prodotti, e i prompts per incapsulare i casi d’uso ricorrenti. Databricks segnala un dettaglio che in azienda pesa: le risorse restituite includono metadati di provenienza come ID sorgente e timestamp, rendendo gli output tracciabili. È la differenza fra un agente che afferma e uno che si può verificare.

Il cambio che quasi nessuno ha ancora recepito: MCP è diventato stateless

Qui va segnalata una discrepanza reale nelle fonti. Buona parte della letteratura tecnica in circolazione, inclusi articoli autorevoli e recenti, descrive MCP come protocollo stateful, con sessioni che mantengono contesto fra le chiamate. Nella specifica 2026-07-28 non è più così: MCP è definito stateless, ogni richiesta porta versione di protocollo e capabilities nel campo _meta, i server annunciano ciò che supportano tramite la richiesta obbligatoria server/discover, e le notifiche di cambiamento sono opt-in via subscriptions/listen.

Non è un cavillo: cambia il modo in cui si scala un server remoto dietro un load balancer. Ne abbiamo scritto quando la specifica è uscita, in MCP si aggiorna: il protocollo diventa stateless e pronto per il cloud. Se stai valutando materiale formativo o una consulenza, è un buon test: chi ti descrive ancora le sessioni stateful come stato dell’arte non ha letto la spec corrente.

Sicurezza dei server MCP: i rischi che vengono con la comodità

Un server MCP è codice eseguibile con accesso ai tuoi sistemi. Questo basta a spostare la conversazione dall’entusiasmo alla due diligence, e i numeri disponibili non sono rassicuranti.

Cosa dicono i dati sulle implementazioni reali

Le valutazioni di sicurezza condotte da Equixly su server MCP diffusi riportano che il 43% dei server testati conteneva falle di command injection, il 30% era vulnerabile a SSRF e il 22% consentiva path traversal. Lo stesso lavoro cita uno studio su 2.562 applicazioni MCP reali, di cui 1.438 con API di rete e 1.237 con API di sistema consolidate. Il messaggio è che la maturità di sicurezza non ha tenuto il passo dell’adozione.

I controlli raccomandati, in ordine di utilità

Red Hat classifica i rischi in cinque famiglie, autenticazione e autorizzazione (il classico problema del confused deputy), prompt injection, tool injection (un server legittimo «modificato in un aggiornamento futuro» per raccogliere dati riservati), esecuzione non autorizzata di comandi e rischio supply chain, e raccomanda controlli concreti: firma digitale dei componenti, pinning delle versioni dei server, sanitizzazione dei dati prima dell’uso come argomento, sandboxing dei server locali, conferma esplicita dell’utente sulle azioni e logging centralizzato.

Sull’autenticazione, l’approccio che ha fatto scuola è quello descritto da Cloudflare: il server MCP emette token propri invece di inoltrare quello del provider upstream, così se il token consegnato al client viene compromesso «l’attaccante ottiene solo i permessi limitati che hai concesso esplicitamente». In azienda questo si traduce quasi sempre in un gateway davanti ai server, lo stesso schema che DoorDash ha adottato con il suo gateway centralizzato per l’accesso degli agenti agli strumenti, e in un impianto di regole che non è un dettaglio tecnico ma una scelta di governance degli agenti AI, con policy, ruoli e obblighi dell’AI Act.

Dal protocollo all’agente che serve: perché il connettore è solo metà del lavoro

Se sei arrivato fin qui hai capito la parte facile. Il protocollo è documentato, gli SDK esistono, un server MCP che legge il CRM si scrive in pochi giorni.

Cosa il protocollo MCP non decide al posto tuo

La parte difficile viene dopo, e non è tecnica: è capire quali processi valga la pena esporre, con quali permessi, per quali persone, e come far sì che quelle persone li usino davvero. Un connettore perfetto su un processo che nessuno aveva chiesto è un costo, non un agente. È esattamente il punto per cui, negli agenti AI applicati ai processi aziendali, la differenza fra un progetto che gira e uno che muore in pilota non sta quasi mai nel modello scelto.

Dopo il connettore MCP: l’affiancamento sui processi reali

È la ragione per cui in MIMIR trattiamo l’integrazione come un servizio, non come un prodotto da consegnare chiavi in mano. Scrivere il connettore MCP custom sul gestionale è il primo passo; quello che lo rende utile è l’affiancamento: mappare i processi con chi li esegue ogni giorno, decidere cosa l’agente può leggere e cosa può scrivere, mettere in piedi i controlli e le conferme sulle azioni sensibili, e restare accanto al team nelle prime settimane, quando emergono i casi che nessuna analisi aveva previsto. Abbiamo raccolto il metodo nella nostra guida pratica all’onboarding degli agenti AI in azienda, e il ragionamento più generale in perché per un AI agent enterprise il servizio conta più del modello.

Il protocollo MCP ha reso banale la connessione tecnica fra un LLM e i tuoi sistemi. Ha reso più visibile, non meno, il lavoro che resta: decidere cosa quell’agente deve fare e portarlo dentro il modo in cui l’azienda lavora già. Se hai un gestionale, un CRM o un ERP che vorresti rendere interrogabile da un agente e vuoi capire se ha senso, e da dove partire, parlane con noi di MIMIR: valutiamo insieme i processi, i vincoli di sicurezza e cosa è realistico ottenere. Anche solo per scoprire che nel tuo caso conviene aspettare.

Fonti:

• Anthropic — Introducing the Model Context Protocol (25 novembre 2024)
• Model Context Protocol — Architecture overview, specifica 2026-07-28
• IBM Think — What is the Model Context Protocol
• Databricks — What is the Model Context Protocol e il problema N×M
• OpenAI — Model Context Protocol nell’Agents SDK (supporto annunciato a marzo 2025)
• Cloudflare — Remote Model Context Protocol servers
• WorkOS — MCP vs REST API
• CodiLime — Model Context Protocol explained
• Carly — ChatGPT at work: l’integrazione con SAP
• Salesforce Devops — Agentforce in ChatGPT e gli MCP server fatti in casa
• Equixly — Come i server MCP sfidano i modelli di sicurezza API tradizionali
• Red Hat — MCP: rischi di sicurezza e controlli