MCP donato alla Linux Foundation: cosa cambia per gli agenti aziendali

Il 9 dicembre 2025 Anthropic ha donato il Model Context Protocol alla Agentic AI Foundation, un fondo dedicato sotto l'ombrello della Linux Foundation. È un dettaglio che la stampa tecnica ha trattato come notizia di settore, ma per chiunque stia costruendo agenti che toccano sistemi aziendali reali, gestionali, CRM, ERP, archivi documentali, è una delle poche decisioni del 2025 che cambia il calcolo del rischio architetturale. MCP è il protocollo che da novembre 2024 collega un modello linguistico ai tool e ai dati esterni: la metafora che gli è stata cucita addosso è quella della USB-C per l'AI, un connettore unico al posto di un adattatore proprietario per ogni integrazione. Fino a dicembre 2025 quel connettore aveva un proprietario: Anthropic. Da quella data ha uno steward neutrale, gli stessi che governano Kubernetes, Node.js e PyTorch. Nella mia pipeline personale di automazione scrivo server MCP custom per dare a Claude Code accesso controllato a basi di codice e dati interni da quasi un anno, e questa è la prima volta che posso consigliare a un decisore di costruirci sopra senza la riserva mentale del lock-in di piattaforma. In questo articolo spiego cosa cambia concretamente, e cosa non cambia, per chi deve scegliere su quale standard fondare la propria infrastruttura agentica.

Cosa significa, in pratica, che MCP è passato alla Linux Foundation?

Significa che il controllo del protocollo non è più nelle mani del vendor che lo ha inventato. La donazione del 9 dicembre 2025 trasferisce MCP alla Agentic AI Foundation (AAIF), co-fondata da Anthropic, Block e OpenAI, con Google, Microsoft, AWS, Cloudflare e Bloomberg tra i supporter. La Linux Foundation agisce da custode neutrale, mentre i maintainer del progetto mantengono il modello di governance community-driven già esistente. Sotto la stessa fondazione sono confluiti altri progetti fondativi come goose di Block e AGENTS.md di OpenAI.

Il punto non è simbolico. Quando uno standard è governato da una sola azienda, ogni tua decisione di adottarlo porta con sé una domanda implicita: cosa succede se quell'azienda cambia priorità, alza i prezzi del prodotto che ci gira sopra, o decide che il protocollo non serve più alla sua roadmap commerciale? La governance neutrale non elimina il rischio, lo redistribuisce: un consorzio che include tre laboratori AI concorrenti e cinque hyperscaler ha un incentivo strutturale a mantenere il protocollo stabile e aperto, perché nessuno di loro tollererebbe che un rivale ne prendesse il controllo. È la stessa logica per cui un'azienda si fida di Kubernetes molto più di quanto si fiderebbe di un orchestratore di container proprietario di un singolo cloud provider.

Uno standard governato da una fondazione neutrale non promette che non cambierà mai. Promette che a decidere come cambia non sarà un attore solo, con i suoi interessi commerciali, ma un processo trasparente in cui i tuoi stessi fornitori hanno voce.

Per un'azienda italiana che valuta dove investire budget di sviluppo, questa è la differenza tra "ho fatto un'integrazione con uno strumento di un vendor" e "ho costruito su uno standard di settore". Il secondo è un asset che sopravvive ai cambi di listino e di strategia del singolo fornitore. Se vuoi capire come questa logica architetturale si traduce in scelte concrete di prodotto, ne ho scritto nel mio hub dedicato all'AI per le aziende, dove raccolgo gli articoli su agenti, MCP e Claude Code con la metodologia e il perimetro che applico.

Perché la donazione riduce davvero il rischio di lock-in?

Perché sposta il punto di dipendenza dal vendor al protocollo, e un protocollo aperto con SDK in tutti i linguaggi principali è sostituibile in modo che un'API proprietaria non è. Il dato che misura la trazione è la curva dei download degli SDK: circa 2 milioni mensili al lancio di novembre 2024, saliti a 22 milioni dopo l'adozione di OpenAI ad aprile 2025, 45 milioni dopo Microsoft Copilot Studio a luglio, 68 milioni dopo AWS a novembre, e oltre 97 milioni mensili tra Python e TypeScript già al momento dell'annuncio della donazione, secondo la comunicazione ufficiale di Anthropic. Vanno letti come ordini di grandezza di adozione, non come metriche di precisione, ma la traiettoria è inequivocabile: in tredici mesi il protocollo è passato da esperimento di un vendor a infrastruttura adottata dai suoi diretti concorrenti.

La conseguenza pratica è l'interoperabilità lato client. Un server MCP che scrivi una volta, per esporre il tuo gestionale o il tuo archivio documentale, parla con ChatGPT, Cursor, Gemini, Microsoft Copilot e VS Code senza riscritture, perché tutti questi client implementano lo stesso protocollo. Questa è la proprietà che cambia il calcolo economico di un progetto: l'investimento di engineering nel server non è legato alla scommessa su quale modello vincerà. Se domani Claude smette di essere il modello migliore per il tuo caso d'uso e passi a un concorrente, il server MCP resta. È esattamente lo stesso principio di disaccoppiamento che applico quando progetto un abstraction layer tra applicazione e provider del modello, un tema che ho trattato nell'articolo su come progettare la sostituibilità del modello AI.

C'è un secondo segnale di maturità che pesa più degli annunci: a dicembre 2025 erano attivi oltre 10.000 server MCP pubblici, con un registro ufficiale community-driven per la loro scoperta. Quando un ecosistema raggiunge quel numero di implementazioni indipendenti, lo standard smette di essere "cutting edge sperimentale" e diventa commodity ingegneristica: trovi esempi, librerie mature, pattern consolidati e soprattutto altre persone che hanno già sbattuto la testa sui problemi che incontrerai tu.

Cosa cambia per chi ha già costruito server MCP?

Qui arriva la parte che un decisore deve capire prima di firmare un budget pluriennale: uno standard vivo continua a evolvere, e MCP sta per introdurre breaking change. La specifica stabile corrente è quella del 25 novembre 2025, che ha portato operazioni asincrone, statelessness, identità del server e le estensioni ufficiali. Ma il 21 maggio 2026 i maintainer hanno annunciato una Release Candidate con finalizzazione prevista per il 28 luglio 2026, e questa versione contiene cambiamenti incompatibili con il passato.

Le modifiche non sono cosmetiche. Il core del protocollo diventa stateless a livello di specifica, il che significa che un server MCP scala su HTTP ordinario senza bisogno di sticky session, un cambiamento che semplifica enormemente il deployment dietro un load balancer. Le Extensions ottengono un framework di governance formale; la feature sperimentale Tasks viene degradata da componente core a estensione; e arrivano le MCP Apps, interfacce HTML renderizzate dal server dentro un iframe sandboxed, che aprono la porta a tool con una vera UI invece del solo scambio di testo strutturato. Tutto questo è documentato nel post ufficiale sulla Release Candidate.

Il dettaglio che dovrebbe rassicurare chi ha investito è un altro, e nasce proprio dalla nuova governance: la Release Candidate introduce una deprecation policy formale, con un minimo di dodici mesi tra l'annuncio di una deprecazione e la sua rimozione, più una finestra di validazione di dieci settimane per gli SDK di primo livello prima del rilascio finale. Tradotto: lo standard cambia, ma adesso cambia con un contratto pubblico su quanto tempo hai per adeguarti.

La differenza tra un protocollo vendor-driven e uno governato da una fondazione non è che il primo non rompe la compatibilità e il secondo sì. È che il secondo ti dice con dodici mesi di anticipo cosa romperà, e quel preavviso è un asset di pianificazione che un singolo vendor non è obbligato a darti.

Per chi gestisce server MCP in produzione, l'implicazione operativa è chiara: la migrazione verso il core stateless va messa in roadmap adesso, non quando il vecchio comportamento smetterà di funzionare. È esattamente il tipo di intervento che si pianifica con calma se lo vedi arrivare con un anno di anticipo, e che diventa un'emergenza se lo scopri a deprecazione avvenuta.

La neutralità della governance basta a renderlo lo standard "definitivo"?

No, ed è importante essere precisi su questo punto per non vendere illusioni. MCP è uno standard aperto e dominante per connettere agenti a tool e dati, ma non è l'unico protocollo della galassia agentica, e non lo sarà. Sul versante del commercio agentico convivono altri standard con funzioni diverse: l'Universal Commerce Protocol promosso da Google con Shopify e oltre venti partner copre l'intero percorso d'acquisto, mentre l'Agentic Commerce Protocol di OpenAI e Stripe è focalizzato sull'interazione chat-to-buy dentro un assistente. Questi protocolli non competono con MCP, lo affiancano: MCP è trasversale, gli altri sono specifici di una superficie.

Chi ti racconta che "MCP è il nuovo standard universale" o che "ormai Anthropic possiede l'integrazione AI" sta sbagliando su entrambi i fronti. MCP è uno standard aperto tra altri, e dal 9 dicembre 2025 non è più di proprietà di Anthropic. La lettura corretta per un'architettura aziendale è che servono più protocolli insieme, ognuno per il momento giusto del flusso, con un backend condiviso sotto. Trattare l'agentic-ready come una scelta di vendor singolo è l'errore che produce le integrazioni fragili che poi vanno rifatte.

Vale la pena anche un caveat di onestà sulla parola "stabilità". La donazione alla Linux Foundation non congela il protocollo: la Release Candidate del luglio 2026, con i suoi breaking change, è la prova che lo standard è vivo e continuerà a muoversi. La neutralità della governance non ti dà immunità dai cambiamenti, ti dà un processo trasparente e una finestra di preavviso. Confondere le due cose porta a pianificare male.

Come si traduce tutto questo in una decisione architetturale?

La traduzione operativa è che MCP è oggi la base difendibile su cui costruire l'accesso degli agenti ai sistemi interni. Quando progetto l'infrastruttura agentica di un'azienda, il server MCP custom è il punto in cui un modello linguistico incontra il legacy: il gestionale che gira da quindici anni, il database di produzione, l'archivio dei documenti tecnici. Esporre quei sistemi attraverso un protocollo standard, invece che con un'integrazione one-off legata a un singolo strumento, è ciò che separa un esperimento da un asset.

Il lavoro vero, però, è nel come esponi quei sistemi, e qui la sicurezza è la metà del problema. Un server MCP è una superficie di attacco: dà a un agente la capacità di chiamare funzioni che toccano dati reali. Il principio del privilegio minimo, lo scoping dei token, la validazione degli input e l'audit trail di ogni chiamata sono parte integrante del design, non un livello da aggiungere dopo. Ho approfondito i rischi specifici di un MCP mal progettato nell'articolo sull'over-broad token scoping nei server MCP, perché è esattamente il tipo di errore che trasforma un'integrazione utile in un vettore di privilege escalation.

Una piccola illustrazione di cosa intendo per design pulito: un server MCP ben progettato dichiara capability esplicite e granulari, non un accesso indiscriminato.

server: crm-readonly
capabilities:
  - list_clienti        scope: read
  - dettaglio_ordine    scope: read
  - nota_interna        scope: write, richiede conferma human-in-the-loop
deny_default: true
audit: ogni chiamata loggata con id agente, timestamp, parametri

La differenza tra questo e un server che espone l'intero gestionale con un token onnipotente è la differenza tra un'azienda che può dormire la notte e una che ha messo un agente autonomo alla guida del proprio database senza freni. La governance neutrale di MCP rende il protocollo affidabile come fondamenta; la qualità del tuo design dei server decide se quelle fondamenta reggono un edificio sicuro.

C'è poi una dimensione di scala produttiva che il protocollo da solo non risolve: quando un agente ha accesso a centinaia di tool, la latenza e il consumo di token per selezionare quello giusto diventano un problema reale. Anthropic ha rilasciato meccanismi come Tool Search e Programmatic Tool Calling proprio per gestire deployment con migliaia di tool, e il fatto che esistano è un altro segnale che MCP è uscito dalla fase dimostrativa per entrare in quella delle architetture di produzione.

Cosa dovrebbe fare un'azienda italiana adesso?

La risposta dipende da dove sei, ma il principio è uno solo: trattare MCP come una scelta di lungo periodo da fare con cognizione, non come una moda da inseguire. Se non hai ancora costruito nulla, la donazione alla Linux Foundation è il segnale che il momento di iniziare a progettare seriamente è arrivato, perché lo standard ha la stabilità di governance e la massa critica di adozione che un anno fa non aveva. Se hai già server MCP in produzione, la priorità è mettere in roadmap la migrazione verso il core stateless della specifica di luglio 2026, sfruttando la finestra di dodici mesi della deprecation policy invece di subirla. E se stai valutando un'architettura agentica completa, il deliverable non è un singolo protocollo, ma un design multi-protocollo con un backend condiviso e un modello di sicurezza esplicito su ogni server.

Il filo che lega questi scenari è la sostituibilità. Costruire su uno standard governato da una fondazione neutrale, esporre i sistemi interni con il privilegio minimo, disaccoppiare l'applicazione dal singolo modello: sono le tre mosse che trasformano l'adozione dell'AI da scommessa su un vendor a infrastruttura che resta tua. Il consulente AI medio italiano vende l'integrazione con lo strumento di moda del trimestre; il lavoro che invece difende il valore di un'azienda nel tempo è progettare il sistema in modo che lo strumento di moda sia rimpiazzabile senza rifare tutto da capo. La donazione di MCP alla Linux Foundation è uno dei pochi eventi recenti che rendono questa seconda strada non solo possibile, ma concretamente conveniente.

Se hai un progetto agentico concreto e vuoi capire se rientra nel mio perimetro, dalla scelta dei protocolli al design sicuro dei server MCP fino alla governance dei costi, puoi usare il modulo di preventivo gratuito: sette domande, due minuti, e ti dico subito se posso aiutarti o se è più sensato indirizzarti altrove.