deps: Bump ModelContextProtocol and ModelContextProtocol.AspNetCore - #422
Conversation
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
erikdarlingdata
left a comment
erikdarlingdata
left a comment
There was a problem hiding this comment.
Summary
Dependabot bump of ModelContextProtocol and ModelContextProtocol.AspNetCore from 1.4.1 → 2.0.0 in src/PlanViewer.App/PlanViewer.App.csproj. Two-line diff, no C# source changes.
Good
- Base branch is
dev— correct target. - Both MCP packages moved in lockstep to the same version; no split-version risk.
- No Avalonia, XAML, brush, PlanAnalyzer, or thread-safety surface touched — the project-specific gotchas don't apply here.
Needs attention
- This is a major version bump with breaking changes per the 2.0.0 release notes. Most importantly,
HttpServerTransportOptions.Statelessdefaults totrue, which flips runtime behavior forMcpHostService.cs:80(see inline). Confirm existing LLM clients still work against a stateless server, or setStateless = falseexplicitly. - CI:
check-branchespassed,build-and-testwas still running at review time, andreviewreported failure at 10:15:18Z (11s after start — likely infrastructure, but worth confirming it isn't the actual compile against 2.0.0). - No test change here (dependency bump, so N/A), but a quick manual
MapMcpsmoke against an MCP client would de-risk the transport default flip before merge.
Comments only — leaving the merge decision to the maintainer.
Generated by Claude Code
| <PackageReference Include="ModelContextProtocol" Version="2.0.0" /> | ||
| <PackageReference Include="ModelContextProtocol.AspNetCore" Version="2.0.0" /> |
There was a problem hiding this comment.
Major version bump (1.4.1 → 2.0.0) with documented behavior changes that hit this app. Worth verifying before merge:
HttpServerTransportOptions.Statelessnow defaults totrue.McpHostService.cs:80calls.WithHttpTransport()with no options, so on upgrade the server flips from stateful to stateless: no transport sessions, no standalone SSEGET/DELETEendpoints, and no unsolicited server-to-client requests. The current tool set (McpPlanTools,McpQueryStoreTools) all look request/response, so this is probably fine — but any client that expected a persistent session againstMapMcp()will now behave differently. If any consumer relied on session state, passoptions => options.Stateless = falseexplicitly.- Discovery-first negotiation is new (
server/discoverbefore the legacyinitializehandshake). Down-level clients still work, but the wire behavior changes. Roots/Sampling/LoggingAPIs are deprecated (MCP9005). Grep shows this codebase doesn't use them, so no source impact.- Expect possible
MCP9006warnings for stateful-only options if any surface here.
Also flagging: build-and-test was still in progress at review time — the compile against 2.0.0 is the real signal for whether any API broke. The review check has already reported failure; worth confirming that's not the actual compile.
Generated by Claude Code
erikdarlingdata
left a comment
erikdarlingdata
left a comment
There was a problem hiding this comment.
Automated review — comments only, not an approval or a change request.
What this PR does: Dependabot bump of ModelContextProtocol and ModelContextProtocol.AspNetCore from 1.4.1 → 2.0.0 in src/PlanViewer.App/PlanViewer.App.csproj. Two lines, one file.
Good:
- Targets
dev(correct —mainwould be flagged). - CLI's own MCP surface (
Repl.Mcp) isn't touched by this bump; scope is contained tosrc/PlanViewer.App/Mcp/.
Needs attention:
- Major-version SDK bump — not a routine patch. Upstream 2.0.0 aligns to the MCP
2026-07-28spec and defaultsHttpServerTransportOptions.Stateless = true.McpHostService.cs:80calls.WithHttpTransport()with no options, so the server silently switches to stateless behavior on merge. Inline comment on the version lines has the concrete change list and repro checklist. MCP9005warnings.McpSmokeTests.csuses the now-deprecated Roots client capability. Warnings-as-errors builds will break; otherwise they'll just noise the log.- CI status:
build-and-testis still in progress,reviewjob already failed at 10:15Z,check-branchespassed. Wait for the full build before merging. - No test coverage change to match the SDK jump. For a major SDK bump, a targeted smoke test against a real 2.0 client (or at least verifying the existing
McpSmokeTestspass end-to-end) is the minimum bar before shipping.
Not touching PlanAnalyzer rules or scoring, so no PerformanceMonitor / Lite / Dashboard sync flag on this one.
Generated by Claude Code
| <PackageReference Include="ModelContextProtocol" Version="2.0.0" /> | ||
| <PackageReference Include="ModelContextProtocol.AspNetCore" Version="2.0.0" /> |
There was a problem hiding this comment.
1.4.1 → 2.0.0 is a major bump with behavioral breaking changes that affect this project — the diff compiles, but runtime semantics shift. Specific impact:
HttpServerTransportOptions.Stateless now defaults to true (upstream #1610). src/PlanViewer.App/Mcp/McpHostService.cs:80 calls .WithHttpTransport() with no options, so the MCP server flips from stateful (current) to stateless: no transport sessions, no standalone SSE GET/DELETE, no unsolicited server→client requests. If you want to preserve current behavior, pass o => o.Stateless = false (this then emits MCP9006 warnings — the option is stateful-only and only applies to down-level clients that fall back to the initialize handshake).
Roots/Sampling/Logging APIs are [Obsolete] and emit MCP9005. tests/PlanViewer.Core.Tests/McpSmokeTests.cs:27-37,152-161 sets Capabilities.Roots and Handlers.RootsHandler on the client — those will warn. If the build uses TreatWarningsAsErrors=true, tests stop compiling. If not, they still warn but keep working (the SDK stays down-level-compatible).
Discovery-first negotiation. Clients now POST server/discover before the legacy initialize. The DNS-rebinding guard at McpHostService.cs:91-107 should still fire correctly (it inspects Host/Origin only), but worth a manual smoke test from a real client (Claude Desktop, etc.) — the endpoint shape changes even if the mount point does not.
Non-app impact:
src/PlanViewer.Cli/usesRepl.Mcp0.11.0, not this SDK directly, so the CLI'smcp servepath isn't touched by this PR.- Tool return types are all
stringtoday, so the non-object structured-result change (upstream #1568) and theTool.inputSchemarequired-on-deserialize change (#1600) don't obviously bite, but alist_toolsround-trip against a fresh 2.0 client would confirm.
build-and-test was still running when this review was drafted; the review job already failed at 10:15Z. Confirm CI is green and run a real MCP client against the server before merging — the stateless default is the one to watch.
Generated by Claude Code
|
@dependabot rebase |
|
@dependabot recreate |
Bumps ModelContextProtocol from 1.4.1 to 2.0.0 Bumps ModelContextProtocol.AspNetCore from 1.4.1 to 2.0.0 --- updated-dependencies: - dependency-name: ModelContextProtocol dependency-version: 2.0.0 dependency-type: direct:production update-type: version-update:semver-major - dependency-name: ModelContextProtocol.AspNetCore dependency-version: 2.0.0 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
1c18363 to
8001b90
Compare
…ta#1990) The 1.4.1 -> 2.0.0 major, taken deliberately after a grouped auto-bump demonstrated the failure mode (erikdarlingdata#1822: half-applied across projects, NU1605/NU1004 across every lockfile). The version moves in every referencing project in one commit - Common, Lite, Darling.Service, deprecated/Dashboard - with all six affected lockfiles regenerated together under the CI-pinned SDK (10.0.302; a first pass under 10.0.300 silently downgraded framework packages 10.0.10 -> 10.0.8, so the exact SDK matters for lockfile work). No code changes were needed: - Stateless-by-default HTTP is a no-op here: both hosts have set HttpServerTransportOptions.Stateless = true explicitly since erikdarlingdata#1074 (clients that don't echo Mcp-Session-Id otherwise connect but list zero tools). - Deprecated-API audit (Roots/Sampling/Logging): no usage in either host or the shared tool plumbing (the only greps are ShowPlan SamplingPercent false positives). - McpSchemaCompat (the Gemini schema rewriter) compiles unchanged against 2.0's McpServerTool.Create/McpServerToolCreateOptions. Live-verified against the real Darling service running this branch on the SDK 2.0 packages (local run against a scratch TimescaleDB store): initialize returns the correct envelope with NO session header; tools/list returns all 89 tools with no session round-trip; tools/call executes against the store; and the erikdarlingdata#1648 DNS-rebinding guard still rejects a non-loopback Host with 400 ahead of MapMcp's 2.0 discovery-first endpoint surface (it is pipeline middleware installed before MapMcp, so new endpoints inherit it structurally). The same SDK 2.0 hosting surface was separately validated end-to-end on Performance Studio (erikdarlingdata/PerformanceStudio#422) before this migration. With the major taken, the dependabot ignore rule deferring ModelContextProtocol* majors to erikdarlingdata#1990 is removed (per erikdarlingdata#1991's "remove this once erikdarlingdata#1990 lands"), so SDK patches/minors resume flowing through the weekly group. Closes erikdarlingdata#1990 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
1 participant
Updated ModelContextProtocol from 1.4.1 to 2.0.0.
Release notes
Sourced from ModelContextProtocol's releases.
2.0.0
Version 2.0.0 brings the C# SDK into stable alignment with the MCP 2026-07-28 specification.
This major release introduces discovery-first negotiation, multi-round-trip requests, stateless-by-default HTTP, caching hints, standardized headers, stronger OAuth and token-cache safety, and dedicated MCP Apps and Tasks extension packages, with down-level interoperability for peers negotiating 2025-11-25 and earlier. Review the migration guidance below.
Breaking Changes
Refer to the C# SDK Versioning documentation for details on versioning and breaking-change policies.
HttpServerTransportOptions.Statelessnow defaults totrue. Stateless servers do not create transport sessions, expose the standalone SSEGET/DELETEendpoints, or support unsolicited server-to-client requests.Stateless = falsewhen an existing server requires legacy stateful behavior. Stateful-only options now produceMCP9006warnings and apply only to down-level initialize-handshake connections.server/discoverfirst and automatically fall back to the legacyinitializehandshake for down-level servers.MCP9005warnings because these features are deprecated by the 2026-07-28 specification.MCP9005temporarily if continued use is required while planning migration.ModelContextProtocol.Extensions.Tasks#1693ModelContextProtocol.Extensions.Tasks, import its namespace, register Tasks withWithTasks(...), and replace CoreRequestMethods.Tasks*constants withTasksProtocolmembers.AuthorizationRedirectDelegateandClientOAuthOptions.AuthorizationRedirectDelegatenow produceMCP9007warnings. Migrate toClientOAuthOptions.AuthorizationCallbackHandlerso callbacks can return the authorization code, state, and issuer.UseStructuredContent = trueand a non-object return type now emit the raw value and matching schema, such asstructuredContent: 72, instead of wrapping it as{ "result": 72 }.resultproperty.Tool.inputSchemaduring deserialization #1600Toolpayload withoutinputSchemanow throwsJsonExceptioninstead of silently defaulting the schema.inputSchema; an empty{}is sufficient.S256incode_challenge_methods_supported.application_typeduring dynamic client registration #1613application_type.DynamicClientRegistrationOptions.ApplicationTypeexplicitly when the inferred value is not appropriate.HttpRequestException,TimeoutException, or genuine I/O exception instead of always wrapping failures inIOException.IOException("Failed to connect transport.")wrapper. In AutoDetect mode, inspect the outerHttpRequestExceptionand its inner SSE failure.insufficient_scopechallenge that introduces no new scopes now throwsMcpExceptioninstead of retrying indefinitely.What's Changed
InheritEnvironmentVariablestoStdioClientTransportOptions#1563 by @halter73offline_accessto authorization scope when advertised (SEP-2207) #1479 by @stephentoub (co-authored by @Copilot)McpErrorCode.ResourceNotFoundper SEP-2164 #1558 by @jayaraman-venkatesanMcpClienttool cache #1590 by @tarekghScopeSelectorDelegateto OAuth options #1596 by @halllo... (truncated)
2.0.0-rc.2
This second 2.0 release candidate advances the SDK’s
2026-07-28protocol support, expands Tasks extension conformance tests, strengthens OAuth and transport behavior, and expands 2.0 guidance ahead of general availability.Thank you to the community for using the preview and release-candidate builds and for sharing feedback and issue reports that shape this release!
Breaking Changes
Refer to the C# SDK Versioning documentation for details on versioning and breaking-change policies.
DiscoverResult.ServerInfois removed; read and deserializeMeta[MetaKeys.ServerInfo]instead.2026-07-28, replace legacy initialization, ping, logging, and resource-subscription methods withserver/discover,_metalog level, andsubscriptions/listen.statethroughAuthorizationResult.State, and should returnCode,State, andIss.IOExceptionwrapper.What's Changed
Documentation Updates
Test Improvements
_meta.uiserialization round-trip tests #1698 by @yayayouyouRepository Infrastructure Updates
... (truncated)
2.0.0-rc.1
2.0.0-rc.1 advances the v2 SDK toward general availability with stronger OAuth conformance, improved dynamic client registration, and expanded Tasks validation.
We remain on-track to release 2.0.0 stable on or before 2026-07-28.
We want to give a big thanks to @KubaZ2 for reporting the critical, ship-stopping Tasks/HTTP defect in #1720, fixed by #1722!
Breaking Changes
Refer to the C# SDK Versioning documentation for details on versioning and breaking change policies.
Remove the preview task-scope helper #1722
McpTasksServerExtensions.CreateMcpTaskScope(...)was removed from the stable surface. This affects only applications built against the v2 preview API; no stable 2.0 release has shipped.Harden OAuth issuer validation #1605
AuthorizationRedirectDelegatenow producesMCP9007, which breaks warning-as-error builds; the manual authorization flow now requires the complete redirect URL.AuthorizationCallbackHandlerand returnAuthorizationResult.Require advertised PKCE S256 support #1700
code_challenge_methods_supported: ["S256"]now cause authentication to fail instead of receiving an inferred default.Send Dynamic Client Registration application types #1613
ApplicationTypenow sends an inferredapplication_typeinstead of omitting it.DynamicClientRegistrationOptions.ApplicationTypeexplicitly when the authorization server requires another value.What's Changed
application_typein Dynamic Client Registration requests #1613 by @jayaraman-venkatesan (co-authored by @Copilot)ClientOAuthProvider#1605 by @mikekistler (co-authored by @halter73 @Copilot)Documentation Updates
release/1.x(v1.4.1) andmain(v2 preview) content #1727 by @jeffhandley (co-authored by @Copilot)Test Improvements
... (truncated)
2.0.0-preview.3
This preview reorganizes the Tasks feature into its own
ModelContextProtocol.Extensions.Taskspackage, keepingModelContextProtocol.Corefocused on the base protocol while a new generic request-handler and alternate-result surface lets the Tasks package layer on top. It also delivers correctness fixes to the draft2026-07-28protocol -- per-request client capabilities, negotiation boundaries, and theresultTypediscriminator -- plus Streamable HTTP client improvements (an empty-JSON-response fix and a new standalone GET-stream opt-out) and conformance-test consolidation.Breaking Changes
Refer to the C# SDK Versioning documentation for details on versioning and breaking change policies.
ModelContextProtocol.Extensions.Taskspackage #1693McpTaskStatus,IMcpTaskStore/InMemoryMcpTaskStore, thetasks/*request methods, and the clientGetTaskAsync/UpdateTaskAsync/CancelTaskAsync/CallToolRawAsyncmethods -- is removed fromModelContextProtocol.Coreand relocated to the newModelContextProtocol.Extensions.Taskspackage under theModelContextProtocol.Extensions.Tasksnamespace.ResultOrAlternate<T>(replacingResultOrCreatedTask<T>) plus generic extension points --McpServerRequestHandler,McpServerOptions.RequestHandlers,McpServerHandlers.CallToolWithAlternateHandler,McpRequestFilters.CallToolWithAlternateFilters, andMcpServer.InterceptOutgoingRequests-- that the Tasks package builds on.PackageReferencetoModelContextProtocol.Extensions.Tasks; changeusing ModelContextProtocol.Protocol;tousing ModelContextProtocol.Extensions.Tasks;for task types; the task client/server APIs are now extension methods (McpTasksClientExtensions/McpTasksServerExtensions), and the task store is registered via the new builder extensions instead ofMcpServerOptions.TaskStore.Experimental APIs
To support extracting Tasks (#1693),
ModelContextProtocol.Coregained a generic server-extension surface --ResultOrAlternate<T>,McpServerRequestHandler,McpServerOptions.RequestHandlers,McpServerHandlers.CallToolWithAlternateHandler,McpRequestFilters.CallToolWithAlternateFilters, andMcpServer.InterceptOutgoingRequests-- that lets extension packages such asModelContextProtocol.Extensions.Taskslayer behavior onto the server pipeline. These APIs are annotated[Experimental]under diagnostic IDMCPEXP002.This surface is still being designed: #1704 tracks composing these seams with the normal filter and subscription pipeline (typed custom RPCs, filter composition, and extension-defined subscriptions). Expect these low-level extensibility APIs to change and potentially remain
[Experimental]through the 2.0.0 stable release.What's Changed
ModelContextProtocol.Extensions.Tasksextension package #1693 by @jeffhandley (co-authored by @Copilot)Test Improvements
Acknowledgements
Full Changelog: modelcontextprotocol/csharp-sdk@v2.0.0-preview.2...v2.0.0-preview.3
2.0.0-preview.2
This second preview of the 2.0.0 series advances the SDK's alignment with the upcoming
2026-07-28MCP protocol revision: it adds client-side conformance diagnostics for the SEP-2549 caching hints, makes Streamable HTTP error responses echo the request id per the base protocol and SEP-2243, and fully stabilizes now-stable protocol properties so consumer-defined source generators serialize them correctly. Separately -- and unrelated to the protocol revision -- it introducesDeferChangedEvents()onMcpServerPrimitiveCollection<T>for batchinglist_changednotifications when registering primitives in bulk. There are no breaking changes relative tov2.0.0-preview.1.What's Changed
Documentation Updates
Acknowledgements
Full Changelog: modelcontextprotocol/csharp-sdk@v2.0.0-preview.1...v2.0.0-preview.2
2.0.0-preview.1
This is the first preview of the C# MCP SDK 2.0.0, designed for alignment with the 2026-07-28 MCP specification release. The SDK implements the
2026-07-28protocol version which fundamentally changes how clients and servers interact -- removing theinitializehandshake (SEP-2575), eliminating server-side session state (SEP-2567), introducing Multi Round-Trip Requests (SEP-2322), and deprecating legacy capabilities in favor of the new extensions framework (SEP-2133).The 2.0.0 SDK is fully backward-compatible with servers and clients using the previous
2024-11-05protocol version. Clients automatically negotiate down to the legacyinitializehandshake when connecting to older servers, and servers continue to acceptinitializerequests from older clients. API breaking changes in 2.0.0 are limited to two categories: (1) APIs for capabilities deprecated by the new specification (Roots, Sampling, and Logging), which are now marked[Obsolete]with guidance toward their replacements, and (2) experimental APIs whose contracts changed as the specifications were finalized. Stable, non-deprecated APIs from 1.x continue to work without modification.Protocol Version Negotiation and Handshake Behavior
The 2.0.0 SDK introduces a fundamentally new connection lifecycle:
Default behavior (no configuration needed):
server/discoverrequest withMCP-Protocol-Version: 2026-07-282026-07-28protocol version, it responds with capabilities -- no handshake, no sessionMcpClientOptions.DiscoverProbeTimeout), the client automatically falls back to the legacyinitializehandshake with2025-11-25-32022UnsupportedProtocolVersion,-32021MissingRequiredClientCapability,-32020HeaderMismatch) are never treated as legacy indicators and are surfaced as errorsOpting out of the
2026-07-28protocol version:McpClientOptions.ProtocolVersion = "2025-11-25"to force the legacyinitializehandshake and disable the automatic fallback (a non-nullProtocolVersionnow acts as both the requested version and the minimum the client accepts)Per-request metadata (
2026-07-28protocol version):_metawithio.modelcontextprotocol/protocolVersion,io.modelcontextprotocol/clientInfo, andio.modelcontextprotocol/clientCapabilities2026-07-28 Spec Alignment: SEP Implementation Status
The 2026-07-28 specification release includes 22 SEPs. The table below summarizes C# SDK status. Remaining work is tracked in the 2026-07-28 Spec Compliance milestone.
Commits viewable in compare view.
Updated ModelContextProtocol.AspNetCore from 1.4.1 to 2.0.0.
Release notes
Sourced from ModelContextProtocol.AspNetCore's releases.
2.0.0
Version 2.0.0 brings the C# SDK into stable alignment with the MCP 2026-07-28 specification.
This major release introduces discovery-first negotiation, multi-round-trip requests, stateless-by-default HTTP, caching hints, standardized headers, stronger OAuth and token-cache safety, and dedicated MCP Apps and Tasks extension packages, with down-level interoperability for peers negotiating 2025-11-25 and earlier. Review the migration guidance below.
Breaking Changes
Refer to the C# SDK Versioning documentation for details on versioning and breaking-change policies.
HttpServerTransportOptions.Statelessnow defaults totrue. Stateless servers do not create transport sessions, expose the standalone SSEGET/DELETEendpoints, or support unsolicited server-to-client requests.Stateless = falsewhen an existing server requires legacy stateful behavior. Stateful-only options now produceMCP9006warnings and apply only to down-level initialize-handshake connections.server/discoverfirst and automatically fall back to the legacyinitializehandshake for down-level servers.MCP9005warnings because these features are deprecated by the 2026-07-28 specification.MCP9005temporarily if continued use is required while planning migration.ModelContextProtocol.Extensions.Tasks#1693ModelContextProtocol.Extensions.Tasks, import its namespace, register Tasks withWithTasks(...), and replace CoreRequestMethods.Tasks*constants withTasksProtocolmembers.AuthorizationRedirectDelegateandClientOAuthOptions.AuthorizationRedirectDelegatenow produceMCP9007warnings. Migrate toClientOAuthOptions.AuthorizationCallbackHandlerso callbacks can return the authorization code, state, and issuer.UseStructuredContent = trueand a non-object return type now emit the raw value and matching schema, such asstructuredContent: 72, instead of wrapping it as{ "result": 72 }.resultproperty.Tool.inputSchemaduring deserialization #1600Toolpayload withoutinputSchemanow throwsJsonExceptioninstead of silently defaulting the schema.inputSchema; an empty{}is sufficient.S256incode_challenge_methods_supported.application_typeduring dynamic client registration #1613application_type.DynamicClientRegistrationOptions.ApplicationTypeexplicitly when the inferred value is not appropriate.HttpRequestException,TimeoutException, or genuine I/O exception instead of always wrapping failures inIOException.IOException("Failed to connect transport.")wrapper. In AutoDetect mode, inspect the outerHttpRequestExceptionand its inner SSE failure.insufficient_scopechallenge that introduces no new scopes now throwsMcpExceptioninstead of retrying indefinitely.What's Changed
InheritEnvironmentVariablestoStdioClientTransportOptions#1563 by @halter73offline_accessto authorization scope when advertised (SEP-2207) #1479 by @stephentoub (co-authored by @Copilot)McpErrorCode.ResourceNotFoundper SEP-2164 #1558 by @jayaraman-venkatesanMcpClienttool cache #1590 by @tarekghScopeSelectorDelegateto OAuth options #1596 by @halllo... (truncated)
2.0.0-rc.2
This second 2.0 release candidate advances the SDK’s
2026-07-28protocol support, expands Tasks extension conformance tests, strengthens OAuth and transport behavior, and expands 2.0 guidance ahead of general availability.Thank you to the community for using the preview and release-candidate builds and for sharing feedback and issue reports that shape this release!
Breaking Changes
Refer to the C# SDK Versioning documentation for details on versioning and breaking-change policies.
DiscoverResult.ServerInfois removed; read and deserializeMeta[MetaKeys.ServerInfo]instead.2026-07-28, replace legacy initialization, ping, logging, and resource-subscription methods withserver/discover,_metalog level, andsubscriptions/listen.statethroughAuthorizationResult.State, and should returnCode,State, andIss.IOExceptionwrapper.What's Changed
Documentation Updates
Test Improvements
_meta.uiserialization round-trip tests #1698 by @yayayouyouRepository Infrastructure Updates
... (truncated)
2.0.0-rc.1
2.0.0-rc.1 advances the v2 SDK toward general availability with stronger OAuth conformance, improved dynamic client registration, and expanded Tasks validation.
We remain on-track to release 2.0.0 stable on or before 2026-07-28.
We want to give a big thanks to @KubaZ2 for reporting the critical, ship-stopping Tasks/HTTP defect in #1720, fixed by #1722!
Breaking Changes
Refer to the C# SDK Versioning documentation for details on versioning and breaking change policies.
Remove the preview task-scope helper #1722
McpTasksServerExtensions.CreateMcpTaskScope(...)was removed from the stable surface. This affects only applications built against the v2 preview API; no stable 2.0 release has shipped.Harden OAuth issuer validation #1605
AuthorizationRedirectDelegatenow producesMCP9007, which breaks warning-as-error builds; the manual authorization flow now requires the complete redirect URL.AuthorizationCallbackHandlerand returnAuthorizationResult.Require advertised PKCE S256 support #1700
code_challenge_methods_supported: ["S256"]now cause authentication to fail instead of receiving an inferred default.Send Dynamic Client Registration application types #1613
ApplicationTypenow sends an inferredapplication_typeinstead of omitting it.DynamicClientRegistrationOptions.ApplicationTypeexplicitly when the authorization server requires another value.What's Changed
application_typein Dynamic Client Registration requests #1613 by @jayaraman-venkatesan (co-authored by @Copilot)ClientOAuthProvider#1605 by @mikekistler (co-authored by @halter73 @Copilot)Documentation Updates
release/1.x(v1.4.1) andmain(v2 preview) content #1727 by @jeffhandley (co-authored by @Copilot)Test Improvements
... (truncated)
2.0.0-preview.3
This preview reorganizes the Tasks feature into its own
ModelContextProtocol.Extensions.Taskspackage, keepingModelContextProtocol.Corefocused on the base protocol while a new generic request-handler and alternate-result surface lets the Tasks package layer on top. It also delivers correctness fixes to the draft2026-07-28protocol -- per-request client capabilities, negotiation boundaries, and theresultTypediscriminator -- plus Streamable HTTP client improvements (an empty-JSON-response fix and a new standalone GET-stream opt-out) and conformance-test consolidation.Breaking Changes
Refer to the C# SDK Versioning documentation for details on versioning and breaking change policies.
ModelContextProtocol.Extensions.Taskspackage #1693McpTaskStatus,IMcpTaskStore/InMemoryMcpTaskStore, thetasks/*request methods, and the clientGetTaskAsync/UpdateTaskAsync/CancelTaskAsync/CallToolRawAsyncmethods -- is removed fromModelContextProtocol.Coreand relocated to the newModelContextProtocol.Extensions.Taskspackage under theModelContextProtocol.Extensions.Tasksnamespace.ResultOrAlternate<T>(replacingResultOrCreatedTask<T>) plus generic extension points --McpServerRequestHandler,McpServerOptions.RequestHandlers,McpServerHandlers.CallToolWithAlternateHandler,McpRequestFilters.CallToolWithAlternateFilters, andMcpServer.InterceptOutgoingRequests-- that the Tasks package builds on.PackageReferencetoModelContextProtocol.Extensions.Tasks; changeusing ModelContextProtocol.Protocol;tousing ModelContextProtocol.Extensions.Tasks;for task types; the task client/server APIs are now extension methods (McpTasksClientExtensions/McpTasksServerExtensions), and the task store is registered via the new builder extensions instead ofMcpServerOptions.TaskStore.Experimental APIs
To support extracting Tasks (#1693),
ModelContextProtocol.Coregained a generic server-extension surface --ResultOrAlternate<T>,McpServerRequestHandler,McpServerOptions.RequestHandlers,McpServerHandlers.CallToolWithAlternateHandler,McpRequestFilters.CallToolWithAlternateFilters, andMcpServer.InterceptOutgoingRequests-- that lets extension packages such asModelContextProtocol.Extensions.Taskslayer behavior onto the server pipeline. These APIs are annotated[Experimental]under diagnostic IDMCPEXP002.This surface is still being designed: #1704 tracks composing these seams with the normal filter and subscription pipeline (typed custom RPCs, filter composition, and extension-defined subscriptions). Expect these low-level extensibility APIs to change and potentially remain
[Experimental]through the 2.0.0 stable release.What's Changed
ModelContextProtocol.Extensions.Tasksextension package #1693 by @jeffhandley (co-authored by @Copilot)Test Improvements
Acknowledgements
Full Changelog: modelcontextprotocol/csharp-sdk@v2.0.0-preview.2...v2.0.0-preview.3
2.0.0-preview.2
This second preview of the 2.0.0 series advances the SDK's alignment with the upcoming
2026-07-28MCP protocol revision: it adds client-side conformance diagnostics for the SEP-2549 caching hints, makes Streamable HTTP error responses echo the request id per the base protocol and SEP-2243, and fully stabilizes now-stable protocol properties so consumer-defined source generators serialize them correctly. Separately -- and unrelated to the protocol revision -- it introducesDeferChangedEvents()onMcpServerPrimitiveCollection<T>for batchinglist_changednotifications when registering primitives in bulk. There are no breaking changes relative tov2.0.0-preview.1.What's Changed
Documentation Updates
Acknowledgements
Full Changelog: modelcontextprotocol/csharp-sdk@v2.0.0-preview.1...v2.0.0-preview.2
2.0.0-preview.1
This is the first preview of the C# MCP SDK 2.0.0, designed for alignment with the 2026-07-28 MCP specification release. The SDK implements the
2026-07-28protocol version which fundamentally changes how clients and servers interact -- removing theinitializehandshake (SEP-2575), eliminating server-side session state (SEP-2567), introducing Multi Round-Trip Requests (SEP-2322), and deprecating legacy capabilities in favor of the new extensions framework (SEP-2133).The 2.0.0 SDK is fully backward-compatible with servers and clients using the previous
2024-11-05protocol version. Clients automatically negotiate down to the legacyinitializehandshake when connecting to older servers, and servers continue to acceptinitializerequests from older clients. API breaking changes in 2.0.0 are limited to two categories: (1) APIs for capabilities deprecated by the new specification (Roots, Sampling, and Logging), which are now marked[Obsolete]with guidance toward their replacements, and (2) experimental APIs whose contracts changed as the specifications were finalized. Stable, non-deprecated APIs from 1.x continue to work without modification.Protocol Version Negotiation and Handshake Behavior
The 2.0.0 SDK introduces a fundamentally new connection lifecycle:
Default behavior (no configuration needed):
server/discoverrequest withMCP-Protocol-Version: 2026-07-282026-07-28protocol version, it responds with capabilities -- no handshake, no sessionMcpClientOptions.DiscoverProbeTimeout), the client automatically falls back to the legacyinitializehandshake with2025-11-25-32022UnsupportedProtocolVersion,-32021MissingRequiredClientCapability,-32020HeaderMismatch) are never treated as legacy indicators and are surfaced as errorsOpting out of the
2026-07-28protocol version:McpClientOptions.ProtocolVersion = "2025-11-25"to force the legacyinitializehandshake and disable the automatic fallback (a non-nullProtocolVersionnow acts as both the requested version and the minimum the client accepts)Per-request metadata (
2026-07-28protocol version):_metawithio.modelcontextprotocol/protocolVersion,io.modelcontextprotocol/clientInfo, andio.modelcontextprotocol/clientCapabilities2026-07-28 Spec Alignment: SEP Implementation Status
The 2026-07-28 specification release includes 22 SEPs. The table below summarizes C# SDK status. Remaining work is tracked in the 2026-07-28 Spec Compliance milestone.
Commits viewable in compare view.