Anthropic ha appena pubblicato la nuova roadmap del Model Context Protocol. E no, non è l’ennesimo documento di facciata per far contenti gli investitori — è un piano preciso che dice dove andrà il protocollo nei prossimi mesi.
La roadmap è stata costruita dai Core Maintainers insieme alla community e ai Working Groups. Cinque aree prioritarie, ognuna con un team dedicato. Alcune riprendono spunti dalla roadmap precedente (eventi server-side, miglioramenti ai tipi di risultato, identità degli agenti) che ora sono maturi abbastanza da meritarsi un posto in prima fila.
Primitive per agenti che non stanno mai fermi
Il vecchio schema richiesta-risposta non basta più. Gli agenti moderni girano loop lunghi, i server mandano risultati in streaming, e serve un modo per correggere il tiro mentre il lavoro è ancora in corso. MCP ha già introdotto Task, subscriptions/listen e progress notifications — ora tocca assicurarsi che funzionino bene insieme.
Il piano prevede eventi iniziati dal server (webhook e canali, così i client non devono fare polling a nastro), una revisione della composizione tra i Working Groups Agents, Transports e Triggers & Events, e la maturazione dell’estensione Tasks (SEP-2663) fino a farla entrare nella specifica ufficiale.
HTTP dappertutto, una volta per tutte
Con il rilascio 2026-07-28, un server MCP remoto è diventato un normalissimo carico HTTP. Il che significa: puoi hostarlo ovunque già giri la tua infrastruttura API, senza inventarti niente di nuovo.
Il modello scala. E adesso vogliono estenderlo anche ad altri scenari di deployment, compresi i server locali che parlano Streamable HTTP su stdio. Unificare tutto su un solo transport significa semplificare lo sviluppo di server e client MCP ancora di più. Meno pezzi, meno casino.
Identità degli agenti e sicurezza enterprise
Oggi l’autorizzazione MCP funziona così: una persona approva l’accesso dal browser. Perfetto per client interattivi. Meno perfetto quando chi chiama è un agente cloud con una propria identità, che agisce per conto di un utente assente o delega autorità ristrette a sotto-agenti.
L’obiettivo è dare ai server MCP un modo standardizzato per riconoscere e fidarsi di quelle identità. Niente API key incollate o token eterni — roba seria basata su standard esistenti.
In pratica: finalizzare Demonstrating Proof of Possession (DPoP) e spingerne l’adozione, definire un percorso chiaro per identità e delega degli agenti attraverso Workload Identity Federation, il grant ID-JAG dietro Enterprise-Managed Authorization, e token exchange standard. E continuare a lavorare con i gruppi OAuth IETF e WIMSE perché gli standard evolvano con i mattoni che servono davvero all’identità degli agenti.
Migliorare le primitive (partendo dai tool)
Il tool calling è la parte di MCP che quasi tutti toccano per prima. Ha retto bene finora. Dove scricchiola è nella gestione dei risultati.
Una risposta tools/call può portare lo stesso output in più forme, e oggi uno sviluppatore server non ha modo di sapere quale forma un dato client metterà davanti al modello. Vogliono standardizzare su un contratto unico e chiaro.
Secondo problema: la scala. Connettersi a un server con cento tool significa far pagare al modello l’intera superficie prima ancora che l’utente faccia una domanda. E la selezione dei tool tende a peggiorare quando la lista si allunga. La soluzione? Progressive discovery: il server offre un entry point piccolo e svela il resto del catalogo man mano che la conversazione si restringe.
SDK più intuitive (soprattutto per gli agenti che le usano)
Gli SDK sono il modo in cui gli sviluppatori vivono MCP. Anthropic sta investendo sull’ergonomia, sulla conformità con la specifica, e sul renderle intuitive e ben documentate su ogni piattaforma e linguaggio.
Questo conta ancora di più ora che molti sviluppatori costruiscono client e server MCP puntando un agente alle librerie. API chiare e doc accurate fanno la differenza tra codice che funziona subito e ore passate a debuggare.
Come partecipare
Ogni area prioritaria ha un Working Group dietro (o in formazione), e tutti hanno spazio per nuovi contributor. Puoi unirti a un Working Group o Interest Group, proporre o commentare una SEP (Specification Enhancement Proposal), avviare un’estensione sperimentale (SEP-2133 lo permette), o contribuire direttamente a specifica, SDK e tooling.
Le SEP che rientrano nelle aree prioritarie ottengono review accelerata e maggiori chance di accettazione. Quelle fuori non vengono rifiutate automaticamente, ma il tempo dei maintainer è limitato — e va prima alla roadmap. Tradotto: se hai un’idea, parlane col Working Group di riferimento prima di buttare giù codice a caso.
