.NET: Bump ModelContextProtocol from 1.1.0 to 1.2.0 (#3956)

[neerajkaram]

Motivation and Context

Fixes #3956.

The Agent_MCP_Server_Auth sample currently fails with:

ModelContextProtocol.McpException: Failed to handle unauthorized response with 'Bearer' scheme. The AuthorizationRedirectDelegate returned a null or empty authorization code.

Root cause is the trailing slash in the OAuth resource parameter (resource=http://localhost:7071/), tracked upstream in modelcontextprotocol/csharp-sdk#1122 and fixed in the 1.2.x line of the MCP C# SDK. This PR picks up that fix by bumping the centrally-managed package version.

Description

Two small changes:

1. dotnet/Directory.Packages.props — bump central ModelContextProtocol pin from 1.1.0 to 1.2.0.
2. dotnet/samples/04-hosting/FoundryHostedAgents/responses/Hosted-McpTools/HostedMcpTools.csproj — remove the now-redundant VersionOverride="1.2.0" so the central pin is the single source of truth.

Why 1.2.0 and not 1.3.0: ModelContextProtocol.Core 1.3.0 transitively requires Microsoft.Extensions.* 10.0.7 and Microsoft.Extensions.AI.Abstractions 10.5.2, neither of which are currently in the central pins. Coordinating those bumps is a larger change than #3956 asks for; happy to follow up in a separate PR.

Breaking change check: The 1.2 line includes API breaks on ProtectedResourceMetadata, ToolResultContentBlock, ListTasksResult, and DynamicClientRegistrationResponse. Grepped dotnet/ for usages of all four — zero references, so this bump is non-breaking for this repo.

Verification (local, macOS, .NET 10.0.8):

• dotnet restore — clean
• dotnet build (Debug) — clean
• dotnet build -c Release — clean (Package Validation passes; no CP0001/CP0002)
• dotnet test tests/Microsoft.Agents.AI.Mcp.UnitTests -f net10.0 — 20 passed, 0 failed

No regression test added; reproducing the original failure requires the upstream TestOAuthServer + ProtectedMCPServer harness, and the fix itself is a pure dependency version bump.

Contribution Checklist

• The code builds clean without any errors or warnings
• The PR follows the Contribution Guidelines
• All unit tests pass, and I have added new tests where possible
• Is this a breaking change? If yes, add "[BREAKING]" prefix to the title

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Updates the .NET samples to use a centrally managed ModelContextProtocol package version, bumping it to 1.2.0 and removing a per-project override.

Changes:

• Bumped ModelContextProtocol from 1.1.0 to 1.2.0 in central package management (Directory.Packages.props).
• Removed the VersionOverride="1.2.0" from the sample project so it inherits the centrally pinned version.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
dotnet/samples/04-hosting/FoundryHostedAgents/responses/Hosted-McpTools/HostedMcpTools.csproj	Removes per-project version override to rely on central package versioning.
dotnet/Directory.Packages.props	Updates centrally managed ModelContextProtocol version to 1.2.0.

[neerajkaram]

@microsoft-github-policy-service agree

[neerajkaram]

The merge queue dropped this for 16 test failures that don't appear related to this PR:

Azure Functions sample tests (12 failures) : all show the same Can't determine project language from files / Worker runtime cannot be 'None' error from Azure Functions Core Tools. The failure happens at func start before any sample code runs. The failing samples include ones that don't reference MCP (e.g. 01_SequentialWorkflow, 01_SingleAgent), so this looks like an Azure Functions tooling/environment issue rather than something reachable from a NuGet version bump.

DurableTask sample tests (4 failures): all give Error: The given key was not present in the dictionary. The one test with a full stack trace (WorkflowHITLSampleValidationAsync) points to DurableStreamingWorkflowRun.DeserializeEventByType at dotnet/src/Microsoft.Agents.AI.DurableTask/Workflows/DurableStreamingWorkflowRun.cs:428 (workflow event JSON parsing). That file was introduced in #4436 on 2026-03-16 and hasn't been modified since thus the code path that throws has been there for ~2.5 months and isn't reachable through any MCP code change.

Happy to defer on next steps. Willing to rebase and re-queue once main CI is sorted, or to wait if there's already a fix in flight for either.