Add ASP.NET Core per-user MCP client sample

[luisangelrod]

Summary

• add a compiled ASP.NET Core Web API sample that keeps one MCP client connection per application user/session
• serialize operations within a session while allowing different sessions to run concurrently
• bridge MCP elicitation requests to application-owned HTTP endpoints
• dispose sessions explicitly, after idle expiration, and during application shutdown
• document identity, scale-out, resource, and progress-streaming considerations
• add focused tests for concurrent creation, reuse, per-session serialization, cross-session concurrency, cleanup, and elicitation completion/cancellation

Why

ASP.NET Core applications need an application-lifetime owner for stateful MCP clients. The SDK can correlate concurrent protocol messages, but the application still needs to decide who owns each live connection, how frontend interaction reaches an elicitation handler, and when the connection is disposed. This sample makes those responsibilities explicit without presenting the in-memory registry as a distributed production store.

Validation

• dotnet test tests/AspNetCoreMcpClient.Tests/AspNetCoreMcpClient.Tests.csproj --no-restore
  • 5 passed
• dotnet format tests/AspNetCoreMcpClient.Tests/AspNetCoreMcpClient.Tests.csproj --verify-no-changes --no-restore
• git diff --check

Closes #1126

[jeffhandley]

Thanks, @luisangelrod! It will probably take a week or so for us to review this adequately. Stay tuned though!

[luisangelrod]

Thanks, Jeff. I appreciate the update. I will stay available for feedback and will be happy to make any requested revisions.

[jeffhandley]

Thanks for putting this together, @luisangelrod — this is a genuinely useful sample. The separation of the application session from the MCP protocol session is the right framing, and SessionClientRegistry<TClient> handles the tricky parts carefully: the removal races, cleaning up when the client factory throws, and deterministic async disposal all check out. The "Production considerations" section is a good touch, especially calling out that a distributed cache can't hold a live connection.

I pushed one commit for preventing shutdown hangs on unanswered elicitations.

Because disposing the registry waits for each session's in-flight operation, a tool call blocked in ElicitationBroker.RequestAsync never completes until a frontend posts a response — so an unanswered elicitation would stall application shutdown until the host's shutdown timeout forced the process down. DELETE /session already avoided this by cancelling the session's pending elicitation first, but nothing covered the shutdown path. The commit adds ElicitationBroker.CancelAll() and wires it to ApplicationStopping, so pending elicitations are released before the singleton registry is disposed.

It also collects progress notifications in a ConcurrentQueue instead of a List, since those are reported from the MCP session's message loop while the request thread serializes the response, plus a test for CancelAll() and a README note on the disposal behavior.

Approving — feel free to push back on any of it if you'd rather handle it differently.

_{This review comment was drafted with AI assistance (GitHub Copilot).}

[luisangelrod]

Thanks @jeffhandley! I reviewed the changes, and they look great to me. I really appreciate you catching that issue, improving the sample, and taking the time to review my contribution.