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

[danny-avila]

Thanks for the detailed isolation. I traced both paths, and LibreChat sends the same MCP tool definitions for a saved agent as for the composer's MCP selector. Nothing between your build and current dev changes that, and a server whose tools fail to load raises an explicit error instead of dropping them silently. That leaves two likely causes, and a couple of logs would tell them apart.

1. Ollama's context window (most likely, and it fits both reports). Ollama's OpenAI-compatible /v1 API runs with the server's default context size, which is small, and it silently truncates a prompt that doesn't fit. The GitHub MCP server's 26 tool schemas are large, so enabling it alongside drive can push the tool definitions out of what the model actually sees. A saved agent also adds more to the prompt than a plain chat (instructions, plus any capabilities it has enabled), which could tip even the 3-tool case over the limit. LibreChat can't detect this, because it budgets against its own maxContextTokens, not Ollama's num_ctx.

To test it, raise the context on the Ollama side. librechat.yaml parameters won't reach it through /v1:

• set OLLAMA_CONTEXT_LENGTH=32768 (or larger) on the Ollama server, or
• create a model from a Modelfile with PARAMETER num_ctx 32768

2. "Defer loading" on the agent's tools (saved agent only). In the Agent Builder, open the drive server's tool list and check whether "Defer loading" is on for its tools (or "defer all"). When it is, the model receives only a tool_search tool and must look the real tools up first, which a small model like qwen3-vl 8B usually won't do. It's off by default, so this only applies if it was toggled.

Could you share:

1. The Ollama server log around a failing request. A line like truncating input prompt confirms cause 1.
2. LibreChat debug logs (DEBUG_LOGGING=true) for a failing agent request, specifically any [buildToolClassification] lines.
3. Your Ollama version and whether you've set OLLAMA_CONTEXT_LENGTH / num_ctx anywhere.