[waleedlatif1]

Summary

• A live document is one chunk, so read_document returned the same 8,000-character window whatever limit a client asked for, and clients that asked for more chunks then spent extra calls continuing with startOffset
• For Search MCP reads, a limit above the default (3) now returns a proportionally longer window: limit: 8 returns up to 21,333 characters, and next.startOffset continues from where it ended
• The documents of one call share a 40,000-character budget, measured on the window as the result JSON-encodes it (escaped quotes, backslashes and line breaks count), and each still gets at least the standard 8,000: limit: 8 reads 21,333 for one document, 20,000 each for two, 13,333 for three, 10,000 for four, and 8,000 (today's window) for five or more. A call's result then stays under the 50,000-character size at which MCP clients such as Claude Code save a tool result to a file instead of showing it, and no call returns more per document than it does today once five or more documents are read
• At or below the default, and for every other caller (the Assistant's reads are unchanged), the window stays 8,000 characters
• No tool schema or description changes, so tools/list is byte-identical

Type of Change

• Improvement

Testing

• MCP client bench (Sonnet 5.5, 83 cases, 4 attempts per case per side, paired against this branch's base): continuation reads 25 → 12 (−52%), read calls −10%, no case flipped from mostly right to never right; correct −1.2pp [−5.4, +2.7], completeness −0.9pp, sourceRecall −0.7pp, citedGold 0.0 (every CI spans 0, and all are inside the spread between two runs of the same code: correct −3.6pp); input tokens +2.5k [−5.7, +15.2], also inside the same-code spread (+3.0k to +3.3k); test split flat
• The bench ran the per-document window before the call budget was added; the budget only changes reads of two or more documents at a raised limit (4% of bench reads), moving them toward the base, and the final commit is being re-benched before merge
• New tests in lib/sim-search/live/application.test.ts (a scaling caller above the default limit gets the longer window and continues from its end; one call's documents share the budget at 2, 3 and 4 documents; at or below the default, at five or ten documents, and for a caller that does not scale, the window stays 8,000; a document made entirely of quotes stays within its encoded share and never below 8,000) and lib/knowledge/mcp/server.protocol.test.ts (the MCP adapter opts in with the call's document count, for a single and a batch read); each was seen failing without the change, and each guard (budget, encoded size, 8,000 floor, document count) was reverted and seen failing
• bunx vitest run lib/sim-search/live lib/knowledge/mcp (515 passed), biome on changed files; type-check and audits in CI

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing (new tests pass the test-audit authoring gate)
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
docs	Skipped		Nov 10, 2026 5:02am UTC

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge.

Summary

Search MCP reads can return longer windows when clients request a limit above three.

• Search MCP reads return longer live-document windows when clients ask for more.

_{Reviews (5) · Last reviewed commit: "improvement(search): size a scaled read ..." · Reviewed by Greptile}

[cubic-dev-ai]

No issues found across 4 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Turn on auto-fix | Re-trigger cubic}

[waleedlatif1]

@greptile

[waleedlatif1]

@cubic-dev-ai review this PR

[cubic-dev-ai]

@cubic-dev-ai review this PR

@waleedlatif1 I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

All reported issues were addressed across 4 files

<sub>Reply with feedback, questions, or to request a fix.

Turn on auto-fix | Re-trigger cubic</sub>

[waleedlatif1]

@greptile

[waleedlatif1]

@cubic-dev-ai review this PR

[cubic-dev-ai]

@cubic-dev-ai review this PR

@waleedlatif1 I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

No issues found across 4 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Turn on auto-fix | Re-trigger cubic}

[waleedlatif1]

@greptile

[waleedlatif1]

@cubic-dev-ai review this PR

[cubic-dev-ai]

@cubic-dev-ai review this PR

@waleedlatif1 I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

No issues found across 4 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Turn on auto-fix | Re-trigger cubic}

[waleedlatif1]

@greptile

[waleedlatif1]

@cubic-dev-ai review this PR

[cubic-dev-ai]

@cubic-dev-ai review this PR

@waleedlatif1 I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

No issues found across 4 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Turn on auto-fix | Re-trigger cubic}

[waleedlatif1]

Final bench on this exact head (00432f3) vs its staging base, MCP client bench (Sonnet 5.5, 83 cases, 4 attempts per case per side, pooled):

• continuation reads 11 → 8, read calls 208 → 195, tool calls 2.55 → 2.47 per question, input tokens 52.6k → 51.8k
• largest read response 42,175 chars on both sides; no read response over 50,000 chars
• no case flipped from mostly right to never right (full set and test split)
• correct −1.2pp [−5.1, +2.7], completeness −0.2pp, truthfulness −0.02, sourceRecall −1.5pp [−3.7, +0.5], citedGold −0.3pp: every CI spans 0, and all sit inside the spread between two runs of the same code (correct −2.4pp, completeness −2.6pp, sourceRecall −2.5pp)
• test split sourceRecall −3.3pp [−6.4, −0.7]: the drop is in cases where no read used a scaled window (their reads returned the same 8,000-character window as the base), plus one case whose base got its source 1 of 4 times; the one dev case that lost a source failed in attempts that never made a scaled read

An earlier round on the per-document version (before the call budget and encoded sizing) showed continuation reads 25 → 12 with quality inside the same-code spread.