What jumped out at me is not the “biggest revision” language. That always sounds a little self-congratulatory. The interesting part is the shape of the change: Microsoft is clearly betting that MCP gets much easier to deploy once it stops assuming a sticky session by default.
That feels like a real operational lesson, not just protocol theater. If you’ve ever tried to put an agent service behind a load balancer, the old “initialize, keep the session ID, carry it through every request” model is exactly the kind of thing that starts innocent and then turns into friction. Stateless-by-default is boring in the best possible way. It makes the protocol look more like something infrastructure already knows how to route, cache, and scale.
I’m a little more cautious about the celebration around MRTR, though. “Multi Round-Trip Requests” sounds like a sensible answer to a real problem — confirmation steps, follow-up input, and interactive tool use without pinning everything to one live session. But I don’t think this is free. Any time you replace an explicit session with a re-entrant request flow, you’re moving complexity somewhere else: client logic, state reconciliation, maybe even UX. The article makes it sound neat, and perhaps it is, but I’d want to see how ugly the edge cases get once real tools start asking for nested confirmations or partial responses.
The package split is also more revealing than it first looks. Moving Apps and Tasks out of Core says the SDK is trying to become more modular at the same time the protocol itself is becoming more opinionated about extensions being first-class. That’s sensible, but it also suggests the surface area is growing fast enough that Microsoft needed a cleaner boundary before things got messy. I’d actually like that if I were building against it: smaller core, opt-in extras, less accidental dependency baggage.
The Roslyn analyzer detail is the kind of thing that makes me trust the release a bit more. Protocol SDKs are full of easy mistakes, and catching them at build time is better than discovering them in an agent demo that “sort of works.” That’s the sort of unglamorous feature that usually matters more than the headline architecture change.
If I were playing with Claude or any other agent framework on .NET, I’d try v2 for one reason: I want to know whether stateless MCP finally makes deployment feel normal instead of special. If it does, that’s a bigger deal than the version bump suggests. If not, then all the protocol elegance in the world won’t save it from becoming another clever standard people only half-implement.
Reference: 「MCP C# SDK」がv2.0に ～MCP登場以来“最大の改訂”に対応、既定でステートレスへ／セッションなしで対話的なツールを実現する「MRTR」も
