Request for Sample: ASP.NET Core MCP Client with One Persisted Connection Per User Session

[Vijay-Nirmal]

Request

Please create an official sample demonstrating how to implement an ASP.NET Core Web API that acts as an MCP client and maintains a persisted MCP connection per user per session. This sample should address:

• Managing unique MCP connections per user session (not as a server)
• Connection persistence & cleanup strategy
• Handling concurrency and avoiding message interleaving
• Support for critical MCP features (Elicitation, Tasks, Progress streams, etc.) that require a stable client↔server session

Why

Features like Elicitation, Tasks, and Progress in MCP require a long-lived, stable client-to-server session, which isn’t covered in the current samples (existing samples are either server-side or single-user/console apps). A sample showing this pattern will help teams implement full MCP compatibility in scalable web API scenarios.

If my assumption on the need for one connection per user per session is incorrect for these features, please clarify the recommended approach for handling MCP features that require stateful communication.

[PederHP]

You can use these features without long-lived connections. A server is allowed to stream sample, elicitation, etc. requests in response to any request (before the actual response). It SHOULD be related to the open request, but how that's defined is up to the server.

That being said, more bidirectionality and session focused samples aren't a bad idea.

[Vijay-Nirmal]

@PederHP Without long lived connections how can we implement Elicitation, where user have to provide input from frontend application?

[PederHP]

@PederHP Without long lived connections how can we implement Elicitation, where user have to provide input from frontend application?

Well, on the server side you cannot rely on the client keeping a connection open. It's optional if clients want to do that and if so, for how long.

You will also find that it's a significant drain on networking resources if you have a very large number of clients that keep a GET stream open permanently. You can find yourself resource exhausted with very low memory and cpu utilization, leading to undesirable scaling properties.

Networking infrastructure such as load balancers also don't play nice with long-lived connections. That being said, long-lived GET streams are part of the spec and there are things you can't implement without them.

But, if designing a server for use with arbitrary clients, you should scope your elicitation and sampling within an ongoing tool call or (rarely) resource read. This should allow the POST request stream to carry the requests to the client. I must admit that I am not 100 percent sure how robust the support is, but I will check up on it. It should be solid.

If you have an entirely internal ecosystem, where you write both client and server, and control networking infrastructure, things are different. In that case you know server side, what to expect from the client.

[Vijay-Nirmal]

If you have an entirely internal ecosystem, where you write both client and server, and control networking infrastructure, things are different. In that case, you know server-side, what to expect from the client.

@PederHP This is my case, I control the MCP Server and the Client

Sounds like elicitation may not be the write way to get user input from the frontend, at least in the current state of MCP. I would assume that we need some sort of checkpoint/rehydration mechanism in MCP to have a reliable elicitation implementation in Production.

Correct me if my understanding is wrong, and a sample with the current recommended approach to use elicitation in the Web API MCP Client app would be much appreciated.

[PederHP]

If you have an entirely internal ecosystem, where you write both client and server, and control networking infrastructure, things are different. In that case, you know server-side, what to expect from the client.

@PederHP This is my case, I control the MCP Server and the Client

Sounds like elicitation may not be the write way to get user input from the frontend, at least in the current state of MCP. I would assume that we need some sort of checkpoint/rehydration mechanism in MCP to have a reliable elicitation implementation in Production.

Correct me if my understanding is wrong, and a sample with the current recommended approach to use elicitation in the Web API MCP Client app would be much appreciated.

Without knowing about your use case in detail, I think Elicitation might be the way if you control both ends and can ensure that the networking infrastructure doesn't constantly disconnect your GET stream. You also need to be sure the scaling works out correctly, but if you control both ends, then you can do some polling based GET streams to avoid resource depletion on the server side if you need heavy scaling (ie many clients per server). If you don't then just keep the GET streams open and use them for unscoped Elicitations (which contrary to what some think are perfectly valid and allowed by the spec - if the client and server has a way to achieve resilient bidirectionality).

I'll see what I can do about adding more samples for Elicitation in the new year, with the caveat that the Microsoft crew has to say ok to them. You are right it would be great to have more samples, and Elicitation does have a number of gnarly use cases, so it makes good sense to have a number of scenarios illustrated via samples.