Ready for `ModelContextProtocol` v2.0

[carldebilly]

The package ModelContextProtocol will soon be published its version 2.0 and we should be ready for it.

This should act as the tracking epic for the MCP C# SDK 2.0 migration/readiness work.

Current Repl state:

• Repl currently pins ModelContextProtocol to 1.2.0.
• ModelContextProtocol / ModelContextProtocol.AspNetCore / ModelContextProtocol.Extensions.Apps already have 2.0.0-preview.1 packages published.
• Repl.Mcp already exposes tools/resources/prompts/logging and MCP Apps capability when enabled.
• .LongRunning() commands are already mapped to MCP tool execution metadata with ToolExecution.TaskSupport = Optional.
• Repl does not yet implement the full MCP Tasks lifecycle: no TaskStore, no tasks/get, tasks/update, tasks/cancel, and no CreateTaskResult runtime path.

Suggested scope:

• Spike build/test compatibility with ModelContextProtocol 2.0.0-preview.1.
• Audit API breaks around McpServerOptions, McpServerHandlers, ServerCapabilities.Extensions, RequestContext<T>, progress, elicitation, sampling, roots, and MCP Apps.
• Verify SDK 2.0 client behavior around server/discover and fallback to legacy initialize.
• Decide whether full MCP Tasks runtime support belongs in the SDK 2.0 migration or as a follow-up.
• Add/track a dedicated issue for MCP Tasks runtime support for .LongRunning() commands.
• Document supported MCP protocol versions and host compatibility.
• Add regression tests for MCP server capabilities and tool calls under the chosen SDK version.

Non-goals for Repl 0.11:

• Do not include the MCP Streamable HTTP PR Add MCP Streamable HTTP hosting #27 unless explicitly re-scoped.
• Do not advertise full Tasks support until polling/cancel/update works end-to-end.

[autocarl]

I checked current origin/main (682b5af) against ModelContextProtocol 2.0.0-preview.2 with a transient package bump and ran dotnet test Repl.slnx -c Release. It currently fails while compiling Repl.Mcp.

Concrete migration items worth making explicit in this epic:

• Tasks advertisement is a real compile break, not only a future runtime feature. Tool.Execution, ToolExecution, and ToolTaskSupport are gone. The new model is the io.modelcontextprotocol/tasks extension with TaskStore/task handlers and CallToolWithTaskHandler returning ResultOrCreatedTask<CallToolResult>. We should either implement that path for .LongRunning() or stop advertising task support until the dedicated Tasks work lands.
• Roots, Sampling, and Logging now produce MCP9005. Because Repl has TreatWarningsAsErrors=true, current uses of LoggingLevel, logging capabilities/notifications, ClientCapabilities.Roots, RequestRootsAsync, ClientCapabilities.Sampling, and SampleAsync all fail the build. We need an explicit compatibility decision: retain the legacy APIs behind narrowly scoped suppressions for old-protocol fallback, migrate modern interactions to MRTR/per-request metadata, or both.
• SEP-2549 cache hints need a server policy. Under the 2026-07-28 protocol, ttlMs and cacheScope are required for tools/list, prompts/list, resources/list, resources/templates/list, and resources/read. Repl currently leaves them unset, so preview.2 clients warn about non-conformance. A safe initial policy would be TimeToLive = TimeSpan.Zero plus CacheScope.Private, then optimize later if useful.
• Add explicit MRTR/stateless coverage. In addition to server/discover and legacy fallback, verify that Repl does not rely on unsolicited server-to-client Roots/Sampling/Elicitation calls in 2026-07-28, and that inputRequests / inputResponses / requestState round-trip through the chosen path.
• Make the MCP Apps audit wire-specific. Repl currently has its own metadata model. The official ModelContextProtocol.Extensions.Apps preview uses permissions: { "allow": [...] } where Repl emits individual permission objects, and csp.baseUris where Repl emits csp.baseUriDomains. We should decide whether to adopt the official package/types or at least align and regression-test the emitted wire shape.

Preview.2-specific triage:

• The source-generation fix for ServerCapabilities.Extensions, ClientCapabilities.Extensions, InputResponses, and RequestState is useful; add a consumer-context round-trip test if those objects pass through Repl own McpJsonContext.
• DeferChangedEvents() does not look like a required Repl change today: the dynamic path already debounces and sends one set of list-change notifications, while static collections are populated before the server is attached.
• The Streamable HTTP request-id fix belongs with Add MCP Streamable HTTP hosting #27, which is already a non-goal here.

So the issue already has the right high-level scope, but the compile spike reveals enough concrete blockers that I would track the items above explicitly.

[carldebilly]

Spike done — findings and first migration landed as PR #71 (2.0.0-preview.3):

• Spike build/test compatibility with the 2.0 line: green (1312/1313, known skip).
• Audit API breaks: the only hard break for Repl is the removal of the experimental Tasks tool augmentation (Tool.Execution/ToolTaskSupport). McpServerOptions, handlers, ServerCapabilities.Extensions, RequestContext<T>, progress, elicitation, sampling, roots, and MCP Apps are source-compatible modulo SEP-2577 obsoletions (Roots/Sampling/Logging deprecated, no replacement — kept supported with documented scoped pragmas).
• SDK 2.0 client handshake verified through the McpTests suite (SDK client end-to-end).
• Decision: MCP Tasks runtime support stays OUT of the 2.0 migration — the SDK previews removed the surface entirely, so there is nothing to build against yet. .LongRunning() stays in Repl's model; no protocol-level task advertisement until the SDK ships the Tasks runtime.
• Documented supported SDK/protocol version posture in docs/mcp-reference.md (PR feat(mcp): migrate to ModelContextProtocol 2.0 line (2.0.0-preview.3) #71).
• Regression tests: existing McpTests suite exercises capabilities and tool calls under the new SDK.

Remaining under this epic:

• Dedicated issue + implementation for the MCP Tasks runtime (TaskStore, tasks/get|update|cancel, CreateTaskResult) once the SDK re-ships the surface.
• Re-pin ModelContextProtocol to the stable 2.0.0 before cutting stable 0.12 (noted in PR feat(mcp): migrate to ModelContextProtocol 2.0 line (2.0.0-preview.3) #71).

[carldebilly]

Dedicated MCP Tasks runtime issue opened as announced: see the newly filed issue referencing ModelContextProtocol.Extensions.Tasks (the SDK 2.0 home of the Tasks surface — extracted, not removed; corrected in PR #71's review pass).