morluto/rea

Fork 0

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

[GH-ISSUE #3800] [Compatibility] Tool input_schemas with oneOf/allOf under required properties break Anthropic-compatible gateways (whole request 400s) #1472

New issue

Closed

opened 2026-10-16 21:05:48 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

2026-10-16 21:05:48 +00:00

Owner

Originally created by @wang1xiang on GitHub (Oct 15, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/3800

Summary

Some rea MCP tool input_schemas use JSON Schema constructs (chained $defs/$ref, oneOf/allOf under required properties, enum without a type sibling) that Anthropic-compatible third-party gateways reject. When even one such tool is registered, the gateway rejects the entire request — every API call fails with 400 A parameter specified in the request is not valid, which makes the model appear completely broken. The error does not mention which tool or which construct caused it.

Environment

rea-agents 6.4.0 (rea mcp, 208 tools exposed in my session, 170 of them mcp__rea__*)
Client: Claude Code 2.1.299
Gateway: Volcengine Ark Anthropic-compatible coding endpoint (.../api/coding), model kimi-k3
Same session works fine on the same gateway with glm-5.3 — the failure is model/provider-specific schema translation.

What happens (user-visible)

With the rea MCP server enabled, every request to kimi-k3 fails:

API Error: 400 A parameter specified in the request is not valid Request id: 0217...

Removing the rea server (or switching model) immediately restores normal behavior. No rea tool ever needs to be called — the failure happens on schema upload alone.

Root cause analysis

I bisected the 208-tool request against the gateway and then delta-minimized one failing schema. Tools that fail when sent alone:

compare_web_captures
trace_javascript_semantics
capture_browser_scenario
capture_native_ui_scenario

Minimal reproductions confirmed against the gateway (all are valid JSON Schema draft 2020-12; all fail with the same 400):

1. enum without a type sibling as a property schema:

{ "type": "object", "properties": { "p": { "enum": ["a", "b"] } } }

2. Inside a $defs definition reached via $ref, a required property whose value contains oneOf (or allOf):

{
  "type": "object",
  "properties": { "query": { "$ref": "#/$defs/__schema18" } },
  "$defs": {
    "__schema18": {
      "type": "object",
      "properties": {
        "seed": {
          "oneOf": [
            {
              "type": "object",
              "properties": { "kind": { "type": "string", "const": "x" } },
              "required": ["kind"],
              "additionalProperties": false
            }
          ]
        }
      },
      "required": ["seed"]
    }
  }
}

trace_javascript_semantics minimizes down to exactly this shape (seed is a oneOf of 8 variants and is required).

3. anyOf: [] (empty array) also fails, while oneOf: [] does not — so the gateway's translation layer chokes on several distinct constructs.

For context, these constructs appear throughout the schemas generated for the CDP/Evidence tools, e.g. in compare_web_captures the __schema45-style step-artifact definitions put oneOf discriminators under required keys (screenshot, dom, url, ...).

Why this matters

Blast radius is the whole session. One incompatible tool rejects all 208 tools in the request, and the model becomes unusable for the entire session — including sessions that never call a rea tool.
The error is opaque. "A parameter specified in the request is not valid" gives no hint that an MCP tool schema is the cause. I needed a local recording proxy + schema bisection to find it. Other users will likely just conclude "kimi-k3 on Ark is broken" or "rea is broken" and drop one of them.
Gateway-side fixes are out of rea's control and slow. Volcengine will need time (if they fix it at all); a client-side option would work everywhere, including other strict gateways.

Request

Any of these would solve it for affected users:

A conservative schema mode (e.g. rea mcp --schema-style=flat or an env var) that emits gateway-safe schemas: inline all $defs/$ref, ensure every enum has an explicit type, avoid oneOf/allOf/anyOf in positions that strict translators mishandle (or replace discriminated unions with plain object + enum on the discriminator field).
Alternatively, a per-tool or per-area toolset filter so users can exclude the heavyweight schema tools (the failing ones are all in the browser-capture / JS-tracing families).
At minimum, a documentation note listing known-incompatible gateways and the workaround (disable rea when using them).

Happy to provide the full bisection logs / captured schemas if useful.

Originally created by @wang1xiang on GitHub (Oct 15, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3800 ## Summary Some rea MCP tool `input_schema`s use JSON Schema constructs (chained `$defs`/`$ref`, `oneOf`/`allOf` under `required` properties, `enum` without a `type` sibling) that Anthropic-compatible third-party gateways reject. When even one such tool is registered, **the gateway rejects the entire request** — every API call fails with `400 A parameter specified in the request is not valid`, which makes the model appear completely broken. The error does not mention which tool or which construct caused it. ## Environment - rea-agents 6.4.0 (`rea mcp`, 208 tools exposed in my session, 170 of them `mcp__rea__*`) - Client: Claude Code 2.1.299 - Gateway: Volcengine Ark Anthropic-compatible coding endpoint (`.../api/coding`), model `kimi-k3` - Same session works fine on the same gateway with `glm-5.3` — the failure is model/provider-specific schema translation. ## What happens (user-visible) With the rea MCP server enabled, every request to `kimi-k3` fails: ``` API Error: 400 A parameter specified in the request is not valid Request id: 0217... ``` Removing the rea server (or switching model) immediately restores normal behavior. No rea tool ever needs to be called — the failure happens on schema upload alone. ## Root cause analysis I bisected the 208-tool request against the gateway and then delta-minimized one failing schema. Tools that fail **when sent alone**: - `compare_web_captures` - `trace_javascript_semantics` - `capture_browser_scenario` - `capture_native_ui_scenario` Minimal reproductions confirmed against the gateway (all are valid JSON Schema draft 2020-12; all fail with the same 400): **1. `enum` without a `type` sibling as a property schema:** ```json { "type": "object", "properties": { "p": { "enum": ["a", "b"] } } } ``` **2. Inside a `$defs` definition reached via `$ref`, a `required` property whose value contains `oneOf` (or `allOf`):** ```json { "type": "object", "properties": { "query": { "$ref": "#/$defs/__schema18" } }, "$defs": { "__schema18": { "type": "object", "properties": { "seed": { "oneOf": [ { "type": "object", "properties": { "kind": { "type": "string", "const": "x" } }, "required": ["kind"], "additionalProperties": false } ] } }, "required": ["seed"] } } } ``` `trace_javascript_semantics` minimizes down to exactly this shape (`seed` is a `oneOf` of 8 variants and is `required`). **3. `anyOf: []`** (empty array) also fails, while `oneOf: []` does not — so the gateway's translation layer chokes on several distinct constructs. For context, these constructs appear throughout the schemas generated for the CDP/Evidence tools, e.g. in `compare_web_captures` the `__schema45`-style step-artifact definitions put `oneOf` discriminators under `required` keys (`screenshot`, `dom`, `url`, ...). ## Why this matters - **Blast radius is the whole session.** One incompatible tool rejects all 208 tools in the request, and the model becomes unusable for the entire session — including sessions that never call a rea tool. - **The error is opaque.** "A parameter specified in the request is not valid" gives no hint that an MCP tool schema is the cause. I needed a local recording proxy + schema bisection to find it. Other users will likely just conclude "kimi-k3 on Ark is broken" or "rea is broken" and drop one of them. - **Gateway-side fixes are out of rea's control and slow.** Volcengine will need time (if they fix it at all); a client-side option would work everywhere, including other strict gateways. ## Request Any of these would solve it for affected users: 1. **A conservative schema mode** (e.g. `rea mcp --schema-style=flat` or an env var) that emits gateway-safe schemas: inline all `$defs`/`$ref`, ensure every `enum` has an explicit `type`, avoid `oneOf`/`allOf`/`anyOf` in positions that strict translators mishandle (or replace discriminated unions with plain object + `enum` on the discriminator field). 2. Alternatively, a per-tool or per-area toolset filter so users can exclude the heavyweight schema tools (the failing ones are all in the browser-capture / JS-tracing families). 3. At minimum, a documentation note listing known-incompatible gateways and the workaround (disable rea when using them). Happy to provide the full bisection logs / captured schemas if useful.

bsakaguchi commented

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

Author

Owner

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

Great bisect — the key insight is that one bad schema poisons the whole tools request with a 400 that gives no pointer to the culprit, which makes this far harder to diagnose than it should be. Both minimal reproductions are valid draft 2020-12, so the failure is clearly the gateway/model translation rather than rea emitting invalid schemas. Agree with the direction in #3806 of making compact schemas gateway-compatible; beyond the schema shape fixes, it would also help to keep a lint/CI check that flags oneOf/allOf under required and enum-without-type patterns, since Anthropic-compatible gateways are a real deployment surface.

@XinwangTao commented on GitHub (Oct 15, 2026): Great bisect — the key insight is that one bad schema poisons the whole tools request with a 400 that gives no pointer to the culprit, which makes this far harder to diagnose than it should be. Both minimal reproductions are valid draft 2020-12, so the failure is clearly the gateway/model translation rather than rea emitting invalid schemas. Agree with the direction in #3806 of making compact schemas gateway-compatible; beyond the schema shape fixes, it would also help to keep a lint/CI check that flags oneOf/allOf under required and enum-without-type patterns, since Anthropic-compatible gateways are a real deployment surface.

bsakaguchi referenced this issue

2026-10-17 21:11:43 +00:00

[PR #1472] [CLOSED] fix(json): refuse evidence JSON that cannot decode before reading it #2910

bsakaguchi closed this issue

2026-10-31 00:30:56 +00:00

bsakaguchi commented

2026-10-31 00:30:57 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 25, 2026):

Thanks for the quick fix in #3806 and for closing this out — the bisect wang1xiang did was genuinely valuable for isolating the opaque 400. Glad the compact schemas are normalized now. One small suggestion: since the failure mode was so silent (one bad schema poisons the whole request), it would be worth calling out this gateway-compatibility fix in the release notes so users on strict Anthropic-compatible gateways (Ark etc.) know to upgrade instead of assuming rea is broken.

@XinwangTao commented on GitHub (Oct 25, 2026): Thanks for the quick fix in #3806 and for closing this out — the bisect wang1xiang did was genuinely valuable for isolating the opaque 400. Glad the compact schemas are normalized now. One small suggestion: since the failure mode was so silent (one bad schema poisons the whole request), it would be worth calling out this gateway-compatibility fix in the release notes so users on strict Anthropic-compatible gateways (Ark etc.) know to upgrade instead of assuming rea is broken.

bsakaguchi commented

2026-10-31 00:30:57 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 29, 2026):

Following up on my earlier release-notes suggestion: rea-agents 6.8.0 notes now state that MCP input advertisements default to compact (with REA_MCP_INPUT_SCHEMA_PROFILE=full to opt back in), so users on strict Anthropic-compatible gateways can see at a glance that the schema shape changed and upgrade instead of assuming the server is broken. That covers the silent-400 failure mode well — thanks again to wang1xiang for the bisect that made this diagnosable at all.

@XinwangTao commented on GitHub (Oct 29, 2026): Following up on my earlier release-notes suggestion: rea-agents 6.8.0 notes now state that MCP input advertisements default to compact (with REA_MCP_INPUT_SCHEMA_PROFILE=full to opt back in), so users on strict Anthropic-compatible gateways can see at a glance that the schema shape changed and upgrade instead of assuming the server is broken. That covers the silent-400 failure mode well — thanks again to wang1xiang for the bisect that made this diagnosable at all.

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

No description provided.

Rows
Columns