morluto/rea

Fork 0

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

[GH-ISSUE #5322] compare_web_captures: advertised `normalization` default is rejected for passive before/after comparisons #3236

New issue

Closed

opened 2026-10-31 00:38:10 +00:00 by bsakaguchi · 6 comments

bsakaguchi commented

2026-10-31 00:38:10 +00:00

Owner

Originally created by @jbevedpm on GitHub (Oct 20, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/5322

Observed behavior

The MCP input schema for compare_web_captures declares a top-level normalization property with "default": {"rules": []}. MCP clients that apply schema defaults (Claude Desktop / Claude Code) therefore always send normalization. The server's validator then rejects it for the passive before/after input group:

Input validation error: Invalid arguments for tool compare_web_captures: ✖ Unrecognized key: "normalization"

Result: passive web-capture comparisons can't be run from those clients at all. Claude surfaces it as "Claude can't use Compare Web Captures from REA because of a problem with that connector."

Reproduction

Raw JSON-RPC over stdio against npx -y rea-agents@6.7.0 mcp, after initialize:

tools/call compare_web_captures with {} → only the expected "expected object, received undefined" errors for before/after/before_scenario/after_scenario.
tools/call compare_web_captures with {"normalization": {"rules": []}} (the schema's own default) → the same errors plus ✖ Unrecognized key: "normalization".

So a value the schema itself advertises as the default fails validation on the server.

Expected behavior

Either the server accepts (and ignores) normalization with the empty default for passive comparisons, or the advertised schema doesn't put a default on a key that's only valid for the before_scenario/after_scenario group, so clients don't inject it.

Analysis or suspected cause

The published schema flattens both input groups into one object with normalization (plus its default) at the top level. Server-side validation looks like a strict union where the passive branch doesn't allow normalization. Clients that fill in defaults always hit the strict-key rejection on the passive branch.

Environment

REA: rea-agents 6.7.0 (latest on npm as of 2026-10-19), registered via npx rea-agents setup
Interface: MCP (stdio)
Clients: Claude Code, Claude Desktop
Node.js 24.16.0, npm 11.13.0, macOS 26.6.2

Workaround

Not verified: the CLI rea compare-web-captures route shouldn't be affected, since no MCP client injects defaults there.

Originally created by @jbevedpm on GitHub (Oct 20, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5322 ### Observed behavior The MCP input schema for `compare_web_captures` declares a top-level `normalization` property with `"default": {"rules": []}`. MCP clients that apply schema defaults (Claude Desktop / Claude Code) therefore always send `normalization`. The server's validator then rejects it for the passive `before`/`after` input group: ``` Input validation error: Invalid arguments for tool compare_web_captures: ✖ Unrecognized key: "normalization" ``` Result: passive web-capture comparisons can't be run from those clients at all. Claude surfaces it as "Claude can't use Compare Web Captures from REA because of a problem with that connector." ### Reproduction Raw JSON-RPC over stdio against `npx -y rea-agents@6.7.0 mcp`, after `initialize`: 1. `tools/call` `compare_web_captures` with `{}` → only the expected "expected object, received undefined" errors for `before`/`after`/`before_scenario`/`after_scenario`. 2. `tools/call` `compare_web_captures` with `{"normalization": {"rules": []}}` (the schema's own default) → the same errors **plus** `✖ Unrecognized key: "normalization"`. So a value the schema itself advertises as the default fails validation on the server. ### Expected behavior Either the server accepts (and ignores) `normalization` with the empty default for passive comparisons, or the advertised schema doesn't put a default on a key that's only valid for the `before_scenario`/`after_scenario` group, so clients don't inject it. ### Analysis or suspected cause The published schema flattens both input groups into one object with `normalization` (plus its default) at the top level. Server-side validation looks like a strict union where the passive branch doesn't allow `normalization`. Clients that fill in defaults always hit the strict-key rejection on the passive branch. ### Environment - REA: rea-agents 6.7.0 (latest on npm as of 2026-10-19), registered via `npx rea-agents setup` - Interface: MCP (stdio) - Clients: Claude Code, Claude Desktop - Node.js 24.16.0, npm 11.13.0, macOS 26.6.2 ### Workaround Not verified: the CLI `rea compare-web-captures` route shouldn't be affected, since no MCP client injects defaults there.

bsakaguchi closed this issue

2026-10-31 00:38:10 +00:00

bsakaguchi commented

2026-10-31 00:38:11 +00:00

Author

Owner

@darshjoshi commented on GitHub (Oct 20, 2026):

I'd like to work on this. I'll make the advertised schema and the server validation agree, so that a client which fills in the schema's own defaults can run a passive before/after comparison, with an MCP-level regression test. PR to follow.

@darshjoshi commented on GitHub (Oct 20, 2026): I'd like to work on this. I'll make the advertised schema and the server validation agree, so that a client which fills in the schema's own defaults can run a passive `before`/`after` comparison, with an MCP-level regression test. PR to follow.

bsakaguchi commented

2026-10-31 00:38:11 +00:00

Author

Owner

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

Confirmed this issue: the top-level normalization default in the published schema gets injected by default-filling MCP clients, and the passive input group's strict union validation then rejects it, which makes passive before/after comparisons unusable from Claude Desktop/Claude Code entirely. The schema-side fix in #5323 (only advertise defaults for properties every input group accepts) looks like the right direction. As a compatibility measure, it might also be worth having the server tolerate an empty-default normalization ({"rules": []}) for the passive group, since clients that cached the old schema would keep sending it after the schema update.

@XinwangTao commented on GitHub (Oct 20, 2026): Confirmed this issue: the top-level `normalization` default in the published schema gets injected by default-filling MCP clients, and the passive input group's strict union validation then rejects it, which makes passive before/after comparisons unusable from Claude Desktop/Claude Code entirely. The schema-side fix in #5323 (only advertise defaults for properties every input group accepts) looks like the right direction. As a compatibility measure, it might also be worth having the server tolerate an empty-default `normalization` ({"rules": []}) for the passive group, since clients that cached the old schema would keep sending it after the schema update.

bsakaguchi commented

2026-10-31 00:38:11 +00:00

Author

Owner

@x1mm4nu3l commented on GitHub (Oct 20, 2026):

Verified on main 2538214e2, Linux/Node 24.18.0, with a valid passive capture pair over stdio MCP. Comparison succeeds, but adding the advertised normalization: {rules: []} default triggers the unrecognized-key rejection. Removing that key succeeds again on the same connection. The CLI workaround is now verified too: compare-web-captures BEFORE AFTER --json succeeds with the same captures. I did not test installed Claude clients.

@x1mm4nu3l commented on GitHub (Oct 20, 2026): Verified on main 2538214e2, Linux/Node 24.18.0, with a valid passive capture pair over stdio MCP. Comparison succeeds, but adding the advertised `normalization: {rules: []}` default triggers the unrecognized-key rejection. Removing that key succeeds again on the same connection. The CLI workaround is now verified too: `compare-web-captures BEFORE AFTER --json` succeeds with the same captures. I did not test installed Claude clients.

bsakaguchi commented

2026-10-31 00:38:12 +00:00

Author

Owner

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

同意 x1mm4nu3l 的 stdio 验证结论——即使传入合法 capture pair，默认填充的 normalization 键也会被 passive 组的严格校验拒绝，说明这不是数据问题而是 schema 与校验不一致。#5323 只对每个输入组都接受的属性广播默认值是正确方向；建议在 PR 里补一个兼容性回归用例：模拟已缓存旧 schema 的客户端仍发送 {rules: []}，确认服务端在新 schema 下既不报 unrecognized key、又能正常完成被动比较，避免 schema 发布后新旧客户端行为不一致。

@XinwangTao commented on GitHub (Oct 20, 2026): 同意 x1mm4nu3l 的 stdio 验证结论——即使传入合法 capture pair，默认填充的 normalization 键也会被 passive 组的严格校验拒绝，说明这不是数据问题而是 schema 与校验不一致。#5323 只对每个输入组都接受的属性广播默认值是正确方向；建议在 PR 里补一个兼容性回归用例：模拟已缓存旧 schema 的客户端仍发送 {rules: []}，确认服务端在新 schema 下既不报 unrecognized key、又能正常完成被动比较，避免 schema 发布后新旧客户端行为不一致。

bsakaguchi commented

2026-10-31 00:38:12 +00:00

Author

Owner

@jbevedpm commented on GitHub (Oct 20, 2026):

Thanks for picking this up so quickly, @darshjoshi!

I reported morluto/rea#5322 from Claude Code and Claude Desktop. This fixes the root cause I hit: the passive before/after comparison failed only because the client filled in the advertised normalization default. Dropping defaults for properties that aren’t shared by every input group looks right to me, and it’s nice that it also catches the same problem in inspect_with_objdump.

Claude Code re-reads tools/list at the start of each session, so this is enough for me without a server-side compatibility shim. Once a release ships with this, I’m happy to re-test compare_web_captures from Claude Code and confirm here.

@jbevedpm commented on GitHub (Oct 20, 2026): Thanks for picking this up so quickly, @darshjoshi! I reported [morluto/rea#5322](https://github.com/morluto/rea/issues/5322) from Claude Code and Claude Desktop. This fixes the root cause I hit: the passive before/after comparison failed only because the client filled in the advertised normalization default. Dropping defaults for properties that aren’t shared by every input group looks right to me, and it’s nice that it also catches the same problem in inspect_with_objdump. Claude Code re-reads tools/list at the start of each session, so this is enough for me without a server-side compatibility shim. Once a release ships with this, I’m happy to re-test compare_web_captures from Claude Code and confirm here.

bsakaguchi commented

2026-10-31 00:38:12 +00:00

Author

Owner

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

Agreed with the direction in #5323, and seconding jbevedpm's compatibility point: default-filling clients (and any that cached the 6.7.0 schema) will keep injecting normalization: {"rules": []} even after the schema fix ships. If the server validator stays strict for the passive group, those cached clients will still hit "Unrecognized key: normalization" until they refresh. Tolerating an empty-default normalization on the passive side (treating it as a no-op) would make the upgrade smooth for everyone; ideally with a regression test that simulates a client sending the old default. That closes the loop for both new and already-configured clients rather than just fresh installs.

@XinwangTao commented on GitHub (Oct 25, 2026): Agreed with the direction in #5323, and seconding jbevedpm's compatibility point: default-filling clients (and any that cached the 6.7.0 schema) will keep injecting normalization: {"rules": []} even after the schema fix ships. If the server validator stays strict for the passive group, those cached clients will still hit "Unrecognized key: normalization" until they refresh. Tolerating an empty-default normalization on the passive side (treating it as a no-op) would make the upgrade smooth for everyone; ideally with a regression test that simulates a client sending the old default. That closes the loop for both new and already-configured clients rather than just fresh installs.

bsakaguchi referenced this issue

2026-10-31 01:08:25 +00:00

[PR #3236] [CLOSED] fix(browser): report malformed resource inventories as incomplete #5665

bsakaguchi referenced this issue

2026-10-31 01:08:47 +00:00

[PR #3291] [CLOSED] fix(test): keep capinfos fixture output byte-exact #5705

bsakaguchi referenced this issue

2026-10-31 01:08:59 +00:00

[PR #3416] [MERGED] test(browser): preserve resource uncertainty through MCP #5729