[GH-ISSUE #1484] [Bug] Moonshot clients reject every request while REA is connected: advertised tool schemas exceed the per-schema size cap (kimi-cli unusable) #500

New issue

Closed

opened 2026-10-15 18:25:37 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-15 18:25:37 +00:00

Owner

Originally created by @haythemsellami on GitHub (Oct 10, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1484

Describe the bug

Connecting REA's MCP server to Moonshot-backed clients (kimi-cli / kimi-for-coding, and any client that forwards every advertised tool on every request) fails every model request with a 400 before any prompt is processed:

Error: [provider.api_error] 400 tools.function.parameters is not a valid moonshot flavored json schema,
details: <At path 'root': schema exceeds maximum allowed size>

The Moonshot API enforces a hard maximum size on each tool's serialized function.parameters JSON Schema (not on the tool count). kimi-cli registers user-scope MCP servers in ~/.kimi-code/mcp.json, forwards the complete tools/list payload in every request, and one oversized schema rejects the entire request — so the client becomes unusable while REA is connected, even for unrelated prompts.

Reproduction

Install kimi-cli (Moonshot's coding CLI) and sign in.

Register REA as a user-scope MCP server (this is what the agent itself writes today, since kimi-cli is not a supported setup client):

// ~/.kimi-code/mcp.json
{ "mcpServers": { "rea": { "command": "npx", "args": ["-y", "rea-agents@6.3.0", "mcp"] } } }

Start kimi-cli and send any prompt. Every turn fails with the 400 above; removing the REA entry restores the client.

Measurements

Live tools/list from rea-agents@6.3.0 (stdio, initialize + tools/list, compact UTF-8 byte counts):

Measurement	Value
Tools advertised	139
Complete tool definitions	1,870,420 bytes
Tools whose `inputSchema` exceeds ~14 KB	44
Largest single `inputSchema` (`compare_web_captures`)	87,390 bytes

Presentation-only compaction simulated on the captured catalog:

Transform	Total `inputSchema` bytes	Tools still over ~14 KB
As served	~1.87 MB	44
Strip nested `description`/`examples`/`default`/`title`	316,943	3
Strip, then dedup repeated subtrees into `$defs`/`$ref`	257,975	3

Nested annotation prose is ~86% of the advertised payload. Three tools remain over the cap for structural reasons: compare_web_captures (~45 KB stripped; its before/after inputs mirror complete inspect_web_page/capture_browser_scenario results in single-use definitions), evaluate_reconstruction_coverage, and build_reconstruction_obligation_ledger.

External constraint evidence

Moonshot's per-schema size cap is undocumented, but third parties have measured it:

MoonshotAI/kimi-cli#2475 — same error with other MCP servers; Claude/Codex accept the same servers.
Leechael/pi-provider-kimi-code#16 — a ~15 KB deduplicated schema still rejected; PR #25 compacts schemas via $defs/$ref dedup and observes Moonshot validates the literal serialized bytes without expanding $ref (a 24 KB → 13.7 KB reduction passes).
MoonshotAI/kimi-code#1610 — 255 tools were accepted once schemas were valid, so the constraint is per-schema size, not tool count.

Expected behavior

An opt-in advertised-input-schema presentation for size-capped providers that keeps the canonical catalog, tool set, output schemas, and server-side canonical validation unchanged, while rendering every advertised inputSchema under the measured cap — default discovery unchanged.

Environment

rea-agents 6.3.0 (npx), macOS 15 (darwin 25.6.0, arm64)
kimi-cli (kimi-code) with a Moonshot coding subscription
Related REA issues: #919 (provider schema compatibility profile), #723 (discovery payload design), #1329/#1282 (strict-validator schema validity)

Originally created by @haythemsellami on GitHub (Oct 10, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1484 ### Describe the bug Connecting REA's MCP server to Moonshot-backed clients (kimi-cli / kimi-for-coding, and any client that forwards every advertised tool on every request) fails every model request with a 400 before any prompt is processed: ``` Error: [provider.api_error] 400 tools.function.parameters is not a valid moonshot flavored json schema, details: <At path 'root': schema exceeds maximum allowed size> ``` The Moonshot API enforces a hard maximum size on each tool's serialized `function.parameters` JSON Schema (not on the tool count). kimi-cli registers user-scope MCP servers in `~/.kimi-code/mcp.json`, forwards the complete `tools/list` payload in every request, and one oversized schema rejects the entire request — so the client becomes unusable while REA is connected, even for unrelated prompts. ### Reproduction 1. Install kimi-cli (Moonshot's coding CLI) and sign in. 2. Register REA as a user-scope MCP server (this is what the agent itself writes today, since kimi-cli is not a supported setup client): ```json // ~/.kimi-code/mcp.json { "mcpServers": { "rea": { "command": "npx", "args": ["-y", "rea-agents@6.3.0", "mcp"] } } } ``` 3. Start kimi-cli and send any prompt. Every turn fails with the 400 above; removing the REA entry restores the client. ### Measurements Live `tools/list` from `rea-agents@6.3.0` (stdio, initialize + tools/list, compact UTF-8 byte counts): | Measurement | Value | | --- | ---: | | Tools advertised | 139 | | Complete tool definitions | 1,870,420 bytes | | Tools whose `inputSchema` exceeds ~14 KB | 44 | | Largest single `inputSchema` (`compare_web_captures`) | 87,390 bytes | Presentation-only compaction simulated on the captured catalog: | Transform | Total `inputSchema` bytes | Tools still over ~14 KB | | --- | ---: | ---: | | As served | ~1.87 MB | 44 | | Strip nested `description`/`examples`/`default`/`title` | 316,943 | 3 | | Strip, then dedup repeated subtrees into `$defs`/`$ref` | 257,975 | 3 | Nested annotation prose is ~86% of the advertised payload. Three tools remain over the cap for structural reasons: `compare_web_captures` (~45 KB stripped; its `before`/`after` inputs mirror complete `inspect_web_page`/`capture_browser_scenario` results in single-use definitions), `evaluate_reconstruction_coverage`, and `build_reconstruction_obligation_ledger`. ### External constraint evidence Moonshot's per-schema size cap is undocumented, but third parties have measured it: - [MoonshotAI/kimi-cli#2475](https://github.com/MoonshotAI/kimi-cli/issues/2475) — same error with other MCP servers; Claude/Codex accept the same servers. - [Leechael/pi-provider-kimi-code#16](https://github.com/Leechael/pi-provider-kimi-code/issues/16) — a ~15 KB deduplicated schema still rejected; [PR #25](https://github.com/Leechael/pi-provider-kimi-code/pull/25) compacts schemas via `$defs`/`$ref` dedup and observes Moonshot validates the literal serialized bytes without expanding `$ref` (a 24 KB → 13.7 KB reduction passes). - [MoonshotAI/kimi-code#1610](https://github.com/MoonshotAI/kimi-code/issues/1610) — 255 tools were accepted once schemas were valid, so the constraint is per-schema size, not tool count. ### Expected behavior An opt-in advertised-input-schema presentation for size-capped providers that keeps the canonical catalog, tool set, output schemas, and server-side canonical validation unchanged, while rendering every advertised `inputSchema` under the measured cap — default discovery unchanged. ### Environment - rea-agents 6.3.0 (npx), macOS 15 (darwin 25.6.0, arm64) - kimi-cli (kimi-code) with a Moonshot coding subscription - Related REA issues: #919 (provider schema compatibility profile), #723 (discovery payload design), #1329/#1282 (strict-validator schema validity)

bsakaguchi

2026-10-15 18:25:37 +00:00

closed this issue
added the
area: mcp

triage

bug
labels

bsakaguchi commented

2026-10-15 18:25:39 +00:00

Author

Owner

@ylwl1997 commented on GitHub (Oct 10, 2026):

Thanks for the careful measurements — the per-schema size numbers (especially nested annotation prose dominating the catalog) make this much easier to triage than a bare 400.

Operator checklist while waiting on an upstream presentation/compaction profile:

Confirm the failure class. The error is per-tool function.parameters serialized size, not tool count. If removing only REA restores kimi-cli, you have the right root cause.
Measure your live catalog. Capture tools/list for the exact rea-agents version you pin and note which inputSchemas exceed ~14 KB. Your table already shows compare_web_captures and a few reconstruction tools as structural outliers even after description stripping.
Client routing. Prefer a client that tolerates large catalogs (or run heavy REA jobs via CLI) for day-to-day work; keep Moonshot/kimi for prompts that do not need the full REA tool surface until a compact advertisement path exists.
Do not “fix” the cap by hand-editing malformed schemas — that breaks server-side validation and is worse than a clean disconnect. Track related design threads (#919 / #723 / #1329) for an opt-in compact presentation that keeps canonical validation intact.
Pin versions deliberately. Schema shape drifts between releases; if you bisect, record both the REA version and the exact Moonshot error string.

Happy to refine measurements if maintainers want a minimal repro tool list that still trips the cap.

Disclosure: I maintain rea.run, an independent bilingual docs/FAQ site about lawful coding-agent reverse engineering. Not affiliated with the REA project.

@ylwl1997 commented on GitHub (Oct 10, 2026): Thanks for the careful measurements — the per-schema size numbers (especially nested annotation prose dominating the catalog) make this much easier to triage than a bare 400. **Operator checklist while waiting on an upstream presentation/compaction profile:** 1. **Confirm the failure class.** The error is per-tool `function.parameters` serialized size, not tool count. If removing only REA restores kimi-cli, you have the right root cause. 2. **Measure your live catalog.** Capture `tools/list` for the exact `rea-agents` version you pin and note which `inputSchema`s exceed ~14 KB. Your table already shows `compare_web_captures` and a few reconstruction tools as structural outliers even after description stripping. 3. **Client routing.** Prefer a client that tolerates large catalogs (or run heavy REA jobs via CLI) for day-to-day work; keep Moonshot/kimi for prompts that do not need the full REA tool surface until a compact advertisement path exists. 4. **Do not “fix” the cap** by hand-editing malformed schemas — that breaks server-side validation and is worse than a clean disconnect. Track related design threads (#919 / #723 / #1329) for an opt-in compact presentation that keeps canonical validation intact. 5. **Pin versions deliberately.** Schema shape drifts between releases; if you bisect, record both the REA version and the exact Moonshot error string. Happy to refine measurements if maintainers want a minimal repro tool list that still trips the cap. Disclosure: I maintain [rea.run](https://rea.run/faq/mcp-schema-size/), an independent bilingual docs/FAQ site about lawful coding-agent reverse engineering. Not affiliated with the REA project.

bsakaguchi referenced this issue

2026-10-15 18:28:32 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi referenced this issue

2026-10-16 21:13:30 +00:00

[PR #500] [MERGED] feat(native): add inspection primitives, dispatch traces and approved UI observation #2028