MCP tool schemas exclude DI services by type, closing a reflection race that leaked them into tools/list (issue-4075)

[erikdarlingdata]

This fixes the flake tracked in issue-4075. The issue stays open until two weeks of clean CI.

Root cause (credit: pr-tender seat's repro, issue comment 5806331396)

A reflection race, not the static-cache theory from the earlier lane's decompile (that theory is
ruled out: the SDK's descriptor cache key includes ConfigureParameterBinding, and the SDK makes a
fresh closure per McpServerTool.Create call, so it can't be shared between two service providers).

What happens, read in the decompiled ModelContextProtocol.Core 2.2.0, Microsoft.Extensions.AI.Abstractions
10.8.3, and the .NET 10.0.12 runtime:

1. ReflectionAIFunctionDescriptor's constructor calls method.GetParameters() once and records each
   parameter's DI-service exclusion in a Dictionary<ParameterInfo, …>.
2. It then calls AIJsonUtilities.CreateFunctionJsonSchema, which calls method.GetParameters() a
   second time; its IncludeParameter looks each parameter up in that dictionary.
3. ParameterInfo has no Equals override, so the lookup compares object references.
4. RuntimeMethodInfo's parameter-array cache fills non-atomically (m_parameters ??= ...). A concurrent
   first GetParameters() call on the SAME MethodInfo, from another thread, can return a different
   array of ParameterInfo objects.
5. The lookup misses, the DI-service parameter is treated as a plain argument, and it leaks into the
   served schema — exactly what McpToolsListBudgetTests: lazy Measure() + service-leak diagnostic on unpinned params (#4075) #4094's diagnostic caught (IsService(type) = True on the build's own
   provider, build count = 1, get_alert_settings.postgres in the served schema).

Measured in a standalone repro against these exact package versions:

• one thread: 0/5,000 leaked
• a second thread racing GetParameters() on the same method: 37/5,000 leaked (25/3,000 in an earlier run)
• same race with a by-type IncludeParameter guard: 0/5,000 leaked

Fix

PerformanceMonitor.Common/Mcp/McpSchemaCompat.cs, WithGeminiCompatibleTools: each tool now gets its
own copy of GeminiCompatSchemaOptions (via a new internal SchemaOptionsFor(IServiceProvider)) with an
IncludeParameter that excludes DI-service-typed parameters by CLR type (IServiceProviderIsService),
ANDed with the SDK's own identity-keyed lookup. A missed identity lookup can no longer let a service
through, because this check never depends on ParameterInfo identity — it always sees the parameter's
correct declared type. The shared static GeminiCompatSchemaOptions instance is left unmutated (the with
expression on the record copies it); only the IncludeParameter delegate differs per provider. Parameter
BINDING (which value is passed at invocation) is unaffected — it consistently uses the first
GetParameters() array; only the served SCHEMA was at risk. Both Darling and Lite go through this one file.

Out of scope, noted for later: the SDK's own request-scoped parameter types (the ones
RequestServiceProvider.IsAugmentedWith recognises) take the same double-GetParameters() path and are
not covered by this by-type guard — no Darling/Lite tool takes one of those parameter types today, so this
is dormant risk, not a live gap. Also out of scope: reporting the upstream double-GetParameters() /
identity-keyed-lookup design to Microsoft.Extensions.AI — the root cause is theirs, not documented here as
a follow-up issue per this lane's brief (mechanical fix only).

Test

New Darling/Darling.Tests/McpSchemaCompatServiceLeakRaceTests.cs: emits fresh throwaway
[McpServerTool]-decorated static methods T(Svc svc, int x) via System.Reflection.Emit (so each
method's parameter cache starts empty every run) and races a bystander thread's GetParameters() call
against the tool build.

• RaceGetParameters_WithByTypeGuard_NeverLeaksTheServiceIntoTheSchema (2,000 methods, through
  McpSchemaCompat.SchemaOptionsFor, the exact factory the production path now uses): 0/2,000 leaked.
• RaceGetParameters_WithoutTheGuard_CanLeakTheServiceIntoTheSchema (5,000 methods, plain
  AIJsonSchemaCreateOptions with no guard, mirroring the pre-fix path): reproduced the leak — asserts
  leaks > 0 rather than an exact count (thread scheduling isn't deterministic across machines), and on
  this run it did leak, confirming the race is real on this box before asserting the fix closes it.

Ran (this Mac, dotnet <dll> -class ..., WindowsDesktop.App stripped from runtimeconfig.json and restored
after):

• McpSchemaCompatServiceLeakRaceTests: 2 total, 0 failed.
• McpToolsListBudgetTests + McpUnknownArgumentGuardTests + McpToolGuideTests: 21 total, 0 failed.
• Lite.Tests: build only (dotnet build), succeeded — 0 warnings, 0 errors. Execution left to CI (WPF).
• Full Darling.Tests suite once: 13,310 total, 216 failed, 714 skipped. None of the failures are in
  McpSchemaCompat*, McpToolsListBudget*, McpUnknownArgumentGuard*, McpToolGuide*, or any Alert
  tools test class — grepped the full-run failure list for those names, zero hits. The 216 failures are
  the pre-existing Windows-only failure set this Mac's rig always shows (brief cites 214; the small
  drift is consistent with the usual noise on this rig, not a regression from this change).

Not verified

• Which specific concurrent test thread races the budget build inside the real full-suite run; this PR
  proves the mechanism in isolation (per the brief), not which exact pair of classes collides in CI. The
  fix closes the mechanism regardless of which thread wins.
• The dormant risk in a live host process (another thread reflecting over a tool method during MCP server
  startup) — not exercised by any test here or before.

Coordinator verification (branch head a465a2c)

• The unguarded-race repro is now [Fact(Explicit = true)]. It asserts the race happens (leaks > 0), so on a slow or lightly loaded runner it would fail whenever the window never opens. That would be a new flake in a PR that fixes a flake. It runs on demand (-method ... -explicit on), and it passed on demand here. The guarded test (0 of 2,000 leaks) is the one CI runs.
• The full Darling suite on macOS, compared with dev on the same rig: the only difference was DocCommentHygieneTests ×2, a <see cref="ModuleBuilder"/> that resolves to nothing the repo spells. Made it prose; the class passes 77/77.
• McpSchemaCompatServiceLeakRaceTests 2/2 (+1 explicit), and McpToolsListBudgetTests 5/5.
• The fix only ever removes a parameter from a schema, and only when its type is a registered DI service, which is exactly what the SDK meant to do. So a genuine argument can't be dropped unless its type is registered as a service.
• CI sightings of this flake so far: get_alert_history.dataService (Lite, ×3), get_alert_settings.postgres and get_ag_health.postgres (Darling). All match the mechanism.

CHANGELOG entry

Fixed a race in MCP tool-schema generation that could leak a dependency-injected service (e.g. the
PostgreSQL connection) into a tool's advertised parameter schema under concurrent test/build load.