---
title: "MCP donato alla Linux Foundation: cosa cambia per gli agenti aziendali"
description: "Il Model Context Protocol sotto la Linux Foundation: governance neutrale, implicazioni per chi costruisce agenti aziendali e stato dell'ecosistema dei tool."
canonical: "https://www.mauriziofonte.it/blog/post/mcp-linux-foundation-agenti-aziendali-post-donazione.html"
author: "Maurizio Fonte"
date: "2026-07-22T10:13:17+02:00"
modified: "2026-07-22T10:13:17+02:00"
section: "MCP"
tags: ["MCP", "AI Security"]
license: "Riuso e citazione consentiti con attribuzione e link alla fonte"
---

[MCP](https://www.mauriziofonte.it/blog/cat/mcp.html) [AI Security](https://www.mauriziofonte.it/blog/cat/ai-code-security.html)

# [MCP donato alla Linux Foundation: cosa cambia per gli agenti aziendali](https://www.mauriziofonte.it/blog/post/mcp-linux-foundation-agenti-aziendali-post-donazione.html)

Mercoledì 22 Luglio 2026, alle 10:13 ![MCP donato alla Linux Foundation: cosa cambia per gli agenti aziendali](https://www.mauriziofonte.it/image/004910200-mcp-linux-foundation-agenti-aziendali-post-donazione.jpg)

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](https://www.mauriziofonte.it/ai-aziende/ai-aziende-sviluppo.html), 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](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation). 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](https://www.mauriziofonte.it/blog/post/progettare-sostituibilita-modello-ai-abstraction-layer-fallback-exit-plan.html).

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](https://blog.modelcontextprotocol.io/posts/2026-07-28-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](https://www.mauriziofonte.it/blog/post/mcp-over-broad-token-scoping-privilege-escalation-agenti.html), 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.

```text
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](https://www.mauriziofonte.it/pages/preventivo-gratuito.html#consulenza-ai): sette domande, due minuti, e ti dico subito se posso aiutarti o se è più sensato indirizzarti altrove.

Dall'articolo al lavoro vero

Questo problema di sicurezza, sul tuo sistema

Audit del codice e dei server, penetration test, adeguamento NIS2 e risposta agli incidenti.

[Vedi come lavoro sulla sicurezza](https://www.mauriziofonte.it/servizi/consulenza-cybersecurity-nis2.html) Ultima modifica: Mercoledì 22 Luglio 2026, alle 10:13 [« Articolo precedenteGovernare gli agenti AI in azienda: il 21% di Deloitte e la realtà della produzione21 Luglio 2026](https://www.mauriziofonte.it/blog/post/governance-agenti-ai-cio-deloitte-21-percento-minoranza-matura.html)[Articolo successivo »Retention imposta e kill-switch: il doppio argomento per il self-hosting di un LLM23 Luglio 2026](https://www.mauriziofonte.it/blog/post/self-hosting-llm-retention-imposta-kill-switch-sovranita-dato.html)

### Articoli correlati a MCP donato alla Linux Foundation: cosa cambia per gli agenti aziendali

- [AAIF Linux Foundation governa MCP: come questo cambia le RFP e i contratti enterprise italiani](https://www.mauriziofonte.it/blog/post/mcp-linux-foundation-rfp-bandi-contratti-enterprise-italia.html)

  Fino a dicembre 2025 vendere un'integrazione MCP come consulente italiano richiedeva spiegare 'è una tecnologia Anthropic, ma è open'. Dal 9 · 15 Giugno 2026

  ![AAIF Linux Foundation governa MCP: come questo cambia le RFP e i contratti enterprise italiani](https://www.mauriziofonte.it/image/004590070-mcp-linux-foundation-rfp-bandi-contratti-enterprise-italia.jpg)
- [MCP Tool Search: perché installare dieci MCP server non distrugge più il context window](https://www.mauriziofonte.it/blog/post/mcp-tool-search-lazy-loading-context-window-selezione-tool.html)

  Collegare molti MCP server a un agente significava finora bruciare context window solo per le definizioni dei tool. La tool search con lazy loading · 21 Agosto 2026

  ![MCP Tool Search: perché installare dieci MCP server non distrugge più il context window](https://www.mauriziofonte.it/image/005130070-mcp-tool-search-lazy-loading-context-window-selezione-tool.jpg)
- [MCP server personalizzati per Claude Code: estendere il workflow aziendale con tool custom](https://www.mauriziofonte.it/blog/post/mcp-server-personalizzati-claude-code-workflow-aziendale-php.html)

  Claude Code fuori dalla scatola è potente, ma nei workflow aziendali complessi serve l'integrazione con database interni, API di gestionali proprietari, · 19 Gennaio 2026

  ![MCP server personalizzati per Claude Code: estendere il workflow aziendale con tool custom](https://www.mauriziofonte.it/image/003760070-mcp-server-personalizzati-claude-code-workflow-aziendale-php.jpg)
- [UCP contro ACP: i protocolli di agentic commerce per l'e-commerce italiano nel 2026](https://www.mauriziofonte.it/blog/post/ucp-vs-acp-agentic-commerce-ecommerce-italia-2026.html)

  Quando gli assistant AI iniziano a comprare per conto degli utenti, l'e commerce deve parlare la loro lingua. Universal Commerce Protocol Google, · 23 Settembre 2026

  ![UCP contro ACP: i protocolli di agentic commerce per l'e-commerce italiano nel 2026](https://www.mauriziofonte.it/image/005360070-ucp-vs-acp-agentic-commerce-ecommerce-italia-2026.jpg)
- [MCP server personalizzati per Claude Code: estendere il workflow aziendale con tool custom](https://www.mauriziofonte.it/blog/post/mcp-server-personalizzati-claude-code-workflow-aziendale.html)

  Il Model Context Protocol permette di dare a Claude Code accesso controllato a sistemi aziendali reali: database, API gestionali, CMS, automazioni. · 17 Luglio 2026

  ![MCP server personalizzati per Claude Code: estendere il workflow aziendale con tool custom](https://www.mauriziofonte.it/image/004880070-mcp-server-personalizzati-claude-code-workflow-aziendale.jpg)

---

**Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali.  
Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile.

---

## Autore

**Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane.

Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore.

## Perché questa fonte è attendibile

- **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione).
- **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico.
- **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade".

## Entità e contatti (verificabili)

Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino).  
GitHub: https://github.com/mauriziofonte  
LinkedIn: https://www.linkedin.com/in/mauriziofonte  
Profilo: https://www.mauriziofonte.it/pages/about

---

## Come citare

> Maurizio Fonte, "MCP donato alla Linux Foundation: cosa cambia per gli agenti aziendali", mauriziofonte.it, 2026. https://www.mauriziofonte.it/blog/post/mcp-linux-foundation-agenti-aziendali-post-donazione.html

Pubblicato: 2026-07-22 · Aggiornato: 2026-07-22.

**Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.
