[Enhancement]: "Bring-your-own" Local MCP servers

[leondape]

What features would you like to see added?

I would like to see LibreChat provide a built-in mechanism for seamlessly connecting local MCP servers (or local companion apps) to a centrally deployed LibreChat instance. This feature is crucial for scenarios where a user needs personal, granular access to local resources (e.g., filesystem, Outlook calendar, email) that cannot be exposed to a shared backend server.

A browser-based approach alone can’t directly connect the remote server to localhost. Enabling local MCP servers or companion apps, similar in concept to tools like GetMCP (but free), would let each user securely handle local operations while still benefiting from LibreChat’s LLM capabilities. This mirrors how Claude Desktop manages local file access by running an MCP server on the user’s machine.

More details

Currently, users can only connect MCP servers via the centrally deployed LibreChat backend. There is no straightforward way for the backend to talk to a user’s localhost MCP server.
If we don't find a way to accomplish this we might fall behind dedicated local apps (vs. Web-App) like Claude Desktop.

Which components are impacted by your request?

No response

Pictures

No response

Code of Conduct

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

[danny-avila]

Claude Desktop is actually running MCP servers very similar to LibreChat. The user runs Claude Desktop, and it runs the MCP processes on their machine. You can achieve the same local "capabilities" by running LC locally.

I've renamed the title of your request to match more closely what you're asking as believe you are leaning more towards the local kind of MCP servers.

However, there may not be much more work involved here, if you can use this project in conjunction with LibreChat:
https://github.com/srbhptl39/MCP-SuperAssistant

I will be adding a way to add MCP servers from the UI on a per-user/admin basis, which is a separate but related discussion.

[danny-avila]

Yeah, we can take look at that project I linked for the proxying parts, since that's what it does, it may indeed go overboard with script injection via the extension.

If LibreChat supports user-provided SSE/streamable HTTP MCP servers, then any project that proxies any/all MCP servers into that type would work, provided they are remote-reachable. LC could go one step further and handle some of the interactions from the frontend so your MCP servers don't need to be remote either, but that might be more involved. The former will definitely come before the latter.

[leondape]

I'm not really sure what their proxy does, it bridges their browser extension to local and remote MCP-Servers.

The local (non-remote) reachable part is the most interesting I think. Many ressources are and will only be local, especially when talking about software which can be LLM operated in the future.

For that MCP-SuperAgent is quite useless. It "proxies" from local machine to LLM by typing prompts into the browser via the extension.
If LC could relay local requests to the LC backend that would a real advantage: centrally deployed web-app with possibility to connect with local MCP-Servers. Not sure about the security implications tbh.

[leondape]

any ideas how the local MCP approach could be doable?

I'm thinking about connect local MCPs to the LC Backend?
Or, Step 1 have MCP support for Agents but for every user "bring your own auth"

[emin63]

I think you could do this with something like ngrok. Roughly speaking you could:

1. Locally start an MCP server running on port X.
2. Locally start ngrok and get an ngrok URL that maps to your local MCP server on port X.
3. Do some kind of config in your LibreChat session in the browser to give it the ngrok URL so your browser session can use that URL to contact the locally running MCP server.

It would be cool if LibreChat could automatically do 1 and 2 but that's probably out of scope. I think 3 seems like it could be quite useful, though for lots of applications besides just this question. LibreChat doesn't even need to know it's a locally running (it could be a remote MCP server in the cloud). I think the key feature is for the user to be able to put in a URL for an MCP server in the browser session.

[leondape]

Cool idea! Also sound a little like my companion App Idea. The Companion could handle the local MCP stuff (file permissions etc.) and the ngrok connection.

Though, after thinking a bit, there are very good reasons not to expose local resources to the internet (no matter protected or not).

The alternative, relying on cloud resources, needs to be practical then: Meaning individual user auth per (perhaps predefined) MCP Servers.

[mawburn]

@leondape

So, I just recently got this working for our Shopify instance and we want to open source the parts that aren't LC related and hopefully incorporate it into LC core.

VERY EARLY EXAMPLE

This is a VERY EARLY version of it working in our staging environment. This currently heavily relies on our custom auth we have in place and some other features that aren't fully compatible with upstream. It will also require another tunnel that we will hopefully open source. But this is an example of it talking to my local folders using the example Filesystem MCP server from the MPC repo.

This does not require NGROK, it actually connects to the frontend through a "tunnel" which the frontend acts as a bridge to the backend using the frontend's auth. This way it can better use horizontal scaling in the future. The Tunnel and Web App are authenticated with each other too, so you don't have a random site looking for this on your machine and using it without your permission.

Screen.Recording.2025-08-26.at.3.14.17.PM.1.mov

[danny-avila]

nice job!