Skip to content

Bump ModelContextProtocol and ModelContextProtocol.AspNetCore - #2100

Merged
erikdarlingdata merged 3 commits into
devfrom
dependabot/nuget/Darling/PerformanceMonitor.Darling.Analysis/dev/nuget-fccd249c43
Aug 10, 2026
Merged

erikdarlingdata merged 3 commits into
devfrom
dependabot/nuget/Darling/PerformanceMonitor.Darling.Analysis/dev/nuget-fccd249c43

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Aug 7, 2026

Copy link
Copy Markdown
Contributor

Pinned ModelContextProtocol at 2.1.0.

Release notes

Sourced from ModelContextProtocol's releases.

2.1.0

This release adds an opt-in subscriptions/listen handler for custom server-side notification streams, improves HTTP transport fallback reliability, and expands guidance and samples for telemetry and binary resources.

What's Changed

  • Keep AutoDetect channel open after provisional SSE failure #​1768 by @​PranavSenthilnathan
  • Preserve HTTP status codes across target frameworks #​1767 by @​PranavSenthilnathan
  • Fall back to initialize when server/discover fails at the HTTP layer #​1766 by @​rbstp
  • Add public subscriptions/listen server handler (SEP-2575) #​1775 by @​tarekgh

Documentation Updates

  • Add README for the InMemoryTransport sample #​1769 by @​AkbarDizaji
  • Add Application Insights telemetry example #​1778 by @​lntutor
  • Clarify client handling of embedded binary tool resources #​1762 by @​luisangelrod

Test Improvements

  • Speed up CLI argument escaping tests #​1773 by @​PranavSenthilnathan

Repository Infrastructure Updates

  • Clarify AI disclosure format with a > [!NOTE] alert example #​1771 by @​PranavSenthilnathan (co-authored by @​Copilot)
  • Bump the npm_and_yarn group across 1 directory with 6 updates #​1787
  • Avoid reading Configuration in Directory.Build.props #​1776 by @​lntutor
  • Bump danielpalme/ReportGenerator-GitHub-Action from 5.5.10 to 5.5.11 #​1784

Acknowledgements

  • @​AkbarDizaji made their first contribution in #​1769
  • @​luisangelrod made their first contribution in #​1762
  • @​rbstp submitted issue #​1765 (resolved by #​1766)
  • @​TomasHubelbauer submitted issue #​1026 (resolved by #​1778)
  • @​Youssef1313 submitted issue #​995 (resolved by #​1766)
  • @​eng-marani submitted issue #​1261 (resolved by #​1762)
  • @​jeffhandley @​tarekgh @​halter73 @​PranavSenthilnathan reviewed pull requests

Full Changelog: modelcontextprotocol/csharp-sdk@v2.0.0...v2.1.0

Commits viewable in compare view.

Updated ModelContextProtocol.AspNetCore from 2.0.0 to 2.1.0.

@dependabot dependabot Bot added .NET Pull requests that update .NET code dependencies Pull requests that update a dependency file labels Aug 7, 2026

@erikdarlingdata erikdarlingdata left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Summary

Dependabot grouped bump of ModelContextProtocol + ModelContextProtocol.AspNetCore from 2.0.0 → 2.1.0. Targets dev — good.

What the PR does

  • Bumps ModelContextProtocol / ModelContextProtocol.AspNetCore in Darling/PerformanceMonitor.Darling.Service/PerformanceMonitor.Darling.Service.csproj:30-31 (the only project that legitimately holds these references on dev).
  • Regenerates Lite/packages.lock.json and deprecated/Dashboard/packages.lock.json.
  • Also adds a NEW ModelContextProtocol PackageReference to two projects that did not have it: Darling/PerformanceMonitor.Darling.Analysis/PerformanceMonitor.Darling.Analysis.csproj:20 and PerformanceMonitor.PlanAnalysis/PerformanceMonitor.PlanAnalysis.csproj:25. Confirmed against base 3022f3a.

Needs attention

  • Blocker — dependency scope creep. The two new PackageReference additions are not version bumps; they widen the dependency graph. PlanAnalysis is the shared library that Lite, Dashboard, and Darling all consume, so pulling MCP into it forces MCP into every consumer's closure for no code reason. Darling.Analysis is the pure analysis library; MCP hosting already lives in Darling.Service. Both additions should be reverted before merge. Inline comments on each line.
  • CI is red. build and Darling PostgreSQL tests both failed on this PR (Darling Linux build, review, and check-branches are green). Given the two new PackageReference additions, this is likely related; worth reading the failing job logs before force-rebasing.
  • CRLF↔LF flip on every touched csproj. All four csproj files show every line as changed even where the text is identical — Dependabot's writer flipped line endings. Not a merge blocker, but if .csproj should be CRLF-locked here, tighten .gitattributes so future grouped bumps don't repaint every line.
  • deprecated/ is being tracked by Dependabot. deprecated/Dashboard/packages.lock.json was regenerated. Consider excluding deprecated/** from the nuget group in .github/dependabot.yml — inline comment on the file.

What's fine

  • Base branch is dev, per .github/dependabot.yml.
  • No SQL install/upgrade scripts, no PlanAnalyzer.cs, no build.yml changes — none of the PlanAnalyzer-sync / upgrade-path / SignPath gates apply here.

If Dependabot's grouped update logic is going to keep introducing new PackageReferences on 2.x → 2.y bumps, that is worth flagging upstream / considering a groups.nuget.update-types restriction.


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.1.0" />

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a version bump — this is a brand-new PackageReference. ModelContextProtocol was not declared on dev for this project (confirmed against base 3022f3a), so Dependabot's grouped update materialized it here as a side effect of bumping the reference that legitimately lives in PerformanceMonitor.Darling.Service.

Darling.Analysis is the analysis library (DarlingAnalysisService/PgPlanFetcher) — MCP is a hosting concern that already lives in Darling.Service (line 30 of that csproj). Adding it here expands the dependency surface of a plain library for no code reason and is likely contributing to the failing build/Postgres-tests checks on this PR.

This addition should be reverted before merge; only the version numbers on the projects that already declared ModelContextProtocol/ModelContextProtocol.AspNetCore should change.


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.1.0" />

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same problem as the Darling.Analysis csproj, and worse here: PerformanceMonitor.PlanAnalysis is the SHARED plan-analysis library referenced by Lite, Dashboard, and the Darling service (via InternalsVisibleTo on PerformanceMonitorLite/PerformanceMonitorDashboard/Lite.Tests/Dashboard.Tests/Darling.Tests, plus the direct ProjectReference from Darling.Service.csproj).

Adding ModelContextProtocol here forces MCP into every consumer's closure — Lite, Dashboard, Darling — for a library whose stated purpose (per the comment two lines above) is running ActualPlanExecutor against SqlClient. There is no MCP surface in this project; the MCP tools that USE the shared parser live in Darling.Service and in Lite/Dashboard.

Confirmed against base 3022f3a: this line did not exist before. Revert this addition; only bump the versions in projects that already declared the reference.


Generated by Claude Code

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dependabot is regenerating the lockfile for code under deprecated/. The folder name signals this is not shipped, so bumping it produces review noise and, worse, could keep pinning deprecated code to new package graphs indefinitely.

Consider excluding deprecated/** from the nuget update in .github/dependabot.yml (either move to directories: scoping or add an ignore: entry / paths filter), so grouped bumps only touch the active projects.


Generated by Claude Code

<InternalsVisibleTo Include="Darling.Tests" />
</ItemGroup>
</Project>
<Project Sdk="Microsoft.NET.Sdk.Worker">

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All four touched csproj files show every line as changed even where the text is identical (-<Project Sdk=...> / +<Project Sdk=...> on line 1, and so on). That is the signature of a CRLF↔LF flip introduced by Dependabot's writer.

If the repo's convention is CRLF for .csproj (typical for .NET/Windows tooling), add or tighten .gitattributes — e.g. *.csproj text eol=crlf — so future bumps don't retouch every line and drown the real diff.


Generated by Claude Code

@dependabot dependabot Bot changed the title Bump the nuget group with 2 updates Bump ModelContextProtocol and ModelContextProtocol.AspNetCore Aug 7, 2026
@dependabot
dependabot Bot force-pushed the dependabot/nuget/Darling/PerformanceMonitor.Darling.Analysis/dev/nuget-fccd249c43 branch from 2cf0150 to 785e082 Compare August 7, 2026 18:45
Bumps ModelContextProtocol from 2.0.0 to 2.1.0
Bumps ModelContextProtocol.AspNetCore from 2.0.0 to 2.1.0

---
updated-dependencies:
- dependency-name: ModelContextProtocol
  dependency-version: 2.1.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: nuget
- dependency-name: ModelContextProtocol.AspNetCore
  dependency-version: 2.1.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: nuget
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot
dependabot Bot force-pushed the dependabot/nuget/Darling/PerformanceMonitor.Darling.Analysis/dev/nuget-fccd249c43 branch from 785e082 to b0890f7 Compare August 10, 2026 10:15
…te lock files

Dependabot only bumped PlanAnalysis and Darling.Service; Common, Lite, and the
deprecated Dashboard still pinned 2.0.0 directly, which is NU1605 (downgrade,
warning-as-error in test projects), and the transitive lock files were never
re-evaluated, which is NU1004 in locked-mode restore. One version everywhere
plus --force-evaluate lock regeneration.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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.1.0" />

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This adds a brand-new direct PackageReference to ModelContextProtocol on the shared PerformanceMonitor.PlanAnalysis project — it wasn't here before this PR. Two things stand out:

  1. grep -rl "ModelContextProtocol" PerformanceMonitor.PlanAnalysis/ only matches this line — no source file in this project actually uses the MCP SDK. It looks unused.
  2. This PR's title/body describe a pure version bump (ModelContextProtocol/ModelContextProtocol.AspNetCore 2.0.0 → 2.1.0) sourced from a Dependabot changelog. Dependabot doesn't add new package references, only bump existing ones — so this addition is out of scope for what the PR claims to do, and it fans out into every consumer's packages.lock.json (Darling.Tests, Darling.Viewer, Lite, Lite.Tests, deprecated/Dashboard all pick up a new "ModelContextProtocol": "[2.1.0, )" dependency on performancemonitor.plananalysis).

Every other PackageReference in this repo's .csproj files carries a `` comment (see the AN4 comment a few lines up in the Darling Service csproj, or the comment above Microsoft.Data.SqlClient right here). This new line has none, and I can't find the justification. Was this meant to land in a different PR, or should it be dropped from this one?

Comment thread deprecated/Installer/packages.lock.json Outdated
"requested": "[10.0.10, )",
"resolved": "10.0.10",
"contentHash": "f5VCIE7AJpd5YvzNTeMGVzQIgyE9tX+AreTYwQF+REbu+DZo/2Ae+jNSwhPEYrVz6RRkd7y8ubXjk6Nn6Ka+Cg=="
"requested": "[10.0.8, )",

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unrelated to the ModelContextProtocol bump this PR is about: Microsoft.NET.ILLink.Tasks is being downgraded here, 10.0.1010.0.8 (confirmed against origin/dev, which has 10.0.10). This package isn't referenced by any .csproj/.props in the repo — it's the SDK's implicit trimming-tasks package, so its "requested" version tracks whatever .NET SDK patch generated the lock file. global.json pins the SDK to 10.0.302 with rollForward: latestPatch, so a clean restore on the pinned SDK shouldn't produce 10.0.8 here. This looks like the lock file was regenerated with a different/older SDK than the rest of the repo used, and it's an accidental downgrade riding along with the intended bump rather than something this PR meant to change.

@claude

claude Bot commented Aug 10, 2026

Copy link
Copy Markdown

Reviewed this as a T-SQL/parity-focused pass, but the actual diff is entirely .NET dependency plumbing (no SQL changes), so the review is scoped accordingly. Two inline comments posted on concrete issues; summary below.

Scope creep beyond the stated bump. The PR title/description claim a pure ModelContextProtocol / ModelContextProtocol.AspNetCore 2.0.0 → 2.1.0 bump, but PerformanceMonitor.PlanAnalysis/PerformanceMonitor.PlanAnalysis.csproj also gains a brand-new direct PackageReference to ModelContextProtocol that appears unused (no source file in that project references the MCP SDK) and propagates into every downstream lock file (Darling.Tests, Darling.Viewer, Lite, Lite.Tests, deprecated/Dashboard). See inline comment. Separately, deprecated/Installer/packages.lock.json downgrades the implicit Microsoft.NET.ILLink.Tasks package 10.0.10 → 10.0.8, unrelated to MCP and inconsistent with the SDK pinned in global.json. Neither of these is explained by "bump MCP to 2.1.0," and both look like drift from whatever process generated this branch rather than intentional changes.

Line-ending inconsistency. Darling/PerformanceMonitor.Darling.Service/PerformanceMonitor.Darling.Service.csproj and PerformanceMonitor.PlanAnalysis/PerformanceMonitor.PlanAnalysis.csproj were committed with literal CRLF bytes baked into the git blob (verified via git show <sha>:<path> | file -), unlike every other touched file in this PR (Lite/PerformanceMonitorLite.csproj, PerformanceMonitor.Common/PerformanceMonitor.Common.csproj, deprecated/Dashboard/Dashboard.csproj), which stayed LF-normalized as .gitattributes (* text=auto eol=crlf) expects for storage. That's why those two files show as full-file rewrites in the diff instead of the expected 1-2 line version bump — worth normalizing back to LF before merge so git blame/future diffs on these files stay clean.

Lite/Darling parity: the actual MCP version bump itself is applied consistently to both apps (Lite, Darling Service, and the deprecated Dashboard all move ModelContextProtocol/ModelContextProtocol.AspNetCore to 2.1.0 together) — no drift there.

No SQL Server object changes, no security-relevant surface touched (no new I/O, credential, or query-construction code), and no missing-index-DMV concerns apply here since this is exclusively package/lock-file churn.

…K-artifact lock delta

- PerformanceMonitor.PlanAnalysis: remove the ModelContextProtocol reference
  dependabot materialized — no source in the project uses the SDK, and it
  forced MCP into every consumer's closure (review round 1).
- Rebuild the dependabot-touched csprojs from dev so the diff is the two
  version-bump lines per file instead of whole-file CRLF rewrites.
- deprecated/Installer lock: revert the ILLink.Tasks 10.0.10 -> 10.0.8
  downgrade — an artifact of regenerating locks on a 10.0.300 SDK locally;
  the file's graph is untouched by this bump so dev's entry is correct.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@erikdarlingdata

Copy link
Copy Markdown
Owner

Review round taken, all four findings addressed in the follow-up commit:

  1. Materialized MCP reference — removed from PerformanceMonitor.PlanAnalysis (source grep confirms zero SDK usage in the project; the reference existed nowhere on dev and was dependabot's side effect). Darling.Analysis had no reference at HEAD — its only delta was the line-ending rewrite, which is also gone now.
  2. CRLF flips — the dependabot-touched csprojs were rebuilt from dev with only the version lines re-applied; the csproj diff is now exactly two bump lines per file across four files.
  3. ILLink.Tasks downgrade — correctly diagnosed: my lock regeneration ran on a local 10.0.300 SDK vs CI's 10.0.302. deprecated/Installer's graph is untouched by this bump, so its lock is reverted to dev's entry wholesale.
  4. deprecated/** dependabot exclusion + .gitattributes tightening — agreed, but they're repo-config changes that don't belong in a dependency bump; both are queued into the dependabot-housekeeping PR that follows this one (central package management + Studio-style major/patch-minor split). One nuance for the exclusion: the deprecated projects are still in the solution, so locked-mode restore needs their lock files consistent when a shared dependency bumps — the housekeeping PR will reconcile that (likely VersionOverride-free CPM handles it, since the bump then happens in one place).

@claude

claude Bot commented Aug 10, 2026

Copy link
Copy Markdown

Reviewed. This PR is a mechanical Dependabot bump of ModelContextProtocol / ModelContextProtocol.AspNetCore 2.0.0 → 2.1.0, touching only .csproj files and packages.lock.json lockfiles — no T-SQL, no application logic.

  • Lite/Darling parity: intact. Both apps (plus their test projects, the shared PerformanceMonitor.Common, and the deprecated Dashboard project) are bumped together to the same version with matching content hashes.
  • Correctness/security/performance: nothing to flag — no code paths changed. Per the PR description, 2.1.0 is a minor release (opt-in subscriptions/listen handler, HTTP transport fallback fixes, telemetry/binary resource docs) with no noted breaking changes.

No findings. LGTM.

@erikdarlingdata
erikdarlingdata merged commit 266f869 into dev Aug 10, 2026
5 checks passed
@erikdarlingdata
erikdarlingdata deleted the dependabot/nuget/Darling/PerformanceMonitor.Darling.Analysis/dev/nuget-fccd249c43 branch August 10, 2026 10:52
erikdarlingdata added a commit that referenced this pull request Aug 10, 2026
Central package management + dependabot major/minor split (#2100 follow-up)
dphugo pushed a commit to dphugo/PerformanceMonitor that referenced this pull request Aug 19, 2026
50k vs 200k rows was not enough: a fast runner's fixed per-run cost plus
cache warmth accumulating across the two measured runs inverted the pair
in the field (d1=279ms, d4=217ms, on PR erikdarlingdata#2100's unrelated dependency
bump). 50k vs 500k puts the variable term an order of magnitude above
the observed fixed-cost floor, so monotonicity is physics again instead
of a coin flip. Test-only change; the telemetry and alert assertions
are untouched.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
dphugo pushed a commit to dphugo/PerformanceMonitor that referenced this pull request Aug 19, 2026
…gdata#2100 follow-up)

Directory.Packages.props now owns every package version; csprojs keep
bare PackageReferences. A dependency bump is one line and every consumer
moves atomically - the multi-project misalignment dependabot shipped in
PR erikdarlingdata#2100 (NU1605 downgrade errors from a partial bump) cannot recur.
tools/CompactionRepro keeps its deliberate DuckDB 1.5.3 via
VersionOverride. Lock files regenerate as CPM format v2.

dependabot.yml: the nuget group takes only minor+patch updates, so a
major lands as its own PR instead of hiding in a routine batch
(Studio's convention).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file .NET Pull requests that update .NET code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant