[Enhancement]: Multi-user setup with MCP tools for trusted infrastructure setup

[chemeris]

What features would you like to see added?

LibreChat is a multi-user system and has great support for isolating users (OpenAI keys, artifacts, etc) but so far every user shares the same set of MCP tools. In our use case MCP tools provide access to data sources like DBs and have to be user-specific. Or rather MCP tools are common but each user should have their own configuration for each MCP tool.

More details

The MCP specification has a draft for OAuth 2.0 authentication (see a related #5676 feature request), but it is (a) complex and (b) requires MCP servers to be directly exposed to the user's browser.

In our setup, MCP servers are hidden in the internal (trusted) infrastructure, and exposing them to the user would be difficult.

Proposal

Add an ability for LibreChat to send a user name to MCP servers together with a request, so that the MCP server could pull the correct user profile for that specific user.

This has the following benefits:

1. Allow for per-user profiles at MCP tools.
2. Implementation is much simpler both on the LibreChat and MCP server sides.
3. Works well when MCP tools run at the local trusted infrastructure.

Which components are impacted by your request?

General

Pictures

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[danny-avila]

Thanks, I've been thinking about this lately. It seems to make this work, SSE is the standard for multi-user and a transport has to be created per-user. I was planning on implementing this and making the transport session ID the user ID.

modelcontextprotocol/typescript-sdk#158

Also work on this is still developing on Anthropic's side on replacing SSE as the current transport type to go with.

modelcontextprotocol/modelcontextprotocol#206

[chemeris]

Thank you for the links. It's a bit difficult to follow all discussions and developments around MCP :)

Yes, the approach at the first link looks exactly like what I've had in my head. We just need to make sure the user ID is understandable for the MCP server (i.e. maps to a user's email or some other form of ID that can be mapped to external auth). For example in our company we're using AzureAD for all auth where corporate e-mail is the ID.

Support for pure HTTP instead of SSE would be awesome as well. It'll make many things much easier to implement.

[danny-avila]

Reviewing the MCP SDK codebase again, it looks like the server transport assigns the session ID and we can't assign this client-side. However, we can pass headers to the request, which can likely go in the config. We could probably make them dynamic and allow using variables for user ID, email, etc.

Now that some remote MCP options are popping up (composio, zapier), I want to add functionality to add MCP from the UI to agents, so that will benefit from initial refactoring of managing client transports per user.

[danny-avila]

Closing this with: #6610

This is in anticipation of the new Streamable HTTP spec for MCP servers, which will better suit multi-user support for MCP.

https://spec.modelcontextprotocol.io/specification/2025-03-26/basic/transports/#streamable-http

• Introduced multi-user connection support in MCPManager, enabling distinct user-level and app-level connections with proper establishment and cleanup.
  • This helps MCP Servers distinguish mcp connections by session ID
• Extended MCP SSE options processing to support custom headers and substitute {{LIBRECHAT_USER_ID}} if provided:

mcpServers:
  googlesheets:
      headers:
# Header Key ("X-User-ID") is arbitrary, the value ("{{LIBRECHAT_USER_ID}}" ) is not,
# which will be parsed and replaced by the user ID at request
        X-User-ID: "{{LIBRECHAT_USER_ID}}" 
      type: sse
      url: https://mcp.composio.dev/googlesheets/some-endpoint

• Headers can also reference environment variables like so: ${SOME_API_KEY}

[ed-parsadanyan]

I tried this with n8n and unfortunately I couldn't make it work.

Here's my config:

I've initially tried with n8n's MCP trigger, but it returned 403 error and that's why I had to switch to a normal webhook to be able to see the incoming data:

I don't see any of the authorization headers.

When I test via reqbin and provide extra headers, I can see them in the n8n UI.

This makes me think that LibreChat for some reason doesn't work properly.

P.S.
Before writing the comment I git pulled the latest LibreChat repo, and also docker pulled new containers and then restarted everything.

[drpfunk]

I managed to somewhat get around this issue by making sure the n8n MCP Server Trigger had no auth when I start LibreChat. Once LibreChat is started I can put the auth back on the n8n Server Trigger and it works as expected, respecting and using the header auth.

So when it sends the request to n8n the request header is formatted correctly, but perhaps there is an issue during the LibreChat start up when it tries to connect to the n8n MCP Server Trigger and register the tools?

[danny-avila]

I'm tracking the MCP SDK bug that prevents headers from being passed on initial request. This is highlighted along with workarounds here: #7155 (reply in thread)

[holasoygeorgee]

I tried this with n8n and unfortunately I couldn't make it work.

Here's my config:

I've initially tried with n8n's MCP trigger, but it returned 403 error and that's why I had to switch to a normal webhook to be able to see the incoming data:

I don't see any of the authorization headers.

When I test via reqbin and provide extra headers, I can see them in the n8n UI.

This makes me think that LibreChat for some reason doesn't work properly.

P.S. Before writing the comment I git pulled the latest LibreChat repo, and also docker pulled new containers and then restarted everything.

It worked for me with any model this way: the n8n node mcp with authentication, install: npm install -g supergateway and structure the librechat.yaml like this:

mcpServers:
  n8n:
    type: sse
    url: https://
    command: npx
    args:
      - -y
      - supergateway
      - --sse
      - https://
      - --oauth2Bearer
      - "......."