Migrate both MCP hosts to ModelContextProtocol SDK 2.0 (MCP 2026-07-28 spec) - #2004
Merged
Conversation
The 1.4.1 -> 2.0.0 major, taken deliberately after a grouped auto-bump demonstrated the failure mode (#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 #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 #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 #1990 is removed (per #1991's "remove this once #1990 lands"), so SDK patches/minors resume flowing through the weekly group. Closes #1990 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
ReviewReviewed the diff ( What it does: Bumps Verified during review:
No correctness, security, parity, or performance concerns. The lockfile-only diff is exactly what's expected for a version bump of this shape. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Fixes #1990. Takes the ModelContextProtocol 1.4.1 → 2.0.0 major deliberately, the way the issue prescribed after #1822's grouped auto-bump half-applied it: the version moves in every referencing project in one commit (PerformanceMonitor.Common, Lite, Darling.Service, deprecated/Dashboard) with all six affected
packages.lock.jsonfiles regenerated together under the CI-pinned SDK 10.0.302. (A first regeneration pass under SDK 10.0.300 silently downgraded framework packages 10.0.10 → 10.0.8 in the locks — caught and redone; worth knowing for future lockfile work on non-CI machines.)No code changes were needed. Walking the issue's checklist:
Stateless = trueexplicitly since MCP server doesn't expose tools in Google Antigravity #1074 (clients that don't echoMcp-Session-Idotherwise connect but list zero tools). The 2.0 default now simply matches what we ship. Every exposed tool already works without session state — see the live verification below.MapMcp, so whatever endpoints 2.0 adds inherit them structurally. Verified live, not just structurally (below).SamplingPercentfalse positives).McpSchemaCompat(the Gemini schema rewriter, the deepest SDK-API consumer we have) compiles unchanged.How was this tested?
initializereturns the correct envelope with no session header (stateless confirmed);tools/listwith no session round-trip returns all 89 tools;tools/call list_serversexecutes against the store; and a request with a non-loopback Host is rejected 400 by the DNS-rebinding guard before any 2.0 endpoint (evil.example.localtest.meresolved to 127.0.0.1).AddMcpServer/WithHttpTransport/WithTools/MapMcp) was validated end-to-end on Performance Studio first (deps: Bump ModelContextProtocol and ModelContextProtocol.AspNetCore PerformanceStudio#422): stateless handshake, tool listing/calls, and Host/Origin guard behavior all confirmed there against a booted host.Dogfood plan after merge: nightly → monitor-box upgrade → this session's own MCP client (89-tool surface) reconnecting against the upgraded box is the final live-client check the issue asks for.
Which component(s) does this affect?
Checklist
dotnet build -c Debug)🤖 Generated with Claude Code