morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 07:47:29 +00:00

[GH-ISSUE #3654] [Bug] Default MCP catalog fails every Kimi Code prompt on Moonshot models (per-tool `parameters` schema cap) #1373

New issue

Closed

opened 2026-10-16 21:04:47 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-16 21:04:47 +00:00

Owner

Originally created by @Sicaduj on GitHub (Oct 14, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/3654

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

MCP or agent integration

Observed behavior

With REA registered as an MCP server in Kimi Code, every prompt fails on Kimi
models (k3, k3-256k), including prompts that never call a REA tool. Other
models in the same CLI (DeepSeek, Xiaomi) work, so the failure depends only on
the attached tool catalog.

Exact error, every time:

Model request failed — this turn was interrupted
400 tools.function.parameters is not a valid moonshot flavored json schema, details: <At path 'root': schema exceeds maximum allowed size>
provider.api_error · HTTP 400

The registration was written for Kimi Code without any input-schema profile, so
the server advertised its default (full) catalog. Measuring the advertised
catalog directly (no model API involved) with initialize + tools/list over
stdio JSON-RPC against the same server/spawn environment:

advertised profile	tools	max `parameters` schema	tools > 13 KiB	tools > 15 KB	total `inputSchema` bytes
default (`full`)	207	154,738 B (`compare_web_captures`)	18	12	688,973 B
`REA_MCP_INPUT_SCHEMA_PROFILE=compact`	207	3,520 B	0	0	83,432 B

REA's own recorded measurements for this provider cap are ~13.7 KB accepted /
~15 KB rejected (src/config/mcpInputSchemaProfile.ts:6-11), so the default
advertisement cannot be accepted by the client's own models.

Reproduction

Register REA for Kimi Code — either by rea setup --client kimi (which
selects no input-schema profile) or by hand with the same shape — in
~/.kimi-code/mcp.json:

{
  "mcpServers": {
    "rea": {
      "command": "<node.exe>",
      "args": ["<checkout>/scripts/rea.mjs", "mcp"],
      "env": {
        "REA_ANALYSIS_PROVIDER": "ghidra",
        "GHIDRA_INSTALL_DIR": "<ghidra dir>",
        "JAVA_HOME": "<jdk dir>"
      },
      "startupTimeoutMs": 60000,
      "toolTimeoutMs": 600000
    }
  }
}

Start a new Kimi Code session and select a Kimi model (k3 or k3-256k).
Send any prompt, e.g. hi. It fails with the 400 above.
Frequency: every prompt attempted failed (no successful prompt observed);
no target opened and no REA tool invoked.
Measure the advertised catalog without a model API — spawn the same server
and print Buffer.byteLength(JSON.stringify(tool.inputSchema)) for
tools/list (initialize → notifications/initialized → tools/list).
Result: the table under Observed behavior.
Control: add "REA_MCP_INPUT_SCHEMA_PROFILE": "compact" to that env,
restart the session — prompts succeed, and the same probe reports max
3,520 B with 0 tools over the budget.

Expected behavior

REA already documents this exact failure and its mitigation:
docs/mcp-contracts.md → Compact input schema profile states that "Moonshot
clients such as kimi-cli fail every request while the default catalog is
attached (#1484)" and that REA_MCP_INPUT_SCHEMA_PROFILE=compact renders every
advertised schema within a 13,312-byte budget. rea setup --client kimi writes
the registration for the client whose models are Moonshot's, but selects no
profile, so the documented-for-Kimi failure is the default outcome. Expected:
a registration written by setup for Kimi Code is usable with that client's own
models (or setup/doctor surfaces the conflict), and rea doctor --client kimi
does not report such a registration as healthy while no request can succeed.
Unverified expectation: I did not test other Kimi Code releases or other
size-capped gateways.

Impact and scope

100% failure on Kimi models in Kimi Code while REA is registered; not limited
to REA workflows — the catalog is attached to unrelated prompts.
No REA-side signal: REA never sees the rejected request, so nothing appears in
REA logs or results. The only output is the provider 400, which reads like a
client/model fault and is otherwise indistinguishable from a Kimi-side
regression.
No effect on evidence integrity, provider isolation, or cleanup: no target is
opened and no tool executes. Other models in the same CLI and clients that do
not enforce the cap are unaffected.
Untested scope, left unknown: macOS/Linux hosts, other Kimi Code versions,
other size-capped gateways (WorkBuddy/CodeBuddy, see #2999).

REA version

rea --version → 6.5.0; source revision 3b79af28e (main, workspace build launched through scripts/rea.mjs mcp).

Runtime and platform

Node.js 24.20.0 (npm 11.19.0); Windows 11 x64; Kimi Code CLI 2.2.0 as the MCP host. Ghidra 12.1.4 is configured (REA_ANALYSIS_PROVIDER=ghidra), but no provider was involved in the failure.

Target and artifact context

Not applicable — the request is rejected before any tool call, with no target opened.

Interface

MCP

Earliest failure stage

Request parsing or validation

Relevant output or evidence

Command / request actually run:

<node> <checkout>/scripts/rea.mjs mcp      # spawned as the Kimi Code registration does
→ initialize (clientInfo kimi-code) → notifications/initialized → tools/list

Relevant result, error, or artifact:

Provider error (every prompt attempted): 400 tools.function.parameters is not a valid moonshot flavored json schema, details: <At path 'root': schema exceeds maximum allowed size>.
Advertised-size table above; largest offenders under the default profile:
compare_web_captures 154,738 B; compare_application_versions 28,495 B;
evaluate_reconstruction_coverage 24,267 B; inspect_analysis_view 21,691 B;
project_managed_application_graph 20,871 B;
build_reconstruction_obligation_ledger 20,742 B. 12 tools exceed 15 KB.
rea doctor --client kimi against that registration reported state stale
(for its custom startupTimeoutMs/toolTimeoutMs) and reported nothing about
the advertised schema profile.

Source reference for the missing default: src/application/SetupClientConfiguration.ts
(the client.name === "kimi" branch) adds only startup/tool timeouts and
provider environment; the profile setting is never written for any client.

Missing evidence or remaining uncertainty: the last known good and first known
bad REA versions are NOT_ENOUGH_INFO — see Additional context.

Typed outcome or recovery expected

A Kimi Code registration should advertise a catalog the client's models accept,
or the mismatch should be reportable from REA. Ideally rea doctor /
rea mcp doctor also reports the active input-schema profile, the largest
advertised schema, and the tools above the provider cap, so an opaque provider
400 becomes a named REA-side cause instead of an unexplained turn interruption.

Analysis or suspected cause

Source-derived, grounded in REA's own recorded evidence:

The provider rejects a request while any single tool parameters schema
exceeds a literal serialized size cap; REA records ~13.7 KB accepted / ~15 KB
rejected (src/config/mcpInputSchemaProfile.ts:6-11,
docs/mcp-contracts.md → Compact input schema profile).
The default advertisement exceeds that for 18 of 207 tools, so every request
is rejected before REA participates. Hypothesis for the trigger: whichever
release introduced the largest contracts (their git log dates span
2026-07-14 … 2026-10-13) pushed the catalog past the cap; I did not test a
known-good revision, so this is a hypothesis, not an observation.
REA already ships the mitigation (REA_MCP_INPUT_SCHEMA_PROFILE=compact,
#1514/#1580), but it is opt-in, full remains the documented default, and
only the Claude Code and Copilot sections of docs/client-configuration.md
tell users to add it — the Kimi Code section does not. Proposal (a maintainer
decision, not a required fix): register compact for Kimi Code unless the
caller already selected a profile, since Kimi Code's models are Moonshot's.
Diagnostic gap: registrationAligned
(src/application/ClientRegistrationStatus.ts) validates command identity,
transport and timeouts but not env values, and the environment map is only
validated as a string record, so a Kimi Code registration that omits the
profile is reported as aligned/healthy.

Additional context

Related issues: #1484 (measured cap evidence), #1580, #1514 (compact input
schema profile), #2999 (WorkBuddy/CodeBuddy gateway 11133).

Regression boundary: last known good versions is
6.0. The reporter noticed the failure after a recent REA update;
the catalog is now 207 tools / 688,973 B of input schemas, while
docs/client-configuration.md records an earlier measurement of 172 tools /
~496 KB at revision 04089d5be.

Workaround applied locally (not a tested fix): adding
"REA_MCP_INPUT_SCHEMA_PROFILE": "compact" to the existing registration's env
by hand, rather than re-running rea setup --client kimi, because setup also
normalizes that registration's custom timeouts (startupTimeoutMs 60000 → 30000
and toolTimeoutMs 600000 → 120000, compared against MCP_STARTUP_POLICY in
registrationAligned).

Originally created by @Sicaduj on GitHub (Oct 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3654 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area MCP or agent integration ### Observed behavior With REA registered as an MCP server in Kimi Code, **every** prompt fails on Kimi models (`k3`, `k3-256k`), including prompts that never call a REA tool. Other models in the same CLI (DeepSeek, Xiaomi) work, so the failure depends only on the attached tool catalog. Exact error, every time: ``` Model request failed — this turn was interrupted 400 tools.function.parameters is not a valid moonshot flavored json schema, details: <At path 'root': schema exceeds maximum allowed size> provider.api_error · HTTP 400 ``` The registration was written for Kimi Code without any input-schema profile, so the server advertised its default (`full`) catalog. Measuring the advertised catalog directly (no model API involved) with `initialize` + `tools/list` over stdio JSON-RPC against the same server/spawn environment: | advertised profile | tools | max `parameters` schema | tools > 13 KiB | tools > 15 KB | total `inputSchema` bytes | | ------------------ | ----- | ----------------------- | -------------- | ------------- | ------------------------- | | default (`full`) | 207 | 154,738 B (`compare_web_captures`) | 18 | 12 | 688,973 B | | `REA_MCP_INPUT_SCHEMA_PROFILE=compact` | 207 | 3,520 B | 0 | 0 | 83,432 B | REA's own recorded measurements for this provider cap are ~13.7 KB accepted / ~15 KB rejected (`src/config/mcpInputSchemaProfile.ts:6-11`), so the default advertisement cannot be accepted by the client's own models. ### Reproduction 1. Register REA for Kimi Code — either by `rea setup --client kimi` (which selects no input-schema profile) or by hand with the same shape — in `~/.kimi-code/mcp.json`: ```json { "mcpServers": { "rea": { "command": "<node.exe>", "args": ["<checkout>/scripts/rea.mjs", "mcp"], "env": { "REA_ANALYSIS_PROVIDER": "ghidra", "GHIDRA_INSTALL_DIR": "<ghidra dir>", "JAVA_HOME": "<jdk dir>" }, "startupTimeoutMs": 60000, "toolTimeoutMs": 600000 } } } ``` 2. Start a new Kimi Code session and select a Kimi model (`k3` or `k3-256k`). 3. Send any prompt, e.g. `hi`. It fails with the 400 above. **Frequency: every prompt attempted failed (no successful prompt observed); no target opened and no REA tool invoked.** 4. Measure the advertised catalog without a model API — spawn the same server and print `Buffer.byteLength(JSON.stringify(tool.inputSchema))` for `tools/list` (`initialize` → `notifications/initialized` → `tools/list`). Result: the table under *Observed behavior*. 5. Control: add `"REA_MCP_INPUT_SCHEMA_PROFILE": "compact"` to that `env`, restart the session — prompts succeed, and the same probe reports max 3,520 B with 0 tools over the budget. ### Expected behavior REA already documents this exact failure and its mitigation: `docs/mcp-contracts.md` → *Compact input schema profile* states that "Moonshot clients such as kimi-cli fail every request while the default catalog is attached (#1484)" and that `REA_MCP_INPUT_SCHEMA_PROFILE=compact` renders every advertised schema within a 13,312-byte budget. `rea setup --client kimi` writes the registration for the client whose models are Moonshot's, but selects no profile, so the documented-for-Kimi failure is the default outcome. Expected: a registration written by setup for Kimi Code is usable with that client's own models (or setup/doctor surfaces the conflict), and `rea doctor --client kimi` does not report such a registration as healthy while no request can succeed. Unverified expectation: I did not test other Kimi Code releases or other size-capped gateways. ### Impact and scope - 100% failure on Kimi models in Kimi Code while REA is registered; not limited to REA workflows — the catalog is attached to unrelated prompts. - No REA-side signal: REA never sees the rejected request, so nothing appears in REA logs or results. The only output is the provider 400, which reads like a client/model fault and is otherwise indistinguishable from a Kimi-side regression. - No effect on evidence integrity, provider isolation, or cleanup: no target is opened and no tool executes. Other models in the same CLI and clients that do not enforce the cap are unaffected. - Untested scope, left unknown: macOS/Linux hosts, other Kimi Code versions, other size-capped gateways (WorkBuddy/CodeBuddy, see #2999). ### REA version `rea --version` → `6.5.0`; source revision `3b79af28e` (main, workspace build launched through `scripts/rea.mjs mcp`). ### Runtime and platform Node.js 24.20.0 (npm 11.19.0); Windows 11 x64; Kimi Code CLI 2.2.0 as the MCP host. Ghidra 12.1.4 is configured (`REA_ANALYSIS_PROVIDER=ghidra`), but no provider was involved in the failure. ### Target and artifact context Not applicable — the request is rejected before any tool call, with no target opened. ### Interface MCP ### Earliest failure stage Request parsing or validation ### Relevant output or evidence Command / request actually run: ``` <node> <checkout>/scripts/rea.mjs mcp # spawned as the Kimi Code registration does → initialize (clientInfo kimi-code) → notifications/initialized → tools/list ``` Relevant result, error, or artifact: - Provider error (every prompt attempted): `400 tools.function.parameters is not a valid moonshot flavored json schema, details: <At path 'root': schema exceeds maximum allowed size>`. - Advertised-size table above; largest offenders under the default profile: `compare_web_captures` 154,738 B; `compare_application_versions` 28,495 B; `evaluate_reconstruction_coverage` 24,267 B; `inspect_analysis_view` 21,691 B; `project_managed_application_graph` 20,871 B; `build_reconstruction_obligation_ledger` 20,742 B. 12 tools exceed 15 KB. - `rea doctor --client kimi` against that registration reported state `stale` (for its custom `startupTimeoutMs`/`toolTimeoutMs`) and reported nothing about the advertised schema profile. Source reference for the missing default: `src/application/SetupClientConfiguration.ts` (the `client.name === "kimi"` branch) adds only startup/tool timeouts and provider environment; the profile setting is never written for any client. Missing evidence or remaining uncertainty: the last known good and first known bad REA versions are `NOT_ENOUGH_INFO` — see *Additional context*. ### Typed outcome or recovery expected A Kimi Code registration should advertise a catalog the client's models accept, or the mismatch should be reportable from REA. Ideally `rea doctor` / `rea mcp doctor` also reports the active input-schema profile, the largest advertised schema, and the tools above the provider cap, so an opaque provider 400 becomes a named REA-side cause instead of an unexplained turn interruption. ### Analysis or suspected cause Source-derived, grounded in REA's own recorded evidence: - The provider rejects a request while any single tool `parameters` schema exceeds a literal serialized size cap; REA records ~13.7 KB accepted / ~15 KB rejected (`src/config/mcpInputSchemaProfile.ts:6-11`, `docs/mcp-contracts.md` → *Compact input schema profile*). - The default advertisement exceeds that for 18 of 207 tools, so every request is rejected before REA participates. Hypothesis for the trigger: whichever release introduced the largest contracts (their `git log` dates span 2026-07-14 … 2026-10-13) pushed the catalog past the cap; I did not test a known-good revision, so this is a hypothesis, not an observation. - REA already ships the mitigation (`REA_MCP_INPUT_SCHEMA_PROFILE=compact`, #1514/#1580), but it is opt-in, `full` remains the documented default, and only the Claude Code and Copilot sections of `docs/client-configuration.md` tell users to add it — the Kimi Code section does not. Proposal (a maintainer decision, not a required fix): register `compact` for Kimi Code unless the caller already selected a profile, since Kimi Code's models are Moonshot's. - Diagnostic gap: `registrationAligned` (`src/application/ClientRegistrationStatus.ts`) validates command identity, transport and timeouts but not `env` values, and the environment map is only validated as a string record, so a Kimi Code registration that omits the profile is reported as aligned/healthy. ### Additional context Related issues: #1484 (measured cap evidence), #1580, #1514 (compact input schema profile), #2999 (WorkBuddy/CodeBuddy gateway `11133`). Regression boundary: last known good versions is `6.0`. The reporter noticed the failure after a recent REA update; the catalog is now 207 tools / 688,973 B of input schemas, while `docs/client-configuration.md` records an earlier measurement of 172 tools / ~496 KB at revision `04089d5be`. Workaround applied locally (not a tested fix): adding `"REA_MCP_INPUT_SCHEMA_PROFILE": "compact"` to the existing registration's `env` by hand, rather than re-running `rea setup --client kimi`, because setup also normalizes that registration's custom timeouts (`startupTimeoutMs` 60000 → 30000 and `toolTimeoutMs` 600000 → 120000, compared against `MCP_STARTUP_POLICY` in `registrationAligned`).

bsakaguchi

2026-10-16 21:04:47 +00:00

closed this issue
added the
triage

bug
labels

bsakaguchi commented

2026-10-16 21:04:49 +00:00

Author

Owner

@morluto commented on GitHub (Oct 14, 2026):

Delivered on main in fffb07419.

Kimi setup omitted the compact advertisement already provided for Moonshot schema-size limits. New/refreshed Kimi registrations now select compact when no profile is explicitly stored or supplied; explicit full/compact remains authoritative. Doctor marks omitted-profile Kimi registrations stale, and the Kimi guide explains recovery.

Validation: Public Kimi registration lifecycle/status tests cover defaults, explicit stored choices, override precedence, backups and idempotency. Compact schemas retain canonical server validation and pass dialect/client checks. Live Moonshot behavior is the reported Kimi Code 2.2.0/Windows 11 evidence; no model API was called in this fix. Full exact-revision qualification passed.

@morluto commented on GitHub (Oct 14, 2026): Delivered on main in [fffb07419](https://github.com/morluto/rea/commit/fffb0741936067530d1ce9777461cd53e87398c2). Kimi setup omitted the compact advertisement already provided for Moonshot schema-size limits. New/refreshed Kimi registrations now select compact when no profile is explicitly stored or supplied; explicit full/compact remains authoritative. Doctor marks omitted-profile Kimi registrations stale, and the Kimi guide explains recovery. Validation: Public Kimi registration lifecycle/status tests cover defaults, explicit stored choices, override precedence, backups and idempotency. Compact schemas retain canonical server validation and pass dialect/client checks. Live Moonshot behavior is the reported Kimi Code 2.2.0/Windows 11 evidence; no model API was called in this fix. Full exact-revision [qualification](https://github.com/morluto/rea/actions/runs/38629313022) passed.

bsakaguchi commented

2026-10-16 21:04:49 +00:00

Author

Owner

@nosmile99 commented on GitHub (Oct 14, 2026):

Reproduced the measurements independently via initialize + tools/list over stdio against a local build — they match the issue's table exactly: default profile advertises 207 tools, max inputSchema 154,738 B (compare_web_captures), 18 tools over 13 KiB, 688,971 B total; REA_MCP_INPUT_SCHEMA_PROFILE=compact gives max 3,520 B, 0 over 13 KiB, 83,432 B total. The default catalog cannot be accepted by Moonshot's own models, confirmed.

Fix approach (verified locally): rea setup --client kimi should default REA_MCP_INPUT_SCHEMA_PROFILE=compact in the registration env, without overriding an explicitly configured profile. Implemented in clientConfigurationDesired (src/application/SetupClientConfiguration.ts) — the default applies only when the key is absent, so an explicit "full" in the user's mcp.json is preserved, and other clients are untouched.

Regression test src/application/SetupClientConfiguration.test.ts (3 tests: default-to-compact, explicit-profile-preserved, other-clients-untouched): the key test fails on pre-fix code, 3/3 pass post-fix; related setup suites 59/59 green; typecheck + lint clean.

Branch with the fix + tests: nosmile99/rea@fix/kimi-default-compact-input-schema-3654. Per this repo's human-ownership rule I'm not opening the PR myself — the branch is ready for a human owner to declare and file.

@nosmile99 commented on GitHub (Oct 14, 2026): Reproduced the measurements independently via `initialize` + `tools/list` over stdio against a local build — they match the issue's table exactly: default profile advertises 207 tools, max `inputSchema` 154,738 B (`compare_web_captures`), 18 tools over 13 KiB, 688,971 B total; `REA_MCP_INPUT_SCHEMA_PROFILE=compact` gives max 3,520 B, 0 over 13 KiB, 83,432 B total. The default catalog cannot be accepted by Moonshot's own models, confirmed. Fix approach (verified locally): `rea setup --client kimi` should default `REA_MCP_INPUT_SCHEMA_PROFILE=compact` in the registration `env`, without overriding an explicitly configured profile. Implemented in `clientConfigurationDesired` (`src/application/SetupClientConfiguration.ts`) — the default applies only when the key is absent, so an explicit `"full"` in the user's `mcp.json` is preserved, and other clients are untouched. Regression test `src/application/SetupClientConfiguration.test.ts` (3 tests: default-to-compact, explicit-profile-preserved, other-clients-untouched): the key test fails on pre-fix code, 3/3 pass post-fix; related setup suites 59/59 green; typecheck + lint clean. Branch with the fix + tests: `nosmile99/rea@fix/kimi-default-compact-input-schema-3654`. Per this repo's human-ownership rule I'm not opening the PR myself — the branch is ready for a human owner to declare and file.

bsakaguchi referenced this issue

2026-10-17 21:10:50 +00:00

[PR #1373] [MERGED] fix(mcp): advertise object roots for union input schemas #2835

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#1373

No description provided.

Rows
Columns

[GH-ISSUE #3654] [Bug] Default MCP catalog fails every Kimi Code prompt on Moonshot models (per-tool parameters schema cap) #1373

Before submitting

Area

Observed behavior

Reproduction

Expected behavior

Impact and scope

REA version

Runtime and platform

Target and artifact context

Interface

Earliest failure stage

Relevant output or evidence

Typed outcome or recovery expected

Analysis or suspected cause

Additional context

[GH-ISSUE #3654] [Bug] Default MCP catalog fails every Kimi Code prompt on Moonshot models (per-tool `parameters` schema cap) #1373