MCP C#-SDK 2.0: tilstandsløs som standard og ti bruddendringer

Ti bruddendringer står i utgivelsesnotatet for MCP C#-SDK 2.0, som Microsoft ga ut 28. juli. Samme dato bærer MCP-revisjonen SDK-en nå er i stabil overensstemmelse med, og omleggingen forklarer lista.

Den første endringen treffer flest. «HttpServerTransportOptions.Stateless» har byttet standardverdi til «true». En tilstandsløs server oppretter ingen transportsesjon, eksponerer verken GET- eller DELETE-endepunktet for SSE, og kan ikke sende uoppfordrede forespørsler tilbake til klienten. Har serveren din en bakgrunnsjobb som varsler klienten, forsvinner den stille ved oppgradering om du ikke setter «Stateless = false» selv. Da kompilerer koden med varselet MCP9006, og innstillingen gjelder bare mot klienter som forhandler seg ned.

Forhandlingen har snudd retning: klienter spør «server/discover» først og faller tilbake til det gamle «initialize»-håndtrykket mot eldre servere. Vercel gjorde samme grep for mcp.vercel.com i forrige uke, så det å servere begge protokollene fra ett endepunkt er i ferd med å bli normen.

Tre kjente API-flater er på vei ut. Roots, Sampling og Logging utløser nå varselet MCP9005 fordi 2026-07-28-spesifikasjonen avvikler dem. Nedforhandlede forbindelser kan fortsatt bruke dem, men Microsoft ber deg planlegge migrering framfor å undertrykke varselet permanent. Tasks er flyttet til pakken «ModelContextProtocol.Extensions.Tasks» uten API- eller wire-kompatibilitet med den eksperimentelle utgaven fra 1.4.x.

Nytt er flerrundeforespørsler, som lar et verktøy be brukeren bekrefte en handling uten levende sesjon fordi kontinuiteten reiser i nyttelasten. OAuth er strammet inn i samme slengen: utsteder-avvik avvises etter RFC 9207 og RFC 8414, og autorisasjonsserveren må annonsere PKCE med S256.

Hva bør du gjøre?

1. Avklar om serveren din trenger sesjoner før du oppgraderer. Gjør den det, sett «Stateless = false» i samme commit som pakkeoppdateringen.
2. Søk opp Roots, Sampling og Logging i kodebasen. Varslene MCP9005 og MCP9006 peker deg rett på migreringsjobben.
3. Kontroller at autorisasjonsserveren annonserer «S256» i «code_challenge_methods_supported». Mangler feltet, feiler OAuth-flyten etter oppgraderingen.