MCP er nå stateless for alvor: Cloudflare skroter McpAgent og kjører servere i en vanlig Worker

Cloudflare skriver i et blogginnlegg 6. august at spesifikasjonen ble sluppet uken før, sammen med oppdaterte SDK-er for TypeScript, Python, Go og C#. På modelcontextprotocol.io står 2026-07-28 nå oppført som «latest», og oppsummeringen av basisprotokollen beskriver den som statsløse, selvstendige forespørsler med capability-forhandling per kall. Release candidate-en er ferdig.

Det praktiske utslaget hos Cloudflare er at McpAgent-primitivet ikke lenger er nødvendig. Den gamle transporten krevde et initialize-håndtrykk, en Mcp-Session-Id-header og en serverinstans som husket økten, noe som tvang fram sticky routing og Durable Objects. Nå bærer hver forespørsel protokollversjon, klientidentitet og capabilities selv. Vil klienten inspisere serveren før den gjør noe mer, kan den kalle server/discover, men det er valgfritt.

Elicitation, der serveren må spørre brukeren om noe midt i en operasjon, var det som bandt hardest til en åpen strøm. Den er skrevet om til Multi Round-Trip Requests: serveren returnerer et input_required-resultat som beskriver hva den mangler, klienten henter svaret og prøver operasjonen på nytt med det. Cloudflare kaller det en breaking change, men mener det er langt enklere å drifte.

For alle som legger en gateway foran agentene sine, er den nye header-plikten kanskje viktigst. Streamable HTTP-forespørsler må nå ha Mcp-Method og Mcp-Name, så en brannmur eller rate limiter kan skille et tools/call fra et resources/read uten å parse JSON-kroppen. Listekall får i tillegg ttlMs- og cacheScope-hint, og verktøykataloger er deterministisk sortert slik at prompt-cachen holder seg stabil på tvers av reconnects.

«Vi gikk live med denne nye før 7-28-spesifikasjonen i det hele tatt var ferdig, og den knakk ikke prod.» — David Cramer, medgrunnlegger og produktdirektør i Sentry

Autorisasjonen er strammet inn samtidig. MCP foretrekker nå forhåndsregistrerte klienter, deretter Client ID Metadata Documents, med Dynamic Client Registration som siste utvei. DCR er avviklet for nye implementasjoner og skal etter planen fjernes etter sommeren 2027. Spesifikasjonen adopterer også RFC 9207, der autorisasjonsserveren sender med iss i svaret slik at klienten kan sjekke at svaret kom fra utstederen den faktisk startet flyten mot.

«Dette er det mest betydelige framskrittet i protokollen siden lansering.» — David Soria Parra, medskaper og hovedvedlikeholder av MCP, Anthropic

Utgivelsen innfører dessuten en formell livssyklus for funksjoner, med statusene Active, Deprecated og Removed. Noe som er avviklet må være tilgjengelig i minst tolv måneder før det kan fjernes. Roots, Sampling, Logging, Dynamic Client Registration og den gamle HTTP+SSE-transporten er avviklet i denne runden. Nye ideer skal i stedet gå gjennom et utvidelsesrammeverk, der MCP Apps, Enterprise-Managed Authorization og Tasks allerede ligger.

Hva bør du gjøre?

1. Sjekk om serveren din faktisk trenger tilstand. Bruker den bare tools, prompts og resources, kan den flyttes til ren forespørselsbasert kjøring uten Durable Object.
2. Finn elicitation-kallene dine først. MRTR er en breaking change, så de må skrives om selv om resten av serveren klarer seg med en SDK-oppgradering.
3. Sett en frist for DCR selv. Tolv måneders avviklingsvindu høres romslig ut, men CIMD krever at du legger ut et metadata-dokument klienten kan hentes fra.