[Bug]: MCP tools become unavailable when multiple servers are enabled together

[cfs603]

What happened?

When multiple MCP servers are enabled together for a single conversation,
one server's tools become completely unavailable to the model, even though
that same server works correctly when enabled alone. The model reports the
tool as "not available" / "not in the provided list of tools" and never
attempts to call it, despite the server being connected and healthy
(confirmed via server logs showing successful tool discovery at the exact
time of the failed request).

Reproduced consistently across multiple fresh conversations, fresh browser
sessions, and after full container recreation (docker compose up -d
--force-recreate), ruling out session or cache staleness as the cause.

Version Information

LibreChat version: v0.8.8-rc1
Commit: eaef87f
Branch: main
Build date: 2026-08-14 07:28:58 UTC
User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/153.0.0.0 Safari/537.36

Steps to Reproduce

1. Configure two MCP servers in librechat.yaml (streamable-http transport,
   requiresOAuth: false): a small server exposing 3 tools, and a larger
   one (github MCP server) exposing 26 tools
2. Start a new chat using a custom Ollama endpoint model (tested with
   qwen3-vl:8b-instruct)
3. In the MCP Servers selector, enable ONLY the small server
4. Prompt the model to use one of that server's tools -> works correctly,
   tool is called and returns results
5. Start a new chat, enable BOTH the small server and the github server
   together in the MCP Servers selector
6. Send the identical prompt -> model reports the small server's tool is
   "not available" and does not attempt to call it

What browsers are you seeing the problem on?

Chrome

Relevant log output

Both servers confirmed healthy via container logs at time of testing:

[MCP][drive] Tools: list_files, read_file, search_files
[MCP][drive] Initialized in: 44ms
[MCP][github] Tool list changed; refreshed 26 tools
[MCP] Initialized with 3 configured servers and 40 tools.
Server readiness checks passing.

No errors logged at the time of the failed request with both servers
enabled; the model simply reports the tool as unavailable.

Environment: Docker Compose, self-hosted. Model: qwen3-vl:8b-instruct via
custom Ollama endpoint (baseURL: http://host.docker.internal:11434/v1/).
drive: self-hosted MCP server, 3 tools. github: official github MCP
server, 26 tools, Bearer token auth.

Screenshots

Code of Conduct

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

[cfs603]

Update: further testing shows this is broader than originally reported.
The same failure occurs even with only ONE MCP server (the 3-tool "drive"
server) attached to a saved Agent, no other MCP servers enabled at all.
The identical model, server, and prompt work correctly in a plain chat
(model picked directly, MCP Servers selector, no Agent involved) but fail
consistently when run through a saved Agent with the same single server
attached.

This suggests Agents may use a different code path for MCP tool
injection than plain chat (a "ResumableAgentController" reference appears
in server logs specifically during Agent-based failures), separate from
the original multi-server issue described above. Both reproduce
reliably; they may be related or may be two distinct bugs.

Further isolated: this reproduces with a SINGLE MCP server attached to a
saved Agent (no other servers enabled at all), ruling out the multi-server
interaction as the sole cause.

• Plain chat, model picked directly from dropdown, MCP Servers selector,
  "drive" (3 tools) enabled alone -> works correctly every time
• Same model, same single "drive" server attached to a saved Agent
  (Agent Builder Tools list shows "drive · 3") -> fails every time with
  "The search_files tool is not available in the provided set of tools"

Also ruled out as causes during this investigation:

• MCP server health/connectivity (confirmed healthy via logs at time of
  every failed attempt)
• Session/auth staleness (reproduced across full logout/login cycles and
  full container recreation via docker compose up -d --force-recreate)
• Browser/domain mismatch (reproduced on the correct canonical domain in
  a fresh browser session)
• Credential/encryption fingerprint drift (reproduced after clearing and
  regenerating the librechatCredentialMetadata record)

This strongly points to Agents using a different code path than plain
chat for attaching MCP tool context to the model request, one that is
failing to include the tools even when the underlying MCP connection is
healthy and the same tools work correctly outside an Agent.

[daviddiviny]

Is this possibly related to #15292 @danny-avila