Bump the nuget group with 2 updates - #2003
Conversation
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-group: nuget - dependency-name: ModelContextProtocol.AspNetCore dependency-version: 2.0.0 dependency-type: direct:production update-type: version-update:semver-major dependency-group: nuget ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
.NET
erikdarlingdata
left a comment
erikdarlingdata
left a comment
There was a problem hiding this comment.
Summary
Dependabot grouped NuGet bump. Advertised as "2 updates" — ModelContextProtocol and ModelContextProtocol.AspNetCore from 1.4.1 → 2.0.0 in Darling/PerformanceMonitor.Darling.Service.csproj. In practice the PR also:
- Adds
ModelContextProtocol 2.0.0as a new direct dependency ofDarling/PerformanceMonitor.Darling.Analysisand ofPerformanceMonitor.PlanAnalysis(neither had it onmain). - Leaves
PerformanceMonitor.Common,Lite/PerformanceMonitorLite, anddeprecated/Dashboardstill pinned at1.4.1— creating solution-wide version skew with a downstream transitive[2.0.0, )requirement recorded inLite/packages.lock.json:791anddeprecated/Dashboard/packages.lock.json:776. - Flips line-endings LF → CRLF on the three touched
.csprojfiles and rewrites bothpackages.lock.jsonfiles nearly whole (real content delta is one added line each). This matches.gitattributes(* text=auto eol=crlf), so it's a normalization, not a regression — but it inflates the diff and hides the real changes.
What's good
.gitattributesnormalization brings these files back in line with repo convention.- The
Stateless = truedefault change in MCP 2.0.0 does not alter behavior here:DarlingMcpHostService.cs:399andLite/Mcp/McpHostService.cs:75already setWithHttpTransport(options => options.Stateless = true)explicitly. - Group PR keeps the noise consolidated.
What needs attention
- Version skew (BLOCKER) —
ModelContextProtocolends up pinned at1.4.1in Common/Lite/deprecated Dashboard and2.0.0in Darling.Service/Darling.Analysis/PlanAnalysis, with noDirectory.Packages.propsto unify. Either bump every direct pin in the same PR or narrow this PR to just the Darling.Service bump and drop the twoPlanAnalysis/Darling.Analysisadditions (see the inline comments — those two additions are the cause of the lockfile conflict). The comment atDarling.Service.csproj:27-30explicitly claims "Lite's exact MCP stack/version" and this PR breaks that invariant. - New direct dependencies (BLOCKER) — Dependabot doesn't add packages. The two new
<PackageReference>lines inDarling.Analysis.csproj:20andPlanAnalysis.csproj:25were not onmain; nothing in either project's.cssources importsModelContextProtocol.*. Confirm intent or drop. - MCP 2.0.0 is a major breaking release — Roots/Sampling/Logging APIs now warn as
MCP9005, plus stateless-only options warn asMCP9006, plus discovery-first negotiation.EnableNETAnalyzers=trueis on across the affected csprojs; verify neither warning is escalated to error under the repo's analyzer config, and re-runDarling.Tests/DarlingMcp*Tools*Tests.cs— no tests were added or updated in this PR. - Base branch is
main— per the review focus for this repo, PRs should targetdev. Dependabot targets the repo default (currentlymain); if this cadence should land indevfirst for validation, addtarget-branch: devto.github/dependabot.ymlunder the nuget update block. - Not touched but worth noting — this PR touches no PlanAnalyzer, no SQL, no
install/*.sql, noupgrades/*, no.github/workflows/build.yml, no C#/WPF/Avalonia code. Nothing to flag on those focus areas.
Comments only — the maintainer makes the call.
Generated by Claude Code
| <!-- The plan fetcher connects to the MONITORED SQL Server (same client the Service uses); | ||
| Npgsql and Logging.Abstractions flow transitively from the Storage/Notifications references. --> | ||
| <PackageReference Include="Microsoft.Data.SqlClient" Version="7.0.2" /> | ||
| <PackageReference Include="ModelContextProtocol" Version="2.0.0" /> |
There was a problem hiding this comment.
New direct <PackageReference> — not a version bump. ModelContextProtocol was not a direct dependency of PerformanceMonitor.Darling.Analysis on main; this line adds it. Dependabot doesn't add net-new package references, so this is either an artifact of Dependabot's lockfile regeneration reacting to something else in the group update, or a leftover from a manual staging step that got picked up by the bot. Please confirm the intent: does the Analysis project actually consume MCP types directly? A grep under Darling/PerformanceMonitor.Darling.Analysis/ for ModelContextProtocol / McpServerTool / IMcpServer shows no usages — if that stays true, drop this line and let it flow transitively via PerformanceMonitor.Common where it belongs.
Generated by Claude Code
| XML), so it needs the SqlClient runtime connection surface. Version matches Lite/Dashboard/the Darling | ||
| service (7.0.1) so there is no transitive version skew. --> | ||
| <PackageReference Include="Microsoft.Data.SqlClient" Version="7.0.2" /> | ||
| <PackageReference Include="ModelContextProtocol" Version="2.0.0" /> |
There was a problem hiding this comment.
New direct <PackageReference> — this is the source of the lockfile skew below. ModelContextProtocol was not a direct dependency of PerformanceMonitor.PlanAnalysis on main. PlanAnalysis is the shared plan-analysis lib consumed by Lite, Dashboard, the Darling service, and Darling.Analysis (via InternalsVisibleTo and ProjectReference); the moment MCP is pinned here, every downstream project transitively inherits [2.0.0, ) — including Lite/PerformanceMonitorLite.csproj and deprecated/Dashboard/Dashboard.csproj, both of which still directly pin 1.4.1. That is the exact conflict now recorded in Lite/packages.lock.json:791 and deprecated/Dashboard/packages.lock.json:776. Same question as on Darling.Analysis.csproj:20: does PlanAnalysis actually reference any MCP types? Nothing under PerformanceMonitor.PlanAnalysis/*.cs imports ModelContextProtocol.*. If unused, drop this line — that also unblocks the lockfile-conflict problem in one shot.
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) partially applied — version skew across the solution. After this PR:
| project | pin |
|---|---|
PerformanceMonitor.Common.csproj:20 |
1.4.1 |
Lite/PerformanceMonitorLite.csproj:76-77 |
1.4.1 |
deprecated/Dashboard/Dashboard.csproj:50-51 |
1.4.1 |
Darling/PerformanceMonitor.Darling.Service.csproj:32-33 |
2.0.0 |
Darling/PerformanceMonitor.Darling.Analysis.csproj:20 |
2.0.0 (newly added) |
PerformanceMonitor.PlanAnalysis.csproj:25 |
2.0.0 (newly added) |
There is no Directory.Packages.props for CPM, so pins are per-project. Since Lite and deprecated/Dashboard both reference PerformanceMonitor.PlanAnalysis transitively, NuGet will unify at the higher 2.0.0 at build time despite the 1.4.1 direct pin — and the shipping bits in Lite will silently be MCP 2.0.0.
Two follow-ons that matter here:
- The comment on line 27-30 above ("AN4: the analysis MCP tools over Streamable HTTP — Lite's exact MCP stack/version") is now false. Either bump Lite/Common/deprecated Dashboard in the same PR, or update the comment.
- MCP 2.0.0 is a hard-break release. From the release notes bundled in the PR body: (a)
HttpServerTransportOptions.Statelessdefaults totrue— no behavior change here sinceDarlingMcpHostService.cs:399andLite/Mcp/McpHostService.cs:75both explicitly set it totrue; (b) Roots, Sampling, and Logging APIs emitMCP9005deprecation warnings; (c) discovery-first negotiation with fallback toinitialize. Given<AnalysisLevel>latest-recommended</AnalysisLevel>and the possibility thatMCP9005/MCP9006are treated as errors under CI's warning rules, this needs a green CI run before merge — and theDarling.Tests/DarlingMcp*Tools*Tests.cssuite should be re-run against the bumped stack, since none of those tests were touched by this PR.
Generated by Claude Code
| "type": "Project", | ||
| "dependencies": { | ||
| "Microsoft.Data.SqlClient": "[7.0.2, )", | ||
| "ModelContextProtocol": "[2.0.0, )", |
There was a problem hiding this comment.
Lockfile conflict recorded here. Lite's direct pin is still 1.4.1 (this same file, line 104: "ModelContextProtocol": {"type": "Direct", "resolved": "1.4.1"}), but the transitive path through PerformanceMonitor.PlanAnalysis now requires [2.0.0, ). Under RestorePackagesWithLockFile=true in locked mode, this will either fail restore with a version-conflict error or silently coerce Lite up to 2.0.0 — either way the "Lite ships MCP 1.4.1" contract in Lite/PerformanceMonitorLite.csproj:76-77 is broken. Fix at the source (PlanAnalysis.csproj:25) rather than here.
Generated by Claude Code
| "type": "Project", | ||
| "dependencies": { | ||
| "Microsoft.Data.SqlClient": "[7.0.2, )", | ||
| "ModelContextProtocol": "[2.0.0, )", |
There was a problem hiding this comment.
Same conflict as Lite/packages.lock.json:791: deprecated/Dashboard's direct pin here is 1.4.1 (line 100), but this project entry now requires [2.0.0, ) transitively via PlanAnalysis. Fix at PlanAnalysis.csproj:25.
Generated by Claude Code
|
Closing: this predates #1991's config fix (target-branch: dev), which is merged to dev but not yet on main — and dependabot reads its config from the default branch, so this PR was created against main, where check-branches correctly blocks everything but dev. The bumps themselves will be re-raised by the weekly group once a release ships the config to main; if either package matters sooner it can ride a manual dev PR. |
|
This pull request was built based on a group rule. Closing it will not ignore any of these versions in future pull requests. To ignore these dependencies, configure ignore rules in dependabot.yml |
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.
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore <dependency name> major versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)@dependabot ignore <dependency name> minor versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)@dependabot ignore <dependency name>will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)@dependabot unignore <dependency name>will remove all of the ignore conditions of the specified dependency@dependabot unignore <dependency name> <ignore condition>will remove the ignore condition of the specified dependency and ignore conditions