La nuova roadmap di MCP: cosa significa per chi ci costruisce sopra

Il 22 agosto i maintainer del Model Context Protocol hanno pubblicato una roadmap aggiornata che copre i prossimi sei-dodici mesi di lavoro sul protocollo. Indica cinque aree prioritarie, i Core Maintainers responsabili di ciascuna e una regola silenziosa ma importante su quali proposal vengono reviewate per prime. La roadmap precedente, di marzo, prometteva quattro cose e ne ha consegnate quasi tutte nella release di specifica di luglio, quindi questa si è guadagnata il diritto di essere presa sul serio. La mia lettura: MCP sta deliberatamente diventando normale infrastruttura web, e la domanda utile per chi costruisce è quale parte dello stack cambierà per prima.

Punti chiave - La roadmap stabilisce cinque priorità: agentic messaging, un unico transport HTTP-native, agent identity e enterprise security, primitive tool più pulite e SDK generati dalla specifica. - Le Spec Enhancement Proposal, SEP, dentro queste aree ottengono review accelerata. Fuori da esse, aspettatevi una coda più lunga e una soglia più alta. - Le promesse della roadmap di marzo sono arrivate in gran parte nella specifica 2026-07-28: core stateless, risultati di lista cacheable e Multi Round-Trip Requests. - I due cambiamenti che probabilmente toccheranno di più il vostro codice sono agent identity, DPoP e Workload Identity Federation, e progressive tool discovery per cataloghi grandi. - Trattate la roadmap come direzione, non come commitment. Lo dicono gli stessi maintainer. Non fermate un build per aspettarla.

Cosa hanno annunciato davvero i maintainer di MCP?

Prima i fatti. La roadmap MCP aggiornata, datata 22 agosto 2026, organizza il prossimo ciclo della spec attorno a cinque aree prioritarie, ciascuna con Core Maintainers nominati e uno o più Working Group dietro:

1. Agentic messaging primitives: eventi iniziati dal server, channels, subscriptions e webhooks, così i client smettono di fare polling, più una composition review per far condividere a Tasks, trigger e progress notification uno stesso lifecycle.

2. HTTP-native transport unification and hardening: Streamable HTTP come unico binding, in seguito parlato anche sopra stdio per i server locali, e caching esteso agli ETag.

3. Agent identity and enterprise-ready security: finalizzare DPoP, Demonstrating Proof of Possession, e definire un percorso opinionated per agent identity e delegation basato sugli standard IETF esistenti.

4. Improved primitives: redesign della shape dei risultati di tools/call, più un nuovo sforzo di progressive discovery per far conoscere ai client il catalogo del server solo quando serve.

5. Improved SDK developer experience: un extension contract e un esperimento per generare direttamente dalla specifica un SDK Tier 1 e i relativi quickstart.

Accanto alle cinque aree c'è una regola che modellerà tutto il resto: le SEP dentro le priorità ottengono review accelerata e le proposal con un Working Group dietro si muovono più velocemente. Nelle parole dei maintainer, "maintainer review time is scarce. We spend it here first." La roadmap dice inoltre chiaramente che riflette il pensiero attuale, non commitment fermi, quindi singoli elementi possono slittare o arrivare in una forma diversa.

La roadmap MCP pubblicata il 22 agosto 2026 stabilisce cinque aree prioritarie per i prossimi sei-dodici mesi: agentic messaging, transport HTTP-native, agent identity, primitive tool migliorate e SDK generati dalla spec. Le proposal dentro queste aree ricevono review accelerata; quelle fuori affrontano una coda più lunga.

Perché questa roadmap conta?

Conta perché la precedente ha consegnato. Le roadmap dei giovani progetti open-source spesso sono documenti aspirazionali che invecchiano in silenzio. Questa ha un track record. La roadmap di marzo 2026 aveva quattro priorità, e la maggior parte è arrivata cinque mesi dopo nella release della specifica 2026-07-28:

L'adozione dà peso alla roadmap. A luglio 2026 gli SDK Tier 1 del protocollo vedevano quasi mezzo miliardo di download al mese, con gli SDK TypeScript e Python ciascuno oltre un miliardo di download complessivi. Quando un protocollo di quella scala dice dove sta andando, vale la pena leggere la mappa.

Fonte: roadmap MCP di marzo e agosto 2026 e annuncio della specifica 2026-07-28.

La roadmap MCP di marzo 2026 prometteva transport evolution, agent communication, governance maturation ed enterprise readiness. Cinque mesi dopo, la specifica 2026-07-28 ha consegnato un core di protocollo stateless, l'extension Tasks, Multi Round-Trip Requests e una deprecation policy formale con finestra minima di dodici mesi.

Cosa significa se costruite su MCP?

Per chi costruisce, l'impatto immediato è disomogeneo. Due delle cinque aree cambieranno probabilmente il vostro codice entro un anno. Le altre tre cambiano soprattutto il modo in cui il protocollo viene governato e mantenuto attorno a voi. Ecco ogni area tradotta.

Agentic messaging: la fine del polling

Il vero lavoro degli agenti non entra bene in request e response. I job durano minuti, i server finiscono mentre il client non sta guardando e oggi l'unica risposta del client è fare polling, costoso e brutto. La roadmap dà priorità agli eventi iniziati dal server: channels, subscriptions e webhooks, così un server può dire al client quando il lavoro è finito. La composition review conta altrettanto. Tasks, subscriptions/listen e progress notification rischiano di diventare tre risposte diverse a "il server non ha ancora finito", mentre i maintainer vogliono un lifecycle, un cancellation model e una error surface condivisi. Se costruite tool long-running, questa è l'area da seguire su Discord.

Un transport, parlato ovunque

La release 2026-07-28 ha reso un server MCP remoto un normale workload HTTP. La roadmap ora vuole cancellare la divisione tra remote e local: Streamable HTTP come unico binding, parlato su stdin e stdout per i server locali, con HTTP/2 che offre multiplexing mentre il subprocess mantiene le proprie garanzie di security e lifecycle. Oggi ogni feature HTTP-native ha bisogno di un secondo design specifico stdio oppure non funziona localmente, e gli SDK mantengono due transport pipeline. Un unico transport model significa meno di questo. Anche il caching si estende: ETag sopra gli hint ttlMs e cacheScope arrivati a luglio, così i risultati delle tool call possono essere versionati invece di essere recuperati di nuovo.

Agent identity: quello che morderà prima

L'authorization MCP assume una persona con un browser al momento del consent. Sempre più spesso il caller è un agent: un cloud workload con identity propria, che agisce per un user non presente, oppure crea sub-agent che dovrebbero ricevere authority più stretta del parent. Honeycomb, citata nell'annuncio della release di luglio, attribuisce già quasi il 20% delle query interattive mensili agli agenti. Nel frattempo molti server MCP di produzione si appoggiano ancora ad API key incollate e refresh token long-lived, esattamente la pratica che questo lavoro vuole ritirare. Il piano è finalizzare e adottare DPoP, più un percorso standard di delegation tramite Workload Identity Federation, SEP-1933, il grant ID-JAG dietro Enterprise-Managed Authorization e RFC 8693 token exchange, coordinati con i Working Group OAuth e WIMSE dell'IETF.

Il modello di authorization di MCP è stato creato per un essere umano che approva access nel browser, ma gli agents stanno diventando i caller. La roadmap dà priorità a DPoP e a un percorso standard di delegation basato su Workload Identity Federation e RFC 8693 token exchange, così i server possono riconoscere agent identity senza API key incollate o token long-lived.

Risultati dei tool e progressive discovery

Qui vengono risolte due confusioni. La prima è tools/call che restituisce contemporaneamente content e structuredContent, producendo implementazioni divergenti perché un server author non può sapere quale forma il client mostrerà al model. Quel contract verrà redesigned. La seconda è la scala: collegatevi a un server con cento tool e il model paga per tutta la surface prima che l'utente abbia fatto una sola domanda, e la tool selection peggiora man mano che la lista cresce. La token bill non è teorica. Nel test Cloudflare di febbraio 2026, esporre un'API con 2.500 endpoint come definizioni di tool MCP ha consumato circa 1,17 milioni di token, contro circa 1.000 attraverso code-calling. Progressive discovery è la risposta proposta: un piccolo entry point che rivela altro catalogo man mano che la conversazione si restringe, collegato al lavoro sul caching. Ho scritto su quando quell'overhead rende una semplice API la scelta migliore; progressive discovery è il tentativo di MCP di ridurre il gap.

SDK generati dalla spec

L'item più silenzioso può essere il più indicativo. Oggi SDK, reference server e quickstart vengono mantenuti a mano. La roadmap lancia un esperimento: generare direttamente dalla specifica un candidate SDK Tier 1 e i quickstart associati, validarli contro una conformance test suite e pubblicare i risultati, incluso quali layer dovrebbero essere deterministic codegen e quali model-assisted. Se funziona, i bug di chiarezza della spec emergono come generation failure e gli SDK smettono di divergere dal documento che dovrebbero implementare.

Cosa dovreste fare adesso?

Quattro cose, in ordine di urgenza:

1. Questa settimana: smettete di costruire nuovo lavoro sulle surface deprecated. Roots, Sampling, Logging e il transport legacy HTTP+SSE sono stati deprecated nella spec 2026-07-28 con finestra minima di dodici mesi. Funzionano ancora. Le nuove implementazioni non dovrebbero adottarli.

2. Questo mese: rendete il server cache-friendly. I list result portano già ttlMs e cacheScope, e gli ETag stanno arrivando. Un server che emette oggi cache hint sensati è una migration avanti.

3. Questo trimestre: fate audit di come si autenticano i vostri agents. Se un server MCP che gestite si fida di una API key incollata o di un refresh token long-lived per un caller unattended, è esattamente il pattern che l'Agent Identity Working Group esiste per sostituire. Seguite il gruppo invece di inventare un delegation scheme. L'angolo governance si collega a ciò che ho trattato in governing AI agents.

4. Se volete influenzare il protocollo: scrivete la vostra SEP dentro un'area prioritaria. Portatela prima al Working Group rilevante e ottenete il suo supporto. Le proposal allineate con la roadmap ottengono review accelerata; quelle fuori aspettano.

Due cose da non fare. Non mettete in pausa un build aspettando la prossima spec: quella attuale è la base stabile e la deprecation policy garantisce ora un avviso di dodici mesi su tutto ciò che scompare. E non trattate la roadmap come promessa. La prima sezione dice che le priorità possono cambiare e lavoro non elencato può comunque essere pubblicato. Se siete più indietro nel percorso, il mio walkthrough pratico per un primo server MCP e la shortlist di server che vale la pena collegare sono i punti di partenza pratici.

La specifica MCP 2026-07-28 ha deprecated Roots, Sampling, Logging e il transport legacy HTTP+SSE con finestra minima di dodici mesi. L'annuncio della release conferma che continuano a funzionare durante quel periodo, ma le nuove implementazioni non dovrebbero adottarli.

Il quadro più ampio

Fate un passo indietro e il pattern è un protocollo che cresce in pubblico. MCP è stato donato alla Agentic AI Foundation vendor-neutral sotto la Linux Foundation nel dicembre 2025, con OpenAI e Block come co-fondatori. Da allora ha ottenuto contributor ladder, feature lifecycle, deprecation policy e ora una dichiarazione pubblica su dove va l'attenzione dei maintainer. L'extensions framework fa lavoro silenzioso ma reale: SEP-2133 permette a ogni Working Group di sperimentare in un repository experimental-ext- prima di una proposta formale, così le idee vengono testate senza destabilizzare il core.

Quello che osserverei nei prossimi due trimestri è se arriva HTTP over stdio. Se server locali e remote convergono davvero su un unico transport, "MCP server" smette di essere un tipo speciale di software e diventa un web service con una faccia standard. È il punto in cui il protocollo scompare nelle tubature, che è ciò che dovrebbe fare una buona infrastruttura.

Domande frequenti

MCP è abbastanza stabile da costruirci sopra ora?

Sì, con disciplina di migrazione. La spec 2026-07-28 ha introdotto una deprecation policy formale con finestra minima di dodici mesi, e gli SDK pubblicano migration note per breaking change. Il protocollo continuerà a muoversi, ma ora vi avvisa un anno prima quando qualcosa da cui dipendete scomparirà.

Cosa è successo alle sessioni MCP?

Sono state retired nella specifica 2026-07-28. L'handshake initialize e l'header Mcp-Session-Id non ci sono più, SEP-2575 e SEP-2567. Ogni request è ora self-describing e porta protocol version e client capabilities in _meta, mentre una call opzionale server/discover sostituisce l'handshake per i client che vogliono capabilities upfront. Ogni request può arrivare su qualsiasi instance dietro un load balancer round-robin.

Dovrei aspettare la prossima spec prima di costruire?

No. La roadmap descrive direzione per i prossimi sei-dodici mesi, non feature committed, e i maintainer lo dicono esplicitamente. La spec attuale è stabile, cacheable e stateless. Costruiteci sopra, evitate le surface deprecated e seguite i due Working Group il cui output vi toccherà di più.