How to use an MCP server for multiple logged in users?

[Marcel0024]

Pre-submission Checklist

• I have verified that this discussion would not be more appropriate as an issue in a specific repository
• I have searched existing discussions to avoid duplicates

Discussion Topic

My scenario currently is a web based chat application for multiple logged in users. I want an MCP server with authentication of course, and able to identify the users on the MCP server. (I own both chat app and MCP Server)

Currently i see two viable options

• Should I reuse one IMCPClient for all of the users? Then i won't have a PAT at handshake and i don't see how i can change the headers during runtime per user, if i want to add a token per request.
• Should I manage an IMCPClient for each of the active users? How would that even look like a singleton that holds all active mcp clients? Also then need to keep track when user leaves the chat page.

[PederHP]

There are multiple ways to do this. If you control both backend (which in this case is the MCP Client Host) and the MCP Server, you don't necessarily need to do user-based auth on connecting to the MCP Server, especially if you can control ingress to the MCP Server. But you can still do auth from client host to server.

Where does the PAT you need to pass to the server come from? You have already auth'ed the user in your backend, so you should know their claims and whatever else data you have for them. So if the MCP Server does all 1st party operations, you should have everything available inside your architecture.

You can't change the headers after connecting - so if you need per-user headers, you need one connection per user - that's one Client per user, but that's ok. An MCP Client Host is often just called a Client (like in "VS Code is an MCP Client"), but that's imprecise, because a Client represents a connection to a Server, not the entire scope of the host. So don't think of IMcpClient as representing your chat backend - or even your user. It's your connection to the MCP Server. And if that server needs per user auth or additional headers? Having one IMcpClient per user is no different than if it was the user connecting to the same MCP Server directly from their frontend.

You can let the clients time out and create new ones when needed. Reconnecting is not necessarily a problem. Depending on your application you could even keep the IMcpClient alive only during processing of a single user request against your backend. (Ie they send a message and you fire up an IMcpClient for each Server they use, then process their message in the backend, and dispose the clients). Experiment with it. But don't be afraid of creating multiple client connections. That's a perfectly valid pattern. And sometimes the only way to do things when dealing with a need for auth and/or headers.