Optional limit on MCP tool result size (search_simple can overflow a model's context)

[chagwood]

The problem

Nothing limits how much text an MCP tool returns. search_simple returns every match in every matching file, and Obsidian's simple search matches each query word separately, so a query made of common words over an ordinary vault can come back as megabytes of JSON.

I hit this with Open WebUI 0.11.4 and a local model with a 262,144-token context window. A single search_simple call ("SSH rejects the fleet key", contextLength: 120) returned 9 files and 3,159 matches, about 1.4 MB of JSON (on the order of 350k tokens). That one result was bigger than the model's whole context window. The next request failed with prompt (524094 tokens) leaves no room to answer in the context (262144). Because the result is saved in the chat history, every retry failed the same way, and the conversation was unrecoverable after two user turns.

The client can't handle this today. Open WebUI has no limit on tool output size (open-webui#30110), and its context compaction never runs between tool calls inside a single answer (open-webui#27599). Lowering contextLength doesn't help much either, because the number of matches stays the same.

Proposal

An opt-in Advanced settings → Maximum MCP tool result size (characters) setting, off (0) by default:

• It's applied in McpHandler.text(), so it covers every text-returning MCP tool, including tools that extensions add. The REST API isn't affected.
• An oversized result is cut to fit and followed by a second text block, [Result truncated: ...], giving the original size and suggesting how to narrow the request.
• List results such as searches are cut between items. The most relevant items are kept, and the text stays valid JSON.

I've opened a PR with an implementation, tests, and docs so there's something concrete to look at: #385. I'm happy to rework it, or move it into an extension, if you'd rather take a different direction, for example a per-request limit / maxMatchesPerFile on search_simple instead of a setting, or as well as one.

[coddingtonbear]

Thanks again for such a clear write-up of this, @chagwood! For anybody who finds this later: I went the per-request route instead of a general size limit (I wrote up why over on #385), and that change is in #387.

• Limits: search_simple now takes maxResults, which keeps the highest-scoring files, and maxMatchesPerFile, which keeps the first matches in each file in document order. Over MCP they default to 20 and 10, and contextLength can't go above 500. Your original query would have come back as at most 90 matches across those nine files: a few dozen KB instead of 1.4 MB.
• Saying what was left out: Each result has a totalMatches count. Whenever something was trimmed, a second text block starting [Search results limited: tells the model how much was left out and how to get more. The first block is still the same JSON array.
• REST: POST /search/simple/ takes the same two parameters, but has no limit by default, so existing scripts get the same results they always have.

This will be in the next release, which should be out sometime in the next few days.

[chagwood]

Thanks a ton!