Repository navigation
[Bug]: MCP tools become unavailable when multiple servers are enabled together #16417
Description
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
- 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 - Start a new chat using a custom Ollama endpoint model (tested with
qwen3-vl:8b-instruct) - In the MCP Servers selector, enable ONLY the small server
- Prompt the model to use one of that server's tools -> works correctly,
tool is called and returns results - Start a new chat, enable BOTH the small server and the github server
together in the MCP Servers selector - 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
Activity
cfs603 commentedon Sep 27, 2026
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.
"drive" (3 tools) enabled alone -> works correctly every time
(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:
every failed attempt)
full container recreation via docker compose up -d --force-recreate)
a fresh browser session)
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 commentedon Sep 27, 2026
Is this possibly related to #15292 @danny-avila
danny-avila commentedon Sep 28, 2026
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
devchanges 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
/v1API 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 alongsidedrivecan 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 ownmaxContextTokens, not Ollama'snum_ctx.To test it, raise the context on the Ollama side.
librechat.yamlparameters won't reach it through/v1:OLLAMA_CONTEXT_LENGTH=32768(or larger) on the Ollama server, orPARAMETER num_ctx 327682. "Defer loading" on the agent's tools (saved agent only). In the Agent Builder, open the
driveserver's tool list and check whether "Defer loading" is on for its tools (or "defer all"). When it is, the model receives only atool_searchtool 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:
truncating input promptconfirms cause 1.DEBUG_LOGGING=true) for a failing agent request, specifically any[buildToolClassification]lines.OLLAMA_CONTEXT_LENGTH/num_ctxanywhere.