morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #2999] [Bug] WorkBuddy/CodeBuddy-backed gateway rejects the whole tool catalog with HTTP 400 code 11133 on the default profile; REA_MCP_INPUT_SCHEMA_PROFILE=compact fixes it #1050

New issue

Closed

opened 2026-10-15 18:30:39 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

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

Owner

Originally created by @Smirk1921 on GitHub (Oct 13, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/2999

Summary

A gateway fronting the WorkBuddy / CodeBuddy backend rejects the entire request with HTTP 400 code 11133 as soon as certain rea tool schemas are present. One offending advertisement takes the whole session's toolset down — the same failure shape as #1327 and #1484, and the same family as #2813 / #2832.

rea-agents@6.4.0 with the default (full) profile still triggers it; REA_MCP_INPUT_SCHEMA_PROFILE=compact fixes it completely (all 184 rea tools and the full 231-tool catalog return 200).

Environment


rea-agents	`6.4.0`, source build, `main` @ `8cbd57c` (358 commits behind `origin/main`)
Node	`v24.x`
Client	ZCode `3.15.1` (SSE, `ai-sdk` transport)
Route	ZCode → local OpenAI-compatible gateway → WorkBuddy/CodeBuddy upstream
Model	`cn:kimi-k3-1` (Kimi-K3; `only_reasoning`, single `medium` effort)
Transport	MCP stdio, non-package-runner registration
Tools in the failing request	231 = 34 client built-in + 12 other MCP server + 184 rea + 1 other

Observed error

HTTP 400
{"code":11133,"msg":"Invalid request parameters",
 "extError":{"code":"400001","message":"the request parameters were rejected by the model provider",
             "param":"","type":"invalid_request_error","StatusCode":400},
 "displayTips":{"en":"This model does not accept the current conversation. It is not a network issue...",
                "zh":"这次对话的内容这个模型不接受，与网络无关..."}}

param is empty — the upstream names no offending field. The gateway then retries across accounts (every account rejects, so it is not account-specific) and surfaces 503. It is not content-related either: the same body with tools removed returns 200, and plain minimal requests to the same model and account return 200. The same 231 tools are also accepted by other models on the same gateway (DeepSeek backends), so the rejection is specific to this backend.

A/B (identical body, only the advertised `tools` differ)

Same messages, tool_choice:"auto", stream:true, reasoning_effort:"max", max_completion_tokens:131072. Both profiles captured from tools/list of the same 6.4.0 build.

#	tools advertised	profile	result
A	all 231 (184 rea)	`full`	400 `11133`
B	184 rea only	`full`	400 `11133`
C	184 rea only	`compact`	200
D	all 231 (184 rea)	`compact`	200

The client's 34 built-in tools and the other MCP server's 12 tools never trigger it. Removing rea from the catalog is sufficient to restore the session.

Per-tool evidence (`full` profile, one rea tool per request, healthy backend pool)

tool                                    inputSchema   $ref   raw depth   result
                                        bytes         count  (JSON tree)
compare_web_captures                       57,360       199      19      REJECTED
correlate_static_and_runtime                9,110        44      12      REJECTED
trace_javascript_semantics                 11,185        41      11      REJECTED
compare_process_captures                   10,837        60      11      REJECTED
capture_native_ui_scenario                  2,638        11       8      REJECTED
observe_native_calls                        3,721        21       9      REJECTED
capture_browser_scenario                   13,494        55       9      REJECTED
build_reconstruction_obligation_ledger     18,754       113      15      accepted
evaluate_reconstruction_coverage           21,786       119      14      accepted
compare_source_to_bundle                   15,461        82      12      accepted
inspect_macho                                 135         0       2      accepted
comment                                       694         3       3      accepted
annotate_native_function                      918         6       3      accepted

What is ruled out (each probed directly)

Not per-schema size. evaluate_reconstruction_coverage (21,786 B) is accepted while capture_native_ui_scenario (2,638 B) is rejected. A synthetic flat schema of ~18 KB is accepted. So this is not the ~14 KB per-schema cap from #1484.
Not nesting depth. build_reconstruction_obligation_ledger (depth 15) is accepted while capture_native_ui_scenario (depth 8) is rejected. Raw depth does not separate the sets, unlike #2813.
Not $schema dialect. 230/231 tools advertise draft/2020-12; rewriting a failing schema to draft-07, or deleting $schema, changes nothing.
Not dependentRequired. It survives into the compact output (1 tool keeps it) and compact is accepted — so this is not the #2832 mechanism.
Not any single JSON-Schema keyword. const, enum, oneOf, anyOf, allOf, items, minItems, minimum/maximum, exclusiveMinimum, pattern, patternProperties, propertyNames, default, examples, format, and a minimal $defs+$ref pair were each probed alone on a synthetic tool: all accepted.
Not a $ref count, $ref-chain depth, or "union reachable through a $ref". All three overlap between the accepted and rejected sets (e.g. evaluate_reconstruction_coverage: 119 refs, chain 4, referenced union → accepted; capture_native_ui_scenario: 11 refs, chain 3, referenced union → rejected).

What differs between the profiles

Diffing the same 184 tools across profiles:

key	`full` (tools with key)	`compact`
`$defs` / `$ref`	172	0
`examples`	170	0
nested `description`	164	8
`oneOf` / `anyOf`	30 / 28	23 / 22
`dependentRequired` / `$schema` / `propertyNames`	1 / 184 / 3	1 / 184 / 3

compact inlines every schema-local reference and drops nested annotation prose; compact is accepted for all 184 tools. That makes the reference advertisements and/or the nested prose the most likely trigger, but I could not reduce it to a rule — none of the structural metrics above separates the two per-tool sets, and every single-keyword synthetic probe passes. I am reporting the accept/reject map above rather than a guessed cause, in case it lets you correlate against the generator.

Workaround (verified)

"env": { "REA_MCP_INPUT_SCHEMA_PROFILE": "compact" }

With this set, the 184 rea tools and the full 231-tool catalog both return 200 against cn:kimi-k3-1. Operator cost: nested property descriptions/examples are no longer advertised (top-level tool descriptions are kept).

Requests

Consider selecting the inline projection by reference count / dialect rather than by serialized size only — the helper added in d86d29c (countLocalReferenceExpansions) already computes the number, and compact's current trigger (size) did not fire for a catalog that a size-tolerant-but-reference-intolerant backend rejects.
Document the WorkBuddy/CodeBuddy dialect next to Moonshot in the REA_MCP_INPUT_SCHEMA_PROFILE description. Operators hitting this see only code 11133 with an empty param, which is hard to attribute to the tool catalog.

#1327 — same gateway and the same 400 code 11133 / 503 error shape, fixed in 6.2.0 for rejected pattern fields (those are fixed here; this is a remaining case on 6.4.0)
#1484 — Moonshot per-schema size cap; origin of the compact profile
#2813 — depth > 10 breaks strict-depth clients
#2832 — Gemini rejects the catalog over dependentRequired
d86d29c — advertisedReferenceExpansionBudget / reference-expansion counting

Originally created by @Smirk1921 on GitHub (Oct 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2999 ### Summary A gateway fronting the **WorkBuddy / CodeBuddy** backend rejects the **entire** request with HTTP 400 `code 11133` as soon as certain rea tool schemas are present. One offending advertisement takes the whole session's toolset down — the same failure shape as #1327 and #1484, and the same family as #2813 / #2832. `rea-agents@6.4.0` with the **default (`full`) profile** still triggers it; **`REA_MCP_INPUT_SCHEMA_PROFILE=compact` fixes it completely** (all 184 rea tools and the full 231-tool catalog return 200). ### Environment | | | |---|---| | rea-agents | `6.4.0`, source build, `main` @ `8cbd57c` (358 commits behind `origin/main`) | | Node | `v24.x` | | Client | ZCode `3.15.1` (SSE, `ai-sdk` transport) | | Route | ZCode → local OpenAI-compatible gateway → WorkBuddy/CodeBuddy upstream | | Model | `cn:kimi-k3-1` (Kimi-K3; `only_reasoning`, single `medium` effort) | | Transport | MCP stdio, non-package-runner registration | | Tools in the failing request | 231 = 34 client built-in + 12 other MCP server + **184 rea** + 1 other | ### Observed error ``` HTTP 400 {"code":11133,"msg":"Invalid request parameters", "extError":{"code":"400001","message":"the request parameters were rejected by the model provider", "param":"","type":"invalid_request_error","StatusCode":400}, "displayTips":{"en":"This model does not accept the current conversation. It is not a network issue...", "zh":"这次对话的内容这个模型不接受，与网络无关..."}} ``` `param` is empty — the upstream names no offending field. The gateway then retries across accounts (every account rejects, so it is not account-specific) and surfaces `503`. It is not content-related either: the same body with `tools` removed returns 200, and plain minimal requests to the same model and account return 200. The same 231 tools are also accepted by other models on the same gateway (DeepSeek backends), so the rejection is specific to this backend. ### A/B (identical body, only the advertised `tools` differ) Same messages, `tool_choice:"auto"`, `stream:true`, `reasoning_effort:"max"`, `max_completion_tokens:131072`. Both profiles captured from `tools/list` of the same `6.4.0` build. | # | tools advertised | profile | result | |---|---|---|---| | A | all 231 (184 rea) | `full` | **400 `11133`** | | B | 184 rea only | `full` | **400 `11133`** | | C | 184 rea only | **`compact`** | **200** | | D | all 231 (184 rea) | **`compact`** | **200** | The client's 34 built-in tools and the other MCP server's 12 tools never trigger it. Removing rea from the catalog is sufficient to restore the session. ### Per-tool evidence (`full` profile, one rea tool per request, healthy backend pool) ``` tool inputSchema $ref raw depth result bytes count (JSON tree) compare_web_captures 57,360 199 19 REJECTED correlate_static_and_runtime 9,110 44 12 REJECTED trace_javascript_semantics 11,185 41 11 REJECTED compare_process_captures 10,837 60 11 REJECTED capture_native_ui_scenario 2,638 11 8 REJECTED observe_native_calls 3,721 21 9 REJECTED capture_browser_scenario 13,494 55 9 REJECTED build_reconstruction_obligation_ledger 18,754 113 15 accepted evaluate_reconstruction_coverage 21,786 119 14 accepted compare_source_to_bundle 15,461 82 12 accepted inspect_macho 135 0 2 accepted comment 694 3 3 accepted annotate_native_function 918 6 3 accepted ``` ### What is ruled out (each probed directly) * **Not per-schema size.** `evaluate_reconstruction_coverage` (21,786 B) is accepted while `capture_native_ui_scenario` (2,638 B) is rejected. A synthetic flat schema of ~18 KB is accepted. So this is not the ~14 KB per-schema cap from #1484. * **Not nesting depth.** `build_reconstruction_obligation_ledger` (depth 15) is accepted while `capture_native_ui_scenario` (depth 8) is rejected. Raw depth does not separate the sets, unlike #2813. * **Not `$schema` dialect.** 230/231 tools advertise `draft/2020-12`; rewriting a failing schema to `draft-07`, or deleting `$schema`, changes nothing. * **Not `dependentRequired`.** It survives into the `compact` output (1 tool keeps it) and `compact` is accepted — so this is not the #2832 mechanism. * **Not any single JSON-Schema keyword.** `const`, `enum`, `oneOf`, `anyOf`, `allOf`, `items`, `minItems`, `minimum`/`maximum`, `exclusiveMinimum`, `pattern`, `patternProperties`, `propertyNames`, `default`, `examples`, `format`, and a minimal `$defs`+`$ref` pair were each probed alone on a synthetic tool: all accepted. * **Not a `$ref` count, `$ref`-chain depth, or "union reachable through a `$ref`".** All three overlap between the accepted and rejected sets (e.g. `evaluate_reconstruction_coverage`: 119 refs, chain 4, referenced union → accepted; `capture_native_ui_scenario`: 11 refs, chain 3, referenced union → rejected). ### What differs between the profiles Diffing the same 184 tools across profiles: | key | `full` (tools with key) | `compact` | |---|---|---| | `$defs` / `$ref` | **172** | **0** | | `examples` | 170 | 0 | | nested `description` | 164 | 8 | | `oneOf` / `anyOf` | 30 / 28 | 23 / 22 | | `dependentRequired` / `$schema` / `propertyNames` | 1 / 184 / 3 | 1 / 184 / 3 | `compact` inlines every schema-local reference and drops nested annotation prose; `compact` is accepted for all 184 tools. That makes the reference advertisements and/or the nested prose the most likely trigger, but I could not reduce it to a rule — none of the structural metrics above separates the two per-tool sets, and every single-keyword synthetic probe passes. I am reporting the accept/reject map above rather than a guessed cause, in case it lets you correlate against the generator. ### Workaround (verified) ```jsonc "env": { "REA_MCP_INPUT_SCHEMA_PROFILE": "compact" } ``` With this set, the 184 rea tools and the full 231-tool catalog both return 200 against `cn:kimi-k3-1`. Operator cost: nested property descriptions/examples are no longer advertised (top-level tool descriptions are kept). ### Requests 1. Consider selecting the inline projection by **reference count / dialect** rather than by serialized size only — the helper added in `d86d29c` (`countLocalReferenceExpansions`) already computes the number, and `compact`'s current trigger (size) did not fire for a catalog that a size-tolerant-but-reference-intolerant backend rejects. 2. Document the WorkBuddy/CodeBuddy dialect next to Moonshot in the `REA_MCP_INPUT_SCHEMA_PROFILE` description. Operators hitting this see only `code 11133` with an empty `param`, which is hard to attribute to the tool catalog. ### Related * #1327 — same gateway and the same `400 code 11133` / `503` error shape, fixed in `6.2.0` for rejected `pattern` fields (those are fixed here; this is a remaining case on `6.4.0`) * #1484 — Moonshot per-schema size cap; origin of the `compact` profile * #2813 — depth > 10 breaks strict-depth clients * #2832 — Gemini rejects the catalog over `dependentRequired` * `d86d29c` — `advertisedReferenceExpansionBudget` / reference-expansion counting

bsakaguchi added the

area: mcp

bug

labels

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

bsakaguchi commented

2026-10-15 18:30:40 +00:00

Author

Owner

@Smirk1921 commented on GitHub (Oct 13, 2026):

Update: rebuilt from `origin/main` (`4c83846`, +358 commits) — `full` still rejected, `compact` still required

I upgraded this install from 8cbd57c (358 commits behind) to 4c83846 and re-verified against the same backend/model.

Result: no change in the verdict. full + all 194 tools → 400 code 11133; compact + all 194 tools → 200.

full    194 tools -> 400 11133
compact 194 tools -> 200

(node scripts/rea.mjs doctor reports healthy: true, skill v41 / 194 tools aligned, registrations aligned. The DeepSeek backends on the same gateway accept the new full catalog — 194 tools → 200 — so the upgrade introduces no regression for them.)

What the upgrade did change

The reference-expansion work (d86d29c and friends) inlined schema-local references on several tools, which fixed 4 of the 7 tools that were rejected on 8cbd57c:

tool	`8cbd57c` full (`$ref`, bytes, depth)	`4c83846` full (`$ref`, bytes, depth)	verdict
`trace_javascript_semantics`	41, 11,185, 11	0, 11,070, 16	rejected → accepted
`compare_process_captures`	60, 10,837, 11	0, 17,436, 18	rejected → accepted
`capture_browser_scenario`	55, 13,494, 9	0, 18,838, 17	rejected → accepted
`correlate_static_and_runtime`	44, 9,110, 12	0, 15,712, 15	rejected → accepted
`capture_native_ui_scenario`	11, 2,638, 8	11, 2,638, 8	still rejected
`observe_native_calls`	21, 3,721, 9	21, 3,721, 9	still rejected
`compare_web_captures`	199, 57,360, 19	0, 153,999, 31	still rejected

Two things worth flagging:

Two tools still carry $defs/$ref in full (capture_native_ui_scenario, observe_native_calls) and both are still rejected — consistent with the reference advertisements being (part of) the trigger. On 4c83846 the catalog has 157/194 tools with $ref in full (down from 172/184), so the inline projection is not being applied to every tool.
compare_web_captures now fails for what looks like a different reason. Inlining its references removed all 199 $refs but grew the advertised inputSchema from 57 KB to 154 KB and its raw tree depth from 19 to 31. It is still rejected while other newly-inlined tools at 11–19 KB and depth 15–18 are accepted — so this one now looks size/depth-bound rather than reference-bound. If that is intended, it may affect other clients with per-schema size or depth caps (cf. #1484's ~14 KB figure and #2813's depth-10 clients), independently of this backend.

Conclusion

REA_MCP_INPUT_SCHEMA_PROFILE=compact remains the only complete fix for this backend at 4c83846 (all 194 tools → 200), and I am keeping it. Making the inline projection the default for this dialect — or applying it per-tool whenever a tool's references would exceed a provider budget — would let full work here too.

@Smirk1921 commented on GitHub (Oct 13, 2026): ### Update: rebuilt from `origin/main` (`4c83846`, +358 commits) — `full` still rejected, `compact` still required I upgraded this install from `8cbd57c` (358 commits behind) to `4c83846` and re-verified against the same backend/model. **Result: no change in the verdict.** `full` + all 194 tools → `400 code 11133`; `compact` + all 194 tools → `200`. ``` full 194 tools -> 400 11133 compact 194 tools -> 200 ``` (`node scripts/rea.mjs doctor` reports `healthy: true`, skill v41 / 194 tools aligned, registrations aligned. The DeepSeek backends on the same gateway accept the new `full` catalog — 194 tools → 200 — so the upgrade introduces no regression for them.) ### What the upgrade did change The reference-expansion work (`d86d29c` and friends) inlined schema-local references on several tools, which fixed **4 of the 7** tools that were rejected on `8cbd57c`: | tool | `8cbd57c` full (`$ref`, bytes, depth) | `4c83846` full (`$ref`, bytes, depth) | verdict | |---|---|---|---| | `trace_javascript_semantics` | 41, 11,185, 11 | **0, 11,070, 16** | rejected → **accepted** | | `compare_process_captures` | 60, 10,837, 11 | **0, 17,436, 18** | rejected → **accepted** | | `capture_browser_scenario` | 55, 13,494, 9 | **0, 18,838, 17** | rejected → **accepted** | | `correlate_static_and_runtime` | 44, 9,110, 12 | **0, 15,712, 15** | rejected → **accepted** | | `capture_native_ui_scenario` | 11, 2,638, 8 | 11, 2,638, 8 | still **rejected** | | `observe_native_calls` | 21, 3,721, 9 | 21, 3,721, 9 | still **rejected** | | `compare_web_captures` | 199, 57,360, 19 | **0, 153,999, 31** | still **rejected** | Two things worth flagging: 1. **Two tools still carry `$defs`/`$ref` in `full`** (`capture_native_ui_scenario`, `observe_native_calls`) and both are still rejected — consistent with the reference advertisements being (part of) the trigger. On `4c83846` the catalog has 157/194 tools with `$ref` in `full` (down from 172/184), so the inline projection is not being applied to every tool. 2. **`compare_web_captures` now fails for what looks like a different reason.** Inlining its references removed all 199 `$ref`s but grew the advertised `inputSchema` from 57 KB to **154 KB** and its raw tree depth from 19 to **31**. It is still rejected while other newly-inlined tools at 11–19 KB and depth 15–18 are accepted — so this one now looks size/depth-bound rather than reference-bound. If that is intended, it may affect other clients with per-schema size or depth caps (cf. #1484's ~14 KB figure and #2813's depth-10 clients), independently of this backend. ### Conclusion `REA_MCP_INPUT_SCHEMA_PROFILE=compact` remains the only complete fix for this backend at `4c83846` (all 194 tools → 200), and I am keeping it. Making the inline projection the default for this dialect — or applying it per-tool whenever a tool's references would exceed a provider budget — would let `full` work here too.

bsakaguchi commented

2026-10-15 18:30:40 +00:00

Author

Owner

@maxiaochaos commented on GitHub (Oct 15, 2026):

I'll take the docs slice — note WorkBuddy/CodeBuddy needs REA_MCP_INPUT_SCHEMA_PROFILE=compact next to Moonshot. PR in a day or two.

@maxiaochaos commented on GitHub (Oct 15, 2026): I'll take the docs slice — note WorkBuddy/CodeBuddy needs REA_MCP_INPUT_SCHEMA_PROFILE=compact next to Moonshot. PR in a day or two.

bsakaguchi referenced this issue

2026-10-16 21:02:23 +00:00

[GH-ISSUE #1065] [Feature] Roadmap: improve MCP usability and performance under bounded resources #390

bsakaguchi referenced this issue

2026-10-16 21:08:21 +00:00

[GH-ISSUE #4190] [Feature] Query retained application metadata and native facts by exact path #1642

bsakaguchi referenced this issue

2026-10-17 21:08:05 +00:00

[PR #1037] [MERGED] feat(native): inspect offline ELF layout through pwntools #2600

bsakaguchi referenced this issue

2026-10-17 21:08:13 +00:00

[PR #1055] [MERGED] fix(javascript): complete large-ASAR analysis with file-local projection #2611

bsakaguchi referenced this issue

2026-10-17 21:09:15 +00:00

[PR #1180] [MERGED] feat(mcp): select views of retained analysis results #2704

bsakaguchi closed this issue

2026-10-31 00:29:52 +00:00

bsakaguchi commented

2026-10-31 00:29:53 +00:00

Author

Owner

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

Thank you for the detailed profile comparison and for separating the gateway, host, and model. The profile that succeeded in your reported experiment is now the default on main (#5975), and the gateway-specific caveat is recorded in docs/mcp-contracts.md. I am closing the default-profile report; I have not rerun the gateway against the current catalog, and explicit full remains a separate compatibility question. The small documentation follow-up is still open as #4028. Please reopen if the current default reproduces the rejection, or if full-profile compatibility needs to be pursued with a current example.

@morluto commented on GitHub (Oct 26, 2026): Thank you for the detailed profile comparison and for separating the gateway, host, and model. The profile that succeeded in your reported experiment is now the default on main (#5975), and the gateway-specific caveat is recorded in `docs/mcp-contracts.md`. I am closing the default-profile report; I have not rerun the gateway against the current catalog, and explicit `full` remains a separate compatibility question. The small documentation follow-up is still open as #4028. Please reopen if the current default reproduces the rejection, or if full-profile compatibility needs to be pursued with a current example.

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#1050

No description provided.

Rows
Columns

[GH-ISSUE #2999] [Bug] WorkBuddy/CodeBuddy-backed gateway rejects the whole tool catalog with HTTP 400 code 11133 on the default profile; REA_MCP_INPUT_SCHEMA_PROFILE=compact fixes it #1050

Summary

Environment

Observed error

A/B (identical body, only the advertised tools differ)

Per-tool evidence (full profile, one rea tool per request, healthy backend pool)

What is ruled out (each probed directly)

What differs between the profiles

Workaround (verified)

Requests

Related

Update: rebuilt from origin/main (4c83846, +358 commits) — full still rejected, compact still required

What the upgrade did change

Conclusion

A/B (identical body, only the advertised `tools` differ)

Per-tool evidence (`full` profile, one rea tool per request, healthy backend pool)

Update: rebuilt from `origin/main` (`4c83846`, +358 commits) — `full` still rejected, `compact` still required