Out of 7 MCP servers included into a ModelSpecs agent definition and activated, only three are known (partially) by the model

[ThomasKorimort]

What happened?

I have defined my research assistant agent via modelSpecs: in librechat.yaml. For that i choose 7 MCP servers out of the list of my MCP servers, which initialize nicely and provide the tools they should provides as LibreChat v0.8.8-rc3 reports on startup as its last message. But then when i actually ask my research assistant to use any of the MCP servers, it does not know about the majority of them, just about one MCP server with more tools is there upon having the model self-report, which MCP servers it knows and the others are not listed. It seems to be truncated or unwisely selected.

Version Information

v0.8.8-rc3

Steps to Reproduce

1. Define a bunch of MCP servers in librechat.yaml which initialize nicely
2. choose some of them to include in an agent definition in modelSpecs:
3. try to use the agent in the chat interface, making sure the MCP servers are generally tick-marked in the context menu and then also specifically up and running.
4. Ask the model to self-report its MCP servers and it knows only a small part of it, as if most of the definitions are cut off.

What browsers are you seeing the problem on?

Firefox

Relevant log output

...

Screenshots

Code of Conduct

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

[danny-avila]

Self-reporting isn't a reliable check here: models frequently list only a
subset of their tools even when all are available. Could you instead:

1. Open DevTools > Network, and paste the tools array from the
   POST /api/agents/chat/... request payload (redact any URLs/keys).
2. Confirm whether the missing servers appear in the Tools dropdown for
   that agent, not just in the yaml.
3. Share the librechat.yaml modelSpecs block and the startup lines
   listing tools per server.

If the payload contains all 7 servers' tools, the model is misreporting and
there's no truncation. If it doesn't, we have a real bug and that payload
tells us exactly where it's dropped.

[ThomasKorimort]

1. I have only GET listed in the DevTools > Network, no POST and the gets have no payload in the requests.
2. In the chat window there is a button saying e.g. 7 MCP servers. Using the dropdown function of that button it shows clearly tick-marked and initialized the MCP servers chosen for that modelSpecs: name (those modelspecs agents are not listed under agents, they appear in the root layer of the choice menu for models and agents). In the tools menu it happens often that the pin for MCP servers is shown crossed (for being deactivated...). Even i make sure it is uncrossed, the MCP servers are still not seen by the model.

modelSpecs:
enforce: false # Optional: Makes the spec the primary way to interact
prioritize: false
list:
- name: "research-assistant"
label: "Local Research Assistant"
description: "Auto-connected to TMDB, Wikipedia, Zenodo, SearXNG, local files, image generation, RAG and Logic tools."
capabilities: []
webSearch: false
fileSearch: true
preset:
endpoint: "Ollama"
model: "qwen3.6:35b-a3b-q8_0"
temperature: 0.5
top_p: 0.9
min_p: 0.05
presence_penalty: 0
frequency_penalty: 0
repeat_penalty: 0
promptPrefix: |
You are a research assistant equipped with active local MCP tools.
Given the following conversation, relevant context, and a follow up question, reply with an answer to the current question the user is asking.
The current date and time is {{current_datetime}}. Use that time as a basis for all your endeavours.
For all your research provide a list of sources used possibly linked by footnotes in your output text.
When asked to perform a search or retrieve media/files, invoke the appropriate function/tool directly.
You have Read-Only access to the local media library and Documents via the local-media MCP tools. The folder names represent the taxonomy.
Path depth indicates specificity. The names of the path provide some reasonable classification for the content. For eBooks check the path for a general c>
Detailed classification is only available for most books from the metadata inside the book itself. A lot of the books are scans.
For photos the folder structure (YYYY-MM-DD - Description) is the primary metadata along with the metadata in the image files themselves, which might be >
For movies and tv-shows the path shows the name and the year for quick identification with other tools.
Inside most of the folders are nfo files and other metadata files. For audio most files are mp3 with proper tags and album tags also named accordingly an>
For documents and general files, they are nicely kept in folders with indicative names, often including a date and time in the folder and file names.
When you are asked to create an image or a piece of music also display it in the chat after it is generated, if easily possible in its original resolutio>
maxContextTokens: 131072
maxOutputTokens: 32768
thinking_budget: 8192
thinkingLevel: "low"
mcpServers:
- "searxng"
- "tmdb"
- "wikipedia"
- "datetime"
- "local-media"
- "comfyui"
- "zenodo"

20 14:05:05 GMKtec-EVO-X2 npm[4084361]: 2026-09-20 14:05:05 info: [MCP][datetime] Tool list changed; refreshed 4 tools
Sep 20 14:05:05 GMKtec-EVO-X2 npm[4084361]: 2026-09-20 14:05:05 info: [MCP][puppeteer] Tool list changed; refreshed 7 tools
Sep 20 14:05:05 GMKtec-EVO-X2 npm[4084361]: 2026-09-20 14:05:05 info: [MCP][sacred-scriptures] Tool list changed; refreshed 6 tools
Sep 20 14:05:05 GMKtec-EVO-X2 npm[4084361]: 2026-09-20 14:05:05 info: [MCP][zenodo] Tool list changed; refreshed 10 tools
Sep 20 14:05:05 GMKtec-EVO-X2 npm[4084361]: 2026-09-20 14:05:05 info: [MCP][tmdb] Tool list changed; refreshed 3 tools
Sep 20 14:05:05 GMKtec-EVO-X2 npm[4084361]: 2026-09-20 14:05:05 info: [MCP][wikipedia] Tool list changed; refreshed 2 tools
Sep 20 14:05:05 GMKtec-EVO-X2 npm[4084361]: 2026-09-20 14:05:05 info: [MCP][yfinance] Tool list changed; refreshed 18 tools
Sep 20 14:05:05 GMKtec-EVO-X2 npm[4084361]: 2026-09-20 14:05:05 info: [MCP][sanskrit] Tool list changed; refreshed 7 tools
Sep 20 14:05:05 GMKtec-EVO-X2 npm[4084361]: 2026-09-20 14:05:05 info: [MCP][searxng] Tool list changed; refreshed 1 tool
Sep 20 14:05:05 GMKtec-EVO-X2 npm[4084361]: 2026-09-20 14:05:05 info: [MCP][sefaria] Tool list changed; refreshed 4 tools
Sep 20 14:05:05 GMKtec-EVO-X2 npm[4084361]: 2026-09-20 14:05:05 info: [MCP][local-media] Tool list changed; refreshed 14 tools
Sep 20 14:05:05 GMKtec-EVO-X2 npm[4084361]: 2026-09-20 14:05:05 info: [MCP][fred] Tool list changed; refreshed 31 tools
Sep 20 14:05:05 GMKtec-EVO-X2 npm[4084361]: 2026-09-20 14:05:05 info: [MCP][comfyui] Tool list changed; refreshed 17 tools
Sep 20 14:05:06 GMKtec-EVO-X2 npm[4085256]: [4085256] [Remote→Local] 2
Sep 20 14:05:06 GMKtec-EVO-X2 npm[4084361]: 2026-09-20 14:05:06 info: [MCP] Initialized with 14 configured servers and 138 tools.
Sep 20 14:05:06 GMKtec-EVO-X2 npm[4084361]: 2026-09-20 14:05:06 info: OAuth reconnect manager initialized successfully.
Sep 20 14:05:06 GMKtec-EVO-X2 npm[4084361]: 2026-09-20 14:05:06 info: [MCP][tripitaka] Tool list changed; refreshed 14 tools
Sep 20 14:05:06 GMKtec-EVO-X2 npm[4084361]: 2026-09-20 14:05:06 info: [agent-triggers] durable delivery engine started
Sep 20 14:05:06 GMKtec-EVO-X2 npm[4084361]: 2026-09-20 14:05:06 error: [schedules] scheduler NOT started: this process cannot see other replicas' generations. The job store is process-local (Redis is off), but nothing here proves this is the only replica — and the standard server arms the scheduler in EVERY replica. A peer would reconcile runs whose jobs it cannot see, eventually marking a still-running generation interrupted and releasing its capacity, and deletions routed elsewhere could not abort the generation at all. Enable a shared stream store (USE_REDIS_STREAMS), or set SCHEDULES_SINGLE_PROCESS=true to assert this deployment runs exactly one replica. Schedule writes are refused (503) until then.
Sep 20 14:05:06 GMKtec-EVO-X2 npm[4084361]: 2026-09-20 14:05:06 error: [schedules] write routes are PERMANENTLY unavailable in this process: the engine did not arm. Resolve the cause logged above and restart.
Sep 20 14:05:06 GMKtec-EVO-X2 npm[4084361]: 2026-09-20 14:05:06 info: Server readiness checks passing.

Honestly, i think it is a bug.

[ThomasKorimort]

@danny-avila You should be aware, that one part of the problem is the native tool calling problem with ollama. Some modelfiles for ollama simply direct the native calls to the prompt without defining a tool calling scheme. This can differ from model to model and from version to version. It is just a matter of wrapping the model with a proper modelfile for ollama.

[ThomasKorimort]

@danny-avila : my financial analyst just reported that he has 4 MCP servers and 30 tools, whereas there are 7 MCP servers with around 80 tools. It looks like somewhere 30 tools could be a hard-coded limit.

[ThomasKorimort]

@danny-avila i have tried to use agent builder instead of modelSpecs for defining my research assistant and it is the same. The context window shows about 11K space used by MCP servers and tools, which seems to be the capped list of about 30 tools and the model itself does not know any of the other tools. Being not able to use MCP servers, completely spoils the fun of having LibreChat installed.

[ThomasKorimort]

@danny-avila : Ok, 11K of context is about enough for 30 tools, so it is LibreChat capping off the MCP tools and that for good reasons, but then i was right in another idea i had before: that LibreChat would need a prompt engineering system similar to that of SillyTavern, that is aware of context and which actions are possible and thus injects world lore and specialities. In the context of SillyTavern role playing this seems to work reliably to focus on the exact scenario in order to provide e.g. the perfect list of 30 MCP tools necessary for the moment.

When does context confusion happen because of too many MCP tools? Is it possible to have 100 tools let us say with 256K Qwen3.6:35b-a3b on Ollama, or let us say 64K to keep the KV Cache and TTFT small.

Or asked differently: Can a model in a chat be made practically stateless and the conversation being compactified practically at every step in order to inject some clues to the model what scenario it is about to work through and to break down more complicated workflows, e.g. generate and image and then post-edit it or similar.

[ThomasKorimort]

@danny-avila I have talked to Google Gemini about it:

In LibreChat v0.8.8-rc3, registered MCP tool schemas quickly consume the system prompt context budget—hitting roughly 11K tokens for ~30 tools—which hard-caps the total number of active tools a user can attach before reaching internal schema overhead limits. While static schema injection guarantees prefix caching benefits across turns, loading large tool sets upfront creates severe context bloat and degrades performance; adopting Just-In-Time (JIT) dynamic tool routing or suffix-based injection would decouple total available tools from system prompt size, preserving token space and preventing early registration caps.

JIT dynamic tool routing would require to have a prompt compositor, that decomposes the user intent into smaller tasks, which then will be processed in proper sequence (or parallel if applicable), with small tool sets injected at the end of the prompt preserving the fixed part of the prompt in the beginning to have some KV cache hits and low prefill.

[ThomasKorimort]

OK, the alternative approach is "deferred tool loading" ...

[ThomasKorimort]

@danny-avila I just re-built my general research agent with the agent-builder in v0.8.8-rc3 and checked the "deferred tool load" box for all the mcp servers i have, especially for my ComfyUI MCP server and when i asked the agent to draw a painting for me, it sent me an excuse that it is just a text model and gave the prompt for copy and paste instead of making use of the ComfyUI MCP tools.

-> Yes, i really think that there is a serious problem with MCP tool calling in LibreChat. The deferral of tools seems not to work properly and the capping of the number of MCP tools is definitely a killer to any useful application of the chat logic of LibreChat v0.8.8-rc3. Personally, i don't know how exactly the MCP calling mechanism works or how tool deferral would actually work, or for that sake how a prompt compositor would actually be able to provide the proper sequence of actions from the text and choose the proper MCP calls, but looking e.g. at Google Gemini and others, this is a problem that has indeed already been successfully solved (decomposing the user intent).

[ThomasKorimort]

@danny-avila also, the native Web Search tool with firecrawl yields very bad search results, much worse results than what a SearXNG MCP server produces.

[jayblast-spec]

The ~30 tools / ~11K token ceiling you're hitting isn't a tool-count limit, it's a token budget, and it's dominated by argument JSON schemas, not names and descriptions. There's a PR open right now (#16179) from someone who measured their own catalog: 8 servers, 202 tools, 239,613 tokens of tool definitions, and 92.6% of that was argument schemas. One server with 12 tools accounted for 67% of the total, with a single tool's schema running 79,699 tokens on its own. Strip the schemas down to name plus description and the same catalog drops to 17,822 tokens. So your 30-tool ceiling is really "how many schemas fit before the budget runs out," and it moves depending on which servers you pick, which matches what you already suspected.

Deferred loading, the mechanism you'd want, already exists in the codebase. It's not something that needs to be invented. A tool can be marked defer_loading: true, in which case the model gets the tool_search tool plus a name-only listing instead of the full schema, and pulls the schema in on demand when it decides to call that tool. But two things currently limit it, both still open as PRs against dev as of today:

1. It's gated behind a separate "deferred_tools" agent capability. If that capability isn't enabled, no deferral happens and no tool_search tool exists at all, regardless of what you check in the UI. That would explain your ComfyUI case: if the agent never got a tool_search fallback, the model has no way to know the tool exists once its schema is excluded from context, so it correctly reports it's "just a text model" rather than hallucinating a tool it can't see.

2. Today, deferral is set per tool, by hand, on saved agents that carry tool_options. There's no server-level default yet (🦥 feat: Server-Level deferLoading Default for MCP Servers #13951, open) and no automatic-by-schema-size rule yet (Defer Oversized MCP Tool Schemas by Size #16179, open, the one with the numbers above). Until one of those lands, the only way to defer an expensive server's tools is to open the agent and toggle each one individually, and an ephemeral agent (plain model plus an attached MCP server, no saved tool_options) can't defer at all yet, which 🦥 feat: Server-Level deferLoading Default for MCP Servers #13951 specifically calls out as the gap it closes.

So the architecture you were describing from the Gemini conversation, name and description now, schema fetched just-in-time, is exactly what defer_loading already does. What's missing in your setup is most likely the capability flag being off, plus there's currently no way to apply deferral without hand-curating tools one at a time. Worth checking whether the deferred_tools capability is enabled for your agent first, since that alone might unblock the ComfyUI case before either PR merges.

[ThomasKorimort]

In the Agent Builder of v0.8.8-rc3 there is no option to switch on deferred tool requests generally. There is only on a per tool basis and on a per-MCP basis a deferred tool switch, which seem to be without function upon being toggled.