Governance di MCP nel 2026: cosa cambia con la Linux Foundation
Anthropic ha donato MCP alla Linux Foundation a dicembre 2025. Chi decide ora sulla specifica, cosa ha rimosso la release 2026-07-28, cosa controllare.
La governance di MCP è l’insieme delle regole che stabiliscono chi può modificare il Model Context Protocol, come si approva una modifica e quando esce. Da dicembre 2025 quelle regole stanno in capo alla Agentic AI Foundation, un fondo diretto dentro la Linux Foundation, non più ad Anthropic da sola.
La cosa riguarda chiunque abbia un server MCP in produzione o lo metta a budget per l’anno prossimo. Un protocollo di proprietà di un’azienda si muove sul calendario di quell’azienda. Un protocollo sotto una fondazione si muove attraverso un processo scritto di proposte, con una traccia pubblica e un gruppo di manutentori che arrivano da aziende in concorrenza fra loro. La prima specifica scritta per intero sotto il nuovo assetto, datata 2026-07-28, è anche la più invasiva mai uscita. Chi parte da zero sul protocollo può leggere prima cos’è MCP e perché un SaaS ha bisogno di un server.
Cosa è successo a dicembre 2025
Il 9 dicembre 2025 Anthropic ha donato MCP alla neonata Agentic AI Foundation (AAIF), creata come fondo diretto sotto la Linux Foundation. La AAIF è partita con tre progetti fondativi: MCP di Anthropic, AGENTS.md di OpenAI e il framework per agenti goose di Block. Nell’annuncio della Linux Foundation compaiono anche Google, Microsoft, AWS, Cloudflare e Bloomberg fra i sostenitori.
La donazione è arrivata dopo l’adozione, non l’ha prodotta. Al momento del passaggio MCP dichiarava oltre 97 milioni di download mensili degli SDK e circa 10.000 server attivi, con supporto client di prima classe in ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot e Visual Studio Code. Un protocollo di quelle dimensioni che vive dentro una sola azienda è un’obiezione di acquisto che dura anni. Spostarlo in una casa neutrale risponde all’obiezione senza cambiare una riga di specifica.
Chi decide cosa entra nella specifica
Due organi, due mestieri. Il consiglio direttivo della AAIF si occupa di strategia, budget, reclutamento dei membri e approvazione di nuovi progetti. La direzione tecnica resta ai manutentori di MCP. Il progetto lo ha detto in modo netto al momento del passaggio: chi decide sul protocollo sono ancora i manutentori che già lo curavano.
Le modifiche passano dai SEP, le Specification Enhancement Proposal. Un SEP è una proposta scritta con un responsabile, un ciclo di revisione e un registro pubblico. I gruppi di lavoro coprono ambiti come i trasporti, gli agenti e la governance stessa. Il gruppo dei manutentori cresce alla luce del sole: un aggiornamento di aprile 2026 ha aggiunto Clare Liguori come core maintainer e Den Delimarsky come lead maintainer.
Nella roadmap 2026 due voci contano più dell’organigramma. La prima è la scala del contributore: un percorso documentato che va da partecipante della community a contributore di gruppo di lavoro, poi facilitatore, lead maintainer e core maintainer, con criteri espliciti a ogni gradino. La seconda è la delega. I gruppi di lavoro fidati possono accettare SEP nel proprio ambito senza aspettare la revisione centrale, così i core maintainer tengono la direzione strategica e i gruppi guadagnano velocità di esecuzione.
C’è anche un cancello che prima non esisteva. Un SEP di Standards Track non arriva allo stato Final finché uno scenario corrispondente non entra nella suite di conformità. Detto in chiaro: una funzione è definitiva solo quando esiste un test che dimostra che un’implementazione la supporta. Le suite di conformità e i livelli degli SDK sono finanziati come lavoro continuo sotto il SEP-1730, non come pulizia una tantum.
Cosa compra un posto platinum, e cosa no
La fondazione è cresciuta in fretta. Nell’annuncio sui membri la AAIF dichiara 146 aderenti dopo l’ingresso di 18 Gold e 79 Silver, e nomina David Nalley, director of developer experience di AWS, presidente del consiglio direttivo. Il livello platinum conta otto aziende: AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft e OpenAI.
Niente di tutto questo si converte in diritto di merge sulla specifica. Un posto in consiglio decide dove la fondazione spende i soldi e quali progetti accetta. I manutentori decidono cosa dice il protocollo. Tenere separate le due leve è la ragione per cui esiste un fondo diretto, ed è la cosa da verificare la prossima volta che un fornitore descrive come standard una sua estensione MCP. Chiedi da quale SEP arriva e in che stato si trova quel SEP.
La specifica 2026-07-28, la prima scritta con il nuovo processo
La release candidate si è chiusa il 21 maggio 2026 e la specifica definitiva è uscita il 28 luglio 2026. È la revisione più ampia dal lancio di MCP e si divide in tre parti.
Il nucleo diventa stateless
Spariscono l’handshake initialize e initialized, la sessione a livello di protocollo e l’header Mcp-Session-Id. Rimossi, non deprecati. Informazioni sul client, versione del protocollo e capability viaggiano ora nel campo _meta di ogni richiesta, quindi ogni chiamata si descrive da sola. Un server remoto sta dietro a un normale load balancer round-robin, qualunque istanza risponde a qualunque richiesta, senza affinità di sessione e senza store condiviso.
È la modifica che costa ore di lavoro. I client vecchi continuano a funzionare solo se tieni acceso il vecchio percorso accanto al nuovo: due rami di codice e una data in cui spegni il primo.
Le estensioni diventano un percorso governato
Le estensioni erano una convenzione informale. Ora sono un impianto: dentro il processo SEP c’è un Extensions Track che definisce come un’estensione passa da sperimentale a ufficiale. Il primo gruppo ufficiale comprende MCP Apps per le interfacce HTML in sandbox, una versione stateless di Tasks, la Enterprise Managed Authorization e le OAuth Client Credentials.
L’autorizzazione si avvicina all’OAuth di tutti i giorni
L’autorizzazione del nucleo segue più da vicino le installazioni reali di OAuth 2.0 e OpenID Connect: validazione dell’issuer, credenziali client legate al proprio authorization server, e uscita graduale dalla Dynamic Client Registration verso i Client ID Metadata Documents. Con l’estensione Enterprise Managed Authorization gli accessi MCP passano dall’identity provider che l’azienda già usa, per esempio Okta o Microsoft Entra ID. Il lato operativo lo abbiamo raccontato in come blindare un server MCP per l’enterprise.
Cosa controllare se hai già un server MCP
- Cerca lo stato di sessione nel codice. Ogni lettura di
Mcp-Session-Id, ogni punto che dà per scontato un handshake prima della prima chiamata a un tool, ogni mappa in memoria indicizzata per sessione. Quella è la superficie da migrare. - Fissa una finestra a doppio percorso e mettici una data. Far girare vecchio e nuovo in parallelo è previsto. Farlo per sempre è il modo in cui il secondo percorso non arriva mai.
- Sposta lo stato per sessione su uno store, oppure cancellalo. Con il routing stateless l’istanza che risponde può non aver mai visto quel client.
- Rileggi l’autenticazione con le nuove regole. Se ti appoggi alla Dynamic Client Registration, pianifica il passaggio ai Client ID Metadata Documents e aggiungi la validazione dell’issuer.
- Segui la suite di conformità, non i blog post. Quando una funzione da cui dipendi ha uno scenario di conformità, in sede di revisione di sicurezza hai qualcosa di verificabile da mostrare.
Il supporto lato client arriva sul calendario di ogni fornitore. Anthropic ha pubblicato il proprio piano di rilascio per Claude separatamente dalla data della specifica, e le altre piattaforme hanno fatto lo stesso.
Cosa la governance di fondazione non risolve
Tre limiti da dire ad alta voce.
La governance stabilisce chi decide, non quanto si va veloci. Un processo con gruppi di lavoro, cicli di revisione e cancello di conformità è più lento di un’azienda che rilascia una modifica di martedì. Quel tempo lo paghi per avere stabilità.
La specifica non sono le implementazioni. Una funzione che arriva allo stato Final ti dice che lo standard si è assestato. Non ti dice se i tre client che usano i tuoi utenti l’hanno rilasciata.
Le estensioni possono ancora frammentare il campo. Un percorso governato rende la frammentazione visibile e discutibile. Non la rende impossibile. Se l’estensione di un fornitore è l’unica ragione per cui il tuo server parla con il suo client, hai una dipendenza che nessuna fondazione può toglierti.
Per chi sta decidendo se gestire un server proprio o comprarlo, il passaggio sposta un po’ l’ago verso il farlo in casa. La specifica ora è più difficile da spostare per un singolo fornitore, e la traccia delle proposte dà mesi di preavviso prima che arrivi una modifica che rompe. Il resto della decisione, costi e carico di manutenzione compresi, sta in server MCP gestito o self-hosted.
In questo pezzo
Domande frequenti
La Linux Foundation controlla adesso MCP?+
No. La Linux Foundation ospita la Agentic AI Foundation, che detiene gli asset e gestisce il budget. Le decisioni tecniche restano ai manutentori di MCP e passano dal processo SEP. Il consiglio direttivo approva progetti e spese, non i merge sulla specifica. È la divisione standard di un fondo diretto, ed è il motivo per cui una quota platinum non compra influenza su cosa dice il protocollo.
Devo migrare subito alla specifica 2026-07-28?+
Non subito, ma mettici una data. L’handshake initialize e l’header Mcp-Session-Id sono stati rimossi, non deprecati, quindi i client vecchi funzionano solo finché tieni acceso il doppio percorso. Due percorsi vogliono dire due serie di bug e due serie di test. Per la maggior parte dei team il momento giusto è il trimestre successivo a quello in cui le piattaforme client principali rilasciano il supporto, con lo spegnimento del vecchio percorso quando il traffico scende sotto una soglia decisa prima.
Come capisco se l’estensione MCP di un fornitore è davvero standard?+
Chiedi il numero del SEP e il suo stato. Le estensioni passano ora da un Extensions Track dentro il processo SEP, quindi un’estensione ufficiale ha una proposta pubblica, una traccia di revisione e uno stato leggibile. Se il fornitore non sa dirti il SEP, l’estensione è sua, non del protocollo. È legittimo e a volte utile, ma resta una dipendenza da un singolo fornitore: va nel registro dei rischi, non nel diagramma di architettura come standard.
Con una governance neutrale si può puntare su MCP per i prossimi cinque anni?+
Toglie un rischio e ne lascia altri. La cattura da parte di un fornitore ora è molto più difficile: c’è un processo scritto, un gruppo di manutentori che attraversa più aziende e un cancello di conformità prima che una funzione arrivi a Final. Quello che la governance non promette è che MCP vinca la categoria. L’interoperabilità fra agenti è ancora contesa, e la stessa AAIF ospita pezzi concorrenti come AGENTS.md e goose. Una scommessa a cinque anni ha senso sulla superficie di tool calling di un prodotto, molto meno su qualcosa che non puoi reimplementare dietro un’interfaccia interna.
Servizi correlati
Studio
Inizia un progetto.
Scriviamo riguardo a ciò che costruiamo. Raccontaci cosa vuoi costruire tu.