MCP, la presa USB dell’Intelligenza Artificiale: come collega gli agenti ai sistemi aziendali

La presa USB delle AI

Se avete mai dovuto collegare un gestionale ad un’applicazione esterna saprete certamente quanto lavoro possa nascondersi dietro ad una frase apparentemente innocua come «facciamo leggere all’AI i dati del CRM», perché prima dell’arrivo di protocolli standardizzati occorreva capire quali API offrisse il prodotto, come autenticarsi, quali endpoint chiamare, quali strutture JSON aspettarsi, come trasformare gli errori, come gestire token, permessi, versioni, timeout e magari scrivere un connettore completamente diverso per il secondo gestionale che il cliente avrebbe acquistato sei mesi dopo. MCP, Model Context Protocol, nasce precisamente per ridurre questa frammentazione, ed è per questo che l’analogia della presa USB oppure, ancora meglio, della USB-C per l’Intelligenza Artificiale è diventata così popolare, perché l’idea fondamentale è semplice: invece di insegnare ad ogni applicazione AI un linguaggio differente per parlare con ogni sorgente di dati, definiamo un protocollo comune attraverso il quale un sistema può dichiarare che cosa sa fare e l’agente può scoprire quelle capacità ed utilizzarle.

La cosa importante è però togliere immediatamente due formule che rischiano di trasformare una tecnologia molto interessante in marketing, perché MCP NON significa che qualunque ERP o CRM possa essere collegato istantaneamente senza che nessuno abbia scritto codice da qualche parte, e soprattutto NON significa che la connessione sia automaticamente «in totale sicurezza». Se il fornitore dell’ERP ha già realizzato un server MCP, oppure se qualcuno ha costruito un server capace di tradurre il protocollo MCP nelle API e nella business logic del prodotto, allora una nuova applicazione compatibile può collegarsi senza sviluppare ogni volta una integrazione punto-punto, ed è qui che il vantaggio diventa enorme. Ma se quel server non esiste, qualcuno deve realizzarlo, deve decidere quali funzioni esporre, quali credenziali usare, quali autorizzazioni rispettare e quali operazioni NON rendere disponibili all’agente. MCP standardizza il collegamento, non elimina il sistema che si trova dall’altra parte della presa.

Da dove arriva MCP e perché in due anni è diventato infrastruttura

Anthropic ha presentato MCP il 25 novembre 2024 come standard aperto per collegare assistenti AI ai sistemi nei quali vivono dati e strumenti, partendo da un problema molto concreto, cioè che ogni nuova sorgente richiedeva una propria integrazione e che questa proliferazione di connettori impediva di costruire sistemi agentici realmente interoperabili. L’idea ha avuto una diffusione eccezionalmente rapida, ed alla fine del 2025 Anthropic riportava più di 10.000 server MCP pubblici attivi ed adozione da parte di ChatGPT, Claude, Gemini, Cursor, Microsoft Copilot, Visual Studio Code ed altri prodotti, mentre nel dicembre dello stesso anno il protocollo è stato donato alla AAIF (Agentic AI Foundation) della Linux Foundation, cofondata da Anthropic, Block ed OpenAI con il supporto, fra gli altri, di Google, Microsoft, AWS e Cloudflare. Questo passaggio conta perché MCP non è più semplicemente «il protocollo di Claude», è diventato una infrastruttura aperta e vendor-neutral sulla quale aziende concorrenti hanno deciso di costruire interoperabilità.

Nel luglio 2026 i maintainer hanno pubblicato la revisione 2026-07-28, la più importante dalla nascita del protocollo, ed hanno dichiarato che gli SDK Tier 1 stavano totalizzando complessivamente quasi mezzo miliardo di download al mese, un dato che naturalmente non equivale a mezzo miliardo di utenti reali ma dà una misura della quantità di software che ormai dipende dall’ecosistema. La revisione 2026 ha inoltre modificato in maniera sostanziale il modello operativo rendendo il core stateless sulle connessioni HTTP, quindi molto più simile all’infrastruttura web che sappiamo già scalare, con richieste autosufficienti che possono essere instradate verso istanze differenti senza dover mantenere una sessione applicativa nascosta nel protocollo.

Prima di capire MCP bisogna distinguere host, client e server

La terminologia sembra più complicata di quanto sia realmente. L’HOST è l’applicazione con la quale interagiamo, per esempio un IDE, un’applicazione desktop, un runtime agentico oppure un assistente aziendale; dentro quell’host vive un CLIENT MCP, cioè il componente che parla effettivamente il protocollo, mentre dall’altra parte troviamo il SERVER MCP che espone dati e capacità. Il server non parla direttamente con il modello linguistico e non è necessariamente un server remoto nel senso tradizionale del termine, perché può essere un piccolo processo locale avviato dall’host e collegato attraverso stdin e stdout, oppure un servizio remoto raggiungibile via HTTP.

Questa distinzione permette di capire una cosa che viene spesso raccontata male: quando un agente «si collega al database» attraverso MCP, normalmente il modello NON apre una connessione SQL al database e non riceve magicamente privilegi amministrativi. Il modello vede invece un insieme di capacità che il server MCP ha deciso di esporre, per esempio cerca_cliente, leggi_fatture_scadute, crea_ordine, verifica_giacenza oppure apri_ticket, ed il server traduce quelle richieste nel linguaggio reale del gestionale, applicando idealmente autenticazione, autorizzazioni, controlli e business logic. È una differenza enorme perché permette di offrire all’agente una interfaccia costruita sul significato dell’operazione aziendale invece di consegnargli direttamente le chiavi del database.

Tools, resources e prompts: le tre primitive che spiegano (quasi) tutto

Un server MCP espone tre primitive fondamentali che conviene distinguere bene, perché rappresentano tre modi diversi attraverso i quali l’AI può interagire con ciò che si trova fuori dal modello. I TOOLS sono funzioni eseguibili che il modello può decidere di utilizzare, quindi una funzione che cerca un cliente, crea una fattura oppure aggiorna una opportunità commerciale appartiene normalmente a questa categoria; le RESOURCES sono invece contenuti o dati che l’applicazione può rendere disponibili come contesto, per esempio un documento, una configurazione, la cronologia di un repository oppure una scheda cliente; i PROMPTS sono modelli di istruzioni riutilizzabili che l’utente può scegliere e parametrizzare.

Questa separazione può sembrare accademica finché non si costruisce un sistema reale, perché stabilisce anche CHI ha il controllo dell’azione. Nella documentazione ufficiale i tool vengono descritti come model-controlled, quindi il modello può sceglierli quando ritiene che siano necessari per completare il compito, le resource sono application-controlled, perché è normalmente il client a decidere come inserirle nel contesto, mentre i prompt sono user-controlled, cioè rappresentano template che l’utente sceglie esplicitamente. In altre parole MCP non si limita a definire un tubo attraverso il quale passano byte, definisce anche una semantica operativa che permette all’host di distinguere una informazione da una azione e da una istruzione.

Che cosa vede concretamente il modello quando scopre un tool

Immaginiamo un server MCP collegato ad un ERP che esponga un tool chiamato get_customer_balance. Il server pubblica il nome della funzione, una descrizione che spiega a che cosa serve ed uno schema degli argomenti accettati, per esempio un identificativo cliente ed una data di riferimento, e nella revisione 2026 gli schemi di input ed output possono utilizzare pienamente JSON Schema 2020-12. Quando l’utente domanda «quanto ci deve ancora il cliente Rossi e quali fatture sono scadute?», il modello non deve conoscere l’endpoint REST proprietario del gestionale, non deve sapere come costruire la query SQL e non deve imparare il formato interno della tabella contabile, perché può selezionare il tool, produrre gli argomenti conformi allo schema ed aspettare il risultato strutturato.

Il server MCP riceve la chiamata, applica il codice necessario per parlare con il gestionale reale e restituisce il risultato, poi il modello utilizza quei dati per costruire la risposta all’utente. Se domani cambio il modello da Claude a ChatGPT, oppure costruisco un agente interno in un altro framework che supporti lo stesso protocollo, idealmente non devo riscrivere l’integrazione con l’ERP, perché il contratto fra agente e sistema esterno rimane quello del server MCP. È esattamente qui che l’analogia con USB diventa potente, non perché tutti i dispositivi siano uguali ma perché entrambi i lati concordano su un’interfaccia comune.

Dove finisce l’analogia con USB

Una chiavetta USB viene collegata ed il sistema operativo possiede già driver e classi di dispositivo molto rigide, mentre nel mondo MCP la semantica dei tool rimane enormemente più libera. Due server possono entrambi esporre una funzione chiamata create_order e darle significati diversi, applicare regole commerciali differenti oppure richiedere autorizzazioni completamente diverse, quindi MCP risolve il problema del COME COMUNICARE ma non può risolvere automaticamente il problema del CHE COSA SIGNIFICA OGNI OPERAZIONE.

Questo è il motivo per cui un buon server MCP è molto più di un wrapper meccanico intorno ad una API. Deve progettare strumenti con nomi chiari, input ben vincolati, output strutturati, errori comprensibili e soprattutto una granularità che renda difficile utilizzare accidentalmente l’azione sbagliata. Un tool esegui_sql che accetta una query arbitraria può essere tecnicamente perfettamente valido secondo il protocollo ma rappresentare una pessima scelta architetturale in un ERP di produzione, mentre tool come leggi_scadenze_cliente, crea_bozza_ordine oppure annulla_ordine_se_autorizzato permettono di incorporare la business logic ed i controlli nei punti nei quali devono realmente vivere.

MCP locale e MCP remoto non sono la stessa cosa

Nei progetti per sviluppatori MCP è diventato popolare inizialmente attraverso server locali collegati via STDIO, cioè processi che l’host avvia come figli e con i quali comunica attraverso standard input e standard output. È un modello elegantemente semplice, perché non serve aprire porte di rete, non serve gestire un server web e l’isolamento può appoggiarsi anche ai normali privilegi del processo locale, quindi è perfetto per strumenti che devono leggere file, interrogare Git oppure utilizzare software installato sul computer.

Nel mondo enterprise prevale invece il server remoto, perché un ERP, un CRM oppure un data warehouse devono essere raggiunti da molti utenti ed applicazioni e quindi il trasporto più naturale diventa Streamable HTTP. La revisione MCP 2026-07-28 ha reso questo scenario molto più semplice da scalare eliminando dal core HTTP la necessità della sessione persistente usata nelle versioni precedenti, con ogni richiesta che dichiara versione del protocollo, identità e capacità necessarie e può arrivare su una qualsiasi replica del server dietro un normale load balancer. I metodi e, quando presente, il nome del tool vengono inoltre riflessi negli header Mcp-Method e Mcp-Name, così un gateway, un WAF oppure un rate limiter può prendere decisioni senza dover interpretare tutto il corpo JSON.

Le installazioni precedenti non sono diventate improvvisamente inutilizzabili, perché gli SDK mantengono compatibilità con l’era 2025 basata sull’handshake initialize, mentre i client moderni possono usare server/discover per conoscere in anticipo versioni e capacità offerte dal server. Questo è un dettaglio particolarmente utile per chi oggi deve implementare MCP in azienda, perché molti tutorial pubblicati nel 2025 descrivono ancora sessioni ed handshake che nella revisione 2026 non rappresentano più il modello principale del protocollo remoto.

Sotto MCP continua a vivere JSON-RPC

MCP non ha inventato da zero ogni strato della comunicazione e si appoggia a JSON-RPC 2.0 per rappresentare richieste, risposte ed errori, quindi una chiamata possiede un metodo, un identificativo, dei parametri ed un risultato oppure un errore. Questa scelta mantiene il protocollo relativamente leggibile anche durante il debugging, perché con un proxy od una traccia possiamo vedere una richiesta tools/call, il nome dello strumento e gli argomenti JSON che il client sta inviando.

Per chi non sviluppa software è sufficiente capire il principio, cioè che il modello non «entra» nel server MCP, ma produce una intenzione strutturata che il client trasforma in una chiamata conforme al protocollo, ed il server restituisce un risultato altrettanto strutturato. Fra queste due estremità possiamo quindi inserire controlli molto tradizionali e comprensibili, autenticazione, autorizzazione, rate limit, audit, timeout, approvazioni umane, policy sugli strumenti consentiti e filtri sugli argomenti, esattamente come faremmo con una API ben progettata.

L’esempio concreto di Dynamics 365 spiega perché le aziende stanno prendendo MCP sul serio

Un caso molto utile per comprendere il salto rispetto alle integrazioni classiche è Dynamics 365 Finance and Operations, perché Microsoft ha reso generalmente disponibile nel gennaio 2026 il server MCP per le applicazioni ERP ed ha successivamente esteso l’architettura dinamica fino a permettere agli agenti di accedere a quasi tutti i dati e alle operazioni di business disponibili nell’interfaccia del prodotto, comprese estensioni e personalizzazioni dell’ambiente. Microsoft descrive esplicitamente il vantaggio come la possibilità di evitare codice, connector ed API personalizzate per ogni singola operazione quando il server MCP dinamico espone già quella business logic.

Questa è probabilmente la forma più vicina alla promessa del «collego l’agente senza scrivere codice ad hoc», perché il lavoro di integrazione è stato spostato a monte ed è Microsoft ad offrire il livello MCP sul proprio ERP. Un agente compatibile può quindi scoprire funzioni del gestionale ed utilizzarle attraverso lo stesso protocollo con cui potrebbe parlare ad altri sistemi, ma il passaggio più importante è che Microsoft specifica chiaramente che MCP NON crea un nuovo confine di sicurezza e non concede privilegi autonomamente. Ogni richiesta viene valutata nel contesto dell’utente autenticato e continua ad essere soggetta alle stesse autorizzazioni, alla stessa business logic ed agli stessi controlli sui dati che esistono nel prodotto normale.

Questo è il modo corretto di intendere MCP in azienda: non una scorciatoia per aggirare i sistemi di sicurezza esistenti, ma un nuovo canale attraverso il quale gli stessi sistemi possono essere utilizzati dagli agenti.

Autenticazione ed autorizzazione: MCP non rende sicuro ciò che era insicuro

L’espressione «connessione in totale sicurezza» è quindi quella che eliminerei per prima da qualsiasi presentazione commerciale, perché MCP possiede meccanismi moderni di autorizzazione ed il protocollo 2026 ha ulteriormente irrigidito molti aspetti legati a OAuth ed OpenID Connect, ma un protocollo può soltanto fornire i mattoni con cui costruire una soluzione sicura, non certificare automaticamente l’architettura che qualcuno realizzerà sopra quei mattoni.

Nel caso dei server remoti, l’autorizzazione si integra con i normali meccanismi OAuth, con token che devono essere emessi per la risorsa corretta, scope coerenti ed identità che non devono essere confuse fra authorization server differenti, mentre la revisione 2026 ha aggiunto controlli specifici contro attacchi di issuer mix-up ed ha rafforzato l’isolamento delle credenziali. Ma se io configuro un tool che utilizza permanentemente un account amministratore globale per qualunque utente, il protocollo continuerà a trasportare perfettamente richieste pericolose. Il principio del least privilege rimane quindi identico a quello di qualsiasi altro sistema, l’agente dovrebbe poter fare soltanto ciò che serve a quel ruolo, con credenziali e scope più ristretti possibile.

Il vero pericolo non è soltanto l’hacker, è il testo che convince l’agente a usare male uno strumento legittimo

MCP rende molto evidente una categoria di rischio propria dei sistemi agentici, perché nel momento in cui un modello può leggere informazioni non affidabili e contemporaneamente possiede strumenti con effetti reali, un testo diventa potenzialmente una istruzione ostile. Un’email, una pagina web, un documento oppure persino il contenuto restituito da un altro server può contenere una prompt injection che tenta di convincere il modello ad ignorare le istruzioni precedenti ed utilizzare un tool in modo diverso da quello previsto.

Questo rischio non nasce da MCP ma MCP può amplificarne le conseguenze perché standardizza l’accesso agli strumenti, ed è precisamente il motivo per cui i maintainer insistono su consenso, isolamento delle credenziali, confini fra server e trattamento dei contenuti provenienti dall’esterno come input non affidabile. Nel 2026 perfino le nuove Skills MCP specificano esplicitamente che il contenuto servito da un server deve essere considerato un possibile vettore di prompt injection e non può acquisire autorità soltanto perché proviene da un server MCP collegato.

La regola pratica è abbastanza semplice: UN TOOL DISPONIBILE AL MODELLO NON DEVE ESSERE CONSIDERATO SICURO SOLTANTO PERCHÉ IL MODELLO SA CHIAMARLO CORRETTAMENTE. Se una operazione può cancellare dati, autorizzare un pagamento, inviare una comunicazione ufficiale oppure cambiare un permesso, conviene introdurre vincoli deterministici fuori dal modello, controlli di ruolo, limiti economici, approvazioni esplicite e magari strumenti distinti per lettura e scrittura.

Read-only e write non dovrebbero avere lo stesso peso

In un CRM aziendale un agente che legge la scheda di un cliente e riassume le ultime attività produce un rischio molto diverso da un agente che modifica il limite di credito, cancella un contatto oppure invia automaticamente un’offerta commerciale. MCP consente ai tool di dichiarare annotazioni relative al comportamento, per esempio se una operazione è read-only, distruttiva, idempotente oppure capace di raggiungere sistemi esterni, ma gli stessi maintainer ricordano che queste annotazioni sono informazioni descrittive e non sostituiscono una policy di sicurezza.

A mio parere un’implementazione enterprise dovrebbe quindi partire da strumenti di sola lettura ed aumentare gradualmente l’autonomia, perché possiamo misurare come il modello seleziona i tool, quali errori produce, quanto frequentemente chiede dati non necessari e quali prompt reali arrivano dagli utenti prima di concedergli operazioni che modificano lo stato del sistema. È lo stesso principio che applichiamo ad un nuovo dipendente, non gli consegniamo al primo giorno l’account amministratore del gestionale soltanto perché sa utilizzare bene l’interfaccia.

MCP non è RAG, anche se spesso i due vengono confusi

Un’altra distinzione utile riguarda il RAG, Retrieval-Augmented Generation, perché entrambi permettono ad un modello di lavorare con informazioni esterne ma risolvono problemi diversi. Un sistema RAG indicizza normalmente documenti, cerca i passaggi semanticamente pertinenti ed inserisce quei passaggi nel contesto del modello, quindi è eccellente quando devo rispondere usando manuali, contratti, procedure oppure grandi collezioni di testo.

MCP invece definisce COME un’applicazione AI interagisce con sistemi esterni, quindi attraverso MCP posso esporre proprio un motore RAG come tool, ma posso anche leggere lo stato di un ordine, avviare una procedura, chiamare una API, aprire un ticket, creare un documento oppure chiedere ad un gestionale di eseguire una operazione. RAG porta soprattutto CONOSCENZA nel contesto, MCP porta INTEROPERABILITÀ fra l’agente ed il mondo esterno, ed in una architettura reale i due sistemi possono convivere perfettamente.

MCP non è neppure una API universale che sostituisce tutte le API

È altrettanto sbagliato immaginare che MCP renda obsolete REST, GraphQL, SQL oppure le API proprietarie, perché nella maggior parte delle implementazioni il server MCP si appoggia proprio a queste tecnologie. Un gestionale può continuare ad avere le proprie API REST ed il server MCP può semplicemente trasformare un tool semanticamente chiaro in una sequenza di chiamate a quelle API; un database può continuare a parlare PostgreSQL ed il server MCP può esporre soltanto interrogazioni controllate; un sistema legacy può continuare perfino ad utilizzare SOAP e l’agente non deve saperlo.

Il vantaggio è che la COMPLESSITÀ SPECIFICA DEL SISTEMA RESTA DIETRO IL SERVER, mentre il client AI utilizza un contratto uniforme. È la stessa ragione per cui negli anni abbiamo costruito driver e middleware invece di pretendere che ogni applicazione conoscesse direttamente ogni periferica, ed è qui che l’analogia con la presa universale recupera tutto il proprio senso.

Senza codice ad hoc, ma soltanto dopo che qualcuno ha costruito l’adattatore

Supponiamo che una azienda utilizzi un vecchio ERP proprietario che non possiede alcun supporto MCP ma dispone di API per clienti, ordini e magazzino. Per rendere queste funzioni disponibili agli agenti qualcuno deve ancora costruire un server MCP, configurare l’autenticazione verso l’ERP e trasformare operazioni come inventory/check oppure orders/create in tool con schemi comprensibili. Quello sviluppo viene però eseguito UNA VOLTA, e successivamente ogni host compatibile con MCP può riutilizzarlo senza avere bisogno di un nuovo connettore specifico per ogni combinazione fra modello e gestionale.

Prima avevamo quindi una matrice quasi esplosiva, perché tre assistenti diversi collegati a quattro sistemi potevano richiedere fino a dodici integrazioni differenti, mentre con un livello realmente standardizzato possiamo costruire quattro server MCP e permettere ai tre host compatibili di utilizzarli. Naturalmente la matematica reale è più sporca, perché esistono differenze di autenticazione, deployment e policy, ma il vantaggio architetturale rimane ed è il motivo per cui questo standard è diventato interessante molto più rapidamente di tante altre proposte agentiche.

Cosa succede quando i tool diventano migliaia

L’adozione enterprise introduce però un problema che il piccolo esempio con tre funzioni non mostra, perché un ERP moderno può contenere migliaia o addirittura centinaia di migliaia di operazioni possibili ed inviare ogni descrizione al modello ad ogni richiesta sarebbe costosissimo e renderebbe il contesto inutilmente rumoroso. Il protocollo ha quindi sviluppato meccanismi di discovery, caching e descrizione sempre più precisi, mentre i runtime moderni aggiungono sistemi di tool search capaci di presentare al modello soltanto la parte del catalogo pertinente al compito corrente.

La revisione 2026 consente ai risultati di tools/list, resources/list, prompts/list e resources/read di indicare per quanto tempo possano essere considerati freschi e se la cache possa essere condivisa oppure debba restare privata per uno specifico contesto di autorizzazione. È un dettaglio che sembra poco importante fino a quando non si gestisce una flotta di agenti, perché impedisce di scaricare continuamente cataloghi identici, riduce latenza e costo ed evita soprattutto di confondere accidentalmente strumenti disponibili ad utenti con permessi differenti.

Le attività lunghe e il problema del lavoro che non finisce in una richiesta HTTP

Un agente non deve soltanto leggere record in pochi millisecondi, può lanciare un’elaborazione che dura minuti oppure ore, per esempio una migrazione, una analisi massiva, un test software oppure la produzione di un report molto pesante. MCP ha introdotto per questo il concetto di Tasks come estensione, attraverso il quale un server può restituire un identificativo di attività e consentire al client di controllarne stato, aggiornamenti, completamento, errore oppure cancellazione senza mantenere inutilmente una connessione bloccata per tutta la durata dell’operazione.

Anche questo mostra che MCP sta evolvendo da semplice meccanismo di tool calling ad infrastruttura per sistemi agentici reali, nei quali un’azione può avere un proprio ciclo di vita ed un agente deve sapere che cosa sta ancora lavorando, che cosa richiede input aggiuntivo e che cosa può essere annullato.

L’osservabilità rimane fondamentale

Quando un agente chiama un ERP non mi interessa soltanto sapere che la richiesta HTTP ha restituito 200, voglio poter ricostruire quale utente ha avviato l’azione, quale agente ha selezionato il tool, con quali argomenti, quale servizio è stato chiamato a valle, quanto tempo ha impiegato e quale errore ha eventualmente prodotto. La revisione 2026 documenta anche la propagazione dei contesti OpenTelemetry attraverso i metadata MCP, permettendo di correlare una richiesta che parte dall’host, attraversa il client, arriva al server MCP e continua nei sistemi sottostanti come una singola traccia distribuita.

Questo è un dettaglio essenziale per l’impiego professionale, perché se un agente modifica un ordine oppure genera una operazione contabile deve esistere una audit trail comprensibile anche da chi non sta osservando il modello in tempo reale. MCP può standardizzare parte di questa infrastruttura, ma l’azienda deve comunque decidere che cosa registrare, quanto conservarlo, come proteggere i log e quali azioni richiedano una conferma umana.

Un esempio completo: dall’italiano all’ERP senza dare all’AI le chiavi del magazzino

Immaginiamo che io chieda ad un assistente aziendale «controlla se abbiamo almeno cinquanta pezzi dell’articolo X, guarda gli ordini già confermati per questa settimana e dimmi se possiamo accettare una nuova commessa da quaranta pezzi». L’host passa la richiesta al modello e gli mette a disposizione i tool del server MCP dell’ERP, il modello individua quelli pertinenti, per esempio una funzione per leggere la giacenza ed una per recuperare gli impegni già confermati, quindi il client invia le chiamate MCP con argomenti strutturati.

Il server MCP autentica l’utente, verifica che possieda il diritto di leggere quei dati e chiama la business logic reale dell’ERP, poi restituisce giacenza, quantità impegnata e magari data prevista dei nuovi approvvigionamenti. Il modello combina questi risultati e mi spiega che cinquanta pezzi fisicamente presenti non significano cinquanta pezzi realmente disponibili perché trenta risultano già allocati. Fino a questo punto non è stato necessario concedere all’agente il diritto di modificare nulla.

Se poi aggiungo «crea una bozza d’ordine da quaranta pezzi», il modello può utilizzare un altro tool che crea esclusivamente bozze e non ordini definitivi, lasciando l’approvazione finale ad un responsabile umano oppure ad una seconda policy applicativa. È in questa separazione che MCP diventa realmente interessante, perché il linguaggio naturale permette di orchestrare il lavoro mentre il server continua ad imporre i confini deterministici che un LLM non dovrebbe essere libero di ridefinire.

La vera rivoluzione è che integrazione ed intelligenza smettono di essere incollate insieme

Prima di MCP ogni assistente rischiava di arrivare con il proprio ecosistema di plugin, connettori e formati, quindi scegliere un modello significava spesso scegliere contemporaneamente anche una particolare modalità di integrazione. Un protocollo aperto rompe questa dipendenza, perché il server che espone il CRM non deve necessariamente sapere quale modello lo utilizzerà ed il modello non deve necessariamente sapere come quel CRM sia implementato.

Questa separazione permette ad una azienda di investire nel proprio livello di accesso ai dati senza vincolarsi completamente al fornitore del modello, ed è forse questo il valore strategico più grande di MCP. Posso cambiare modello, runtime agentico oppure interfaccia utente mantenendo buona parte dei server MCP che rappresentano i miei sistemi aziendali, ed allo stesso modo il fornitore di un ERP può implementare una sola interfaccia standard e diventare immediatamente utilizzabile da una quantità crescente di host compatibili.

Non basta collegare il server, bisogna progettare il contratto fra agente e azienda

Per questo non considero MCP una scorciatoia che elimina l’ingegneria delle integrazioni, considero invece una tecnologia che permette finalmente di spostare l’ingegneria nel posto giusto. Non devo più spendere gran parte del tempo a riscrivere lo stesso adattatore per modelli differenti, posso usare quel tempo per decidere quali azioni abbia senso esporre, quali dati debbano essere filtrati, quali tool debbano essere read-only, quali operazioni richiedano approvazione e quali identità debbano essere propagate fino al sistema di origine.

Un server MCP fatto male può essere pericoloso esattamente come una API fatta male, ed anzi può diventarlo di più perché il chiamante è un agente capace di decidere autonomamente quale strumento utilizzare. Un server MCP fatto bene diventa invece una specie di CONTRATTO OPERATIVO fra il modello e l’azienda, nel quale ogni capacità disponibile possiede uno schema, un significato, un’autorizzazione ed un limite.

Perché nel 2026 MCP è diventato così importante

La diffusione di MCP non deriva quindi soltanto dal fatto che sia tecnicamente elegante, deriva dal momento storico nel quale è comparso. Finché l’AI serviva soprattutto a rispondere a domande, bastava fornirle un prompt ed eventualmente qualche documento, ma nel momento in cui gli agenti devono PRENDERE INFORMAZIONI DAL MONDO REALE ED AGIRE SUL MONDO REALE nasce inevitabilmente il problema di come collegarli a migliaia di applicazioni differenti senza costruire un ecosistema chiuso per ogni modello.

MCP offre una risposta sufficientemente semplice da essere adottata dagli sviluppatori e sufficientemente generale da interessare Microsoft, OpenAI, Anthropic, Google, AWS, Cloudflare ed i grandi produttori software, ed il passaggio sotto la Linux Foundation ha dato al protocollo una governance che rende più credibile investirci senza dipendere completamente dalla strategia commerciale di una singola azienda.

Ma il significato più interessante resta quello operativo, perché un agente collegato soltanto al proprio modello conosce ciò che trova nel contesto, mentre un agente collegato attraverso MCP può chiedere quanto abbiamo in magazzino, leggere lo stato di una pratica, aprire un ticket, recuperare un documento, controllare una fattura e, quando autorizzato, modificare realmente il sistema aziendale. È il passaggio dal chatbot che PARLA dell’azienda all’agente che LAVORA dentro l’azienda.

La presa USB dell’AI, sì, ma con un interruttore accanto

Alla fine considero quindi corretta l’analogia con la presa USB se ricordiamo che una presa non decide quali dispositivi sia prudente collegare, non stabilisce chi debba poterli utilizzare e non impedisce automaticamente ad un dispositivo ostile di creare problemi. MCP standardizza il modo attraverso il quale un agente scopre strumenti, dati e funzioni e rende possibile riutilizzare la stessa integrazione attraverso host differenti, ma sicurezza, identità, principio del minimo privilegio, business logic, audit ed approvazioni rimangono responsabilità dell’architettura che costruiamo intorno al protocollo.

Ed è proprio questa, a mio parere, la ragione per cui MCP è più importante di un semplice sistema di plugin. Non promette che l’AI sappia improvvisamente usare qualsiasi software del mondo senza preparazione, costruisce invece un LINGUAGGIO COMUNE con il quale quel software può dichiarare all’AI ciò che è disposto a farle fare. Una volta che ERP, CRM, repository, database, sistemi documentali e servizi interni iniziano a parlare lo stesso linguaggio operativo, cambiare modello non significa più ricostruire tutto da zero ed aggiungere un nuovo sistema non significa necessariamente scrivere un nuovo connettore per ogni agente.

La rivoluzione quindi non è che il codice di integrazione scompaia, è che smette di moltiplicarsi inutilmente ad ogni incrocio fra modello ed applicazione, ed è precisamente ciò che fanno gli standard quando funzionano davvero: non eliminano la complessità del mondo ma la spostano dietro una interfaccia comune permettendo di riutilizzare il lavoro già fatto.