110 milioni di download al mese. In 18 mesi, il Model Context Protocol (MCP) ha superato il ritmo di adozione di React, raddoppiandolo. E siamo solo all’inizio.
MCP è il protocollo aperto introdotto da Anthropic nel 2024 che standardizza il modo in cui gli agenti AI parlano con strumenti, dati e applicazioni esterne. Nel 2026 diventa la spina dorsale della connettività enterprise: progressive discovery, cross-app access, skills over MCP e nuove primitive per agenti che non si limitano più a scrivere codice, ma fanno il lavoro di un analista finanziario, di un marketing manager, di un knowledge worker.
David Soria Parra, che guida MCP in Anthropic, ha appena fatto il punto sulla direzione del 2026. Vale la pena capirla bene, perché decide dove andranno investimenti AI e architetture dei prossimi dodici mesi.
Dal local-only ai 110 milioni di download: cosa è cambiato per MCP
Diciotto mesi fa MCP era un documento di specifica, qualche SDK scritto perlopiù da Claude, limitato al locale, con poco più dei tools come primitiva disponibile. Oggi è dentro l’SDK agentico di OpenAI, dentro l’ADK di Google, dentro LangChain, dentro migliaia di framework che lo importano come dipendenza anche senza saperlo.
Un dettaglio utile per dimensionare il fenomeno: React, uno dei progetti open source più di successo dell’ultimo decennio, ha impiegato circa il doppio del tempo per arrivare allo stesso volume mensile di download.
La community ha prodotto server per Linear, Slack, Notion, WhatsApp, Blender, GitHub. Ma il grosso dei server MCP vive dietro porte chiuse, dentro le aziende, a collegare sistemi interni ad agenti AI. È lì che il protocollo sta creando più valore, e anche più rischio.
Perché il 2026 è l’anno della connettività, non del coding
Nel 2025 hanno dominato i coding agents. Sono il caso d’uso più facile per un agente: ambiente locale, compilatore che verifica l’output, sviluppatore davanti alla tastiera pronto a correggere. Un laboratorio protetto con un feedback loop immediato.
Il 2026 apre una fase diversa. Gli agenti generalisti, quelli che servono a un analista finanziario, a chi fa marketing, a chi gestisce operations, hanno bisogno di una cosa sola: connettività. Non un compilatore, ma cinque SaaS, un drive condiviso, un CRM, una sequenza di dati da muovere tra sistemi diversi.
Qui arriva il primo punto che il mercato sbaglia spesso. Quando qualcuno dice che esiste “la” soluzione universale alla connettività, probabilmente sta vendendo qualcosa. Computer use, CLI, MCP e skills sono strumenti diversi per problemi diversi, e il lavoro di chi progetta agenti è scegliere la combinazione giusta.
Progressive discovery: il pattern per non saturare il context window
Qui si gioca una bella fetta della partita 2026. Quasi tutti, finora, hanno costruito agenti MCP caricando tutti i tool disponibili nel context window alla partenza. Poi si sono stupiti di ritrovarsi con finestre gonfie, latenza alta e costi di inferenza in crescita costante.
Progressive discovery ribalta il pattern. Invece di caricare i tool, carichi un tool search. Il modello chiede “mi serve uno strumento per X” e solo allora la definizione entra nel contesto. Su Claude Code, dopo l’adozione del pattern, la riduzione dell’uso di token è stata drastica.
Il secondo pattern si chiama programmatic tool calling, o code mode. Invece di far chiamare al modello un tool dopo l’altro, ricevendo risultato ed elaborando prima della chiamata successiva, gli dai un REPL dentro un ambiente isolato (un V8, un sandbox Lua) e lo lasci scrivere uno script che compone le chiamate. Meno inferenza, meno latenza, composizione più elegante.
In pratica, invece di orchestrare il modello, lo trasformi in autore del programma di orchestrazione.
- Context window gonfio
- Latenza alta
- Costi di inferenza in crescita
- Un solo tool search iniziale
- Definizioni caricate al bisogno
- Context ridotto drasticamente
Progressive discovery: il pattern che riduce il consumo di token caricando i tool solo quando servono.
Skills, MCP, CLI: lo stack giusto per la connettività degli agenti AI
Nessuno di questi tre strumenti è superiore agli altri in assoluto. Ciascuno risolve un pezzo specifico del problema, e il design dell’agente consiste nello scegliere bene la combinazione.
| Strumento | Quando usarlo | Punti forti |
|---|---|---|
| Skills | Conoscenza di dominio, capability specifiche riutilizzabili | File semplici, portabili tra piattaforme |
| CLI | Agenti locali con sandbox, tool già in pre-training (Git, GitHub) | Discovery automatica, zero overhead iniziale |
| MCP | Semantica ricca, UI, autorizzazione, governance, task a lungo termine | Decoupling, platform independence, primitive avanzate |
Gli agenti più capaci del 2026 useranno tutti e tre nello stesso task, alternandoli in base al contesto. Il vero lavoro, lato harness, sarà fare in modo che il modello scelga la combinazione giusta senza esaurirsi nel tentativo.
Cosa arriva nel 2026: stateless transport, cross-app access, skills over MCP
Anthropic ha già mappato la roadmap con una trasparenza inusuale per il settore. Le voci più pesanti:
- Stateless transport protocol: il trasporto HTTP attuale è difficile da scalare per grandi piattaforme. Google sta portando avanti una variante stateless che permette di trattare un server MCP come un normale servizio REST, deployabile su Cloud Run o Kubernetes con i pattern noti. In arrivo a giugno 2026.
- Cross-app access: un single sign-on agentico. Una volta autenticati al provider aziendale (Okta, Google Workspace), i server MCP diventano usabili senza doversi riautenticare a ognuno. Meno attrito, più governance centralizzata.
- Server discovery via well-known URL: un crawler, un browser o un agente visitano un dominio e chiedono “hai un server MCP?”. Se la risposta è sì, il server diventa immediatamente usabile.
- Skills over MCP: un server con decine di tool potrà spedire, insieme ai tool, anche la conoscenza d’uso. Aggiornabile in continuo, senza passare da plugin o registry esterni.
- MCP Applications: agenti che spediscono la propria UI attraverso il protocollo, resa indifferentemente in ChatGPT, VS Code, Cursor o Claude. Costruisci una volta, funziona ovunque.
- SDK v2 in TypeScript e Python, entrambi in riscrittura. Il secondo sulle lezioni apprese con FastMCP della community.
Le principali milestone della roadmap MCP annunciate da Anthropic per il 2026.
Le alternative a MCP nel 2026 e quando sceglierle
MCP non è l’unica strada. Chi costruisce agenti nel 2026 dovrebbe conoscere almeno queste opzioni:
- Function calling diretto con JSON schema: la scelta più semplice. Se hai poche API e nessuna esigenza di discovery dinamica, serve meno infrastruttura e meno superfici di attacco.
- Universal Tool Calling Protocol (UTCP): standard aperto che descrive come chiamare tool esistenti invece di proxare le chiamate attraverso un nuovo server.
- LangChain e LangGraph: quando serve orchestrazione multi-step, memoria strutturata e workflow agentici pronti all’uso.
- Microsoft Semantic Kernel: SDK .NET e Python con gestione programmatica della memoria, adatto a stack Microsoft-first.
- Agent Client Protocol, Composio: piattaforme enterprise con gestione integrata della connettività, model-agnostic per costruzione.
La regola operativa: MCP quando servono semantica ricca, UI, autorizzazione e indipendenza dal modello. Function calling diretto quando il perimetro è piccolo e sotto il tuo controllo. Framework come LangGraph quando l’orchestrazione multi-agente è il problema principale, non la connettività in sé.
Il lato non detto: sicurezza MCP e rischi enterprise
Qui arriva la parte che la community celebrativa non ama ricordare. Un assessment di Equixly su implementazioni MCP reali ha trovato numeri che dovrebbero far riflettere chiunque stia per esporre un server MCP a un LLM in produzione:
- 43% delle implementazioni vulnerabili a command injection
- 30% esposte a server-side request forgery (SSRF)
- 22% con accesso arbitrario ai file
Quando metti un server MCP tra un modello e un sistema aziendale, apri una superficie d’attacco nuova. Le REST API sappiamo come proteggerle da vent’anni, i server MCP molto meno. E il pattern più diffuso oggi, cioè prendere una REST API e convertirla uno a uno in un server MCP, è esattamente il modo sbagliato di farlo. Lo dice, con parole anche più dure, chi quel protocollo lo guida: “è cringe”.
Gli agenti non usano le API come gli umani. Un server MCP ben disegnato espone tool composti, resource, prompt predefiniti, e riflette come un agente userà davvero quel sistema, non come l’ha esposto OpenAPI. Saltare questo passaggio significa costruire una porta sempre aperta.
Per chi sta pianificando una trasformazione AI in azienda, la domanda non è “quanti server MCP apriamo”. È quali processi aziendali vogliamo rendere accessibili ad agenti, con che governance e con che controllo. Chi costruisce agenti AI su misura o percorsi di formazione tecnica ai team lo sa bene: il giusto controllo, non tutto il controllo.
Una domanda aperta per il 2026
Il 2026 promette agenti che coordinano cinque SaaS, tre CLI e due server MCP in un singolo task, e lo fanno con meno token e più eleganza di quanto facciamo oggi. È un salto di capacità reale, visibile, misurabile.
Resta una domanda aperta, ed è quella che tiene sveglio chi l’AI la mette in produzione davvero. Quante aziende hanno il controllo operativo, la governance dei permessi e l’osservabilità per accorgersi se uno di quegli agenti, in un task composito, sta facendo qualcosa che non dovrebbe? Il protocollo più bello del mondo non risponde a questa domanda. La risposta la diamo noi, un’implementazione alla volta.