morluto/rea

Fork 0

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

[GH-ISSUE #8304] [Bug] Validating MCP clients reject search_guidance and read_guidance_section results over stdio #6536

New issue

Open

opened 2026-11-01 21:12:02 +00:00 by bsakaguchi · 4 comments

bsakaguchi commented

2026-11-01 21:12:02 +00:00

Owner

Originally created by @kaoru0822-kitauji on GitHub (Oct 31, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8304

Originally assigned to: @kaoru0822-kitauji on GitHub.

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 server, transport, and tool registration

Observed behavior

Over the real stdio MCP server (rea mcp), every successful search_guidance call is rejected by the official TypeScript MCP SDK client:

ProtocolError: Structured content does not match the tool's output schema: data must have required property 'result'

tools/list advertises search_guidance and read_guidance_section with the 2025-era legacy wrapper {type:"object", properties:{result:…}, required:["result"]}, but tools/call returns the unwrapped object (structuredContent keys status, source, content_kind, …). Session tools such as binary_session are unaffected: their canonical schemas are already {result: …} objects, and ToolResultDelivery wraps their values.

Reproduction

On main 23de10bb2, after npm ci && npm run build:cached, using Node 24.22.1:

Raw JSON-RPC over stdio to node scripts/rea.mjs mcp, with initialize at protocol 2025-06-18 or 2025-11-25.
tools/list: search_guidance.outputSchema.required is ["result"] and properties is ["result"].
tools/call search_guidance {"query":"Ghidra annotations","limit":1}: structuredContent top-level keys are status, source, content_kind, package, …, with no result.
@modelcontextprotocol/client Client plus StdioClientTransport on the same command: callTool throws the ProtocolError above.

Among the 15 tools whose advertised output schema is a lone result wrapper, the only ones observed with unwrapped content were the two guidance tools. binary_session returned structuredContent.result.

Expected behavior

The structured content of a successful result validates against the advertised outputSchema in every negotiated protocol era. With the 2025 legacy wrapper, that means {result: <value>}. Validating clients accept results from search_guidance and read_guidance_section.

Impact and scope

Any validating MCP client (the official TS SDK client validates by default) cannot use either guidance tool over stdio. Clients that skip output validation still see the content. The CLI is unaffected. tests/boundary/mcp/registerGuidanceTools.test.ts uses InMemoryTransport with a non-deferred EvidenceMcpServer, and its guidanceOutput helper accepts both shapes, so it does not catch this.

REA version

main 23de10bb2 (rea-agents 6.8.0)

Runtime and platform

macOS arm64, Node 24.22.1

Target and artifact context

No target. Provider-free guidance tools.

Interface

MCP (stdio)

Earliest failure stage

Tool result delivery / client output validation

Relevant output or evidence

See Reproduction. The JSON-RPC shapes were observed directly. No other client was tested.

Typed outcome or recovery expected

A successful result that matches the advertised schema.

Analysis or suspected cause

Source-derived hypothesis, not yet confirmed by a fix. The SDK's 2025 codec wraps structuredContent only when the tool's registered outputSchemaJson has a non-object root (projectCallToolResult). The deferred stdio server (DeferredEvidenceMcpServer) registers recorded projections through bindTool / registered.update({ outputSchema: recordedProjection(…) }). If the recorded projection is the already-wrapped object, the SDK sees an object root, so it neither re-wraps the schema nor wraps the content. ToolResultDelivery.toCallToolResult wraps only kind: "session" contracts, and the guidance contracts are kind: "application" with discriminated-union roots. A fix would make root-union contracts deliver consistently with what is advertised, at the shared registration/delivery boundary. Possible routes: object-root contracts like lifecycleResultOf, or wrapping decided by the schema root rather than contract.kind. Either route also needs checking under the 2026-07-28 era projection.

Additional context

Found while verifying #8290 over real stdio MCP. Not fixed in that PR, which keeps to search ranking.

Originally created by @kaoru0822-kitauji on GitHub (Oct 31, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8304 Originally assigned to: @kaoru0822-kitauji on GitHub. ### 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 server, transport, and tool registration ### Observed behavior Over the real stdio MCP server (`rea mcp`), every successful `search_guidance` call is rejected by the official TypeScript MCP SDK client: ``` ProtocolError: Structured content does not match the tool's output schema: data must have required property 'result' ``` `tools/list` advertises `search_guidance` and `read_guidance_section` with the 2025-era legacy wrapper `{type:"object", properties:{result:…}, required:["result"]}`, but `tools/call` returns the unwrapped object (`structuredContent` keys `status, source, content_kind, …`). Session tools such as `binary_session` are unaffected: their canonical schemas are already `{result: …}` objects, and `ToolResultDelivery` wraps their values. ### Reproduction On main `23de10bb2`, after `npm ci && npm run build:cached`, using Node 24.22.1: 1. Raw JSON-RPC over stdio to `node scripts/rea.mjs mcp`, with `initialize` at protocol `2025-06-18` or `2025-11-25`. 2. `tools/list`: `search_guidance.outputSchema.required` is `["result"]` and `properties` is `["result"]`. 3. `tools/call search_guidance {"query":"Ghidra annotations","limit":1}`: `structuredContent` top-level keys are `status, source, content_kind, package, …`, with no `result`. 4. `@modelcontextprotocol/client` `Client` plus `StdioClientTransport` on the same command: `callTool` throws the ProtocolError above. Among the 15 tools whose advertised output schema is a lone `result` wrapper, the only ones observed with unwrapped content were the two guidance tools. `binary_session` returned `structuredContent.result`. ### Expected behavior The structured content of a successful result validates against the advertised `outputSchema` in every negotiated protocol era. With the 2025 legacy wrapper, that means `{result: <value>}`. Validating clients accept results from `search_guidance` and `read_guidance_section`. ### Impact and scope Any validating MCP client (the official TS SDK client validates by default) cannot use either guidance tool over stdio. Clients that skip output validation still see the content. The CLI is unaffected. `tests/boundary/mcp/registerGuidanceTools.test.ts` uses `InMemoryTransport` with a non-deferred `EvidenceMcpServer`, and its `guidanceOutput` helper accepts both shapes, so it does not catch this. ### REA version main `23de10bb2` (rea-agents 6.8.0) ### Runtime and platform macOS arm64, Node 24.22.1 ### Target and artifact context No target. Provider-free guidance tools. ### Interface MCP (stdio) ### Earliest failure stage Tool result delivery / client output validation ### Relevant output or evidence See Reproduction. The JSON-RPC shapes were observed directly. No other client was tested. ### Typed outcome or recovery expected A successful result that matches the advertised schema. ### Analysis or suspected cause Source-derived hypothesis, not yet confirmed by a fix. The SDK's 2025 codec wraps `structuredContent` only when the tool's registered `outputSchemaJson` has a non-object root (`projectCallToolResult`). The deferred stdio server (`DeferredEvidenceMcpServer`) registers recorded projections through `bindTool` / `registered.update({ outputSchema: recordedProjection(…) })`. If the recorded projection is the already-wrapped object, the SDK sees an object root, so it neither re-wraps the schema nor wraps the content. `ToolResultDelivery.toCallToolResult` wraps only `kind: "session"` contracts, and the guidance contracts are `kind: "application"` with discriminated-union roots. A fix would make root-union contracts deliver consistently with what is advertised, at the shared registration/delivery boundary. Possible routes: object-root contracts like `lifecycleResultOf`, or wrapping decided by the schema root rather than `contract.kind`. Either route also needs checking under the 2026-07-28 era projection. ### Additional context Found while verifying #8290 over real stdio MCP. Not fixed in that PR, which keeps to search ranking.

bsakaguchi added the

bug

label

2026-11-01 21:12:02 +00:00

bsakaguchi commented

2026-11-01 21:12:03 +00:00

Author

Owner

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

Current-main paired check on 60149282 with the installed TypeScript MCP client 2.3.1 over the real stdio server:

Negotiated protocol	Output profile	`search_guidance` and a fresh-locator `read_guidance_section`
2025-11-25	full (default)	Raw call succeeds, but SDK rejects successful content: advertised `{result: ...}` wrapper is missing.
2026-07-28	full (default)	Same rejection.
2025-11-25	compact	SDK accepts; successful structured content is wrapped in `result`.
2026-07-28	compact	SDK accepts; successful structured content is unwrapped.

Both SDK calls supplied the live advertised tool definition explicitly. A fresh search_guidance result supplied the locator, and the raw section response was status: section; this is not just a stale-locator case. binary_session and guided_workflows were successful controls in all four combinations. The SDK skips its output-schema check for isError; this matrix concerns successful results.

I applied the two commits from open PR #8326 (head 09980ead009ad900851e4909a3cbfcfc24cbfbf6) without committing in a detached worktree based on 60149282; all seven PR-touched files exactly matched the PR head. In the same four-profile/protocol matrix, the SDK accepted search and fresh section results and each was wrapped in result. The same controls succeeded. The PR's focused stdio, registration and contract-root tests also passed (3 files, 4 tests). This is one local build/SDK version, not other clients, HTTP transport, or full-suite coverage. The successful modern compact shape changes from unwrapped to wrapped, so clients consuming that existing shape need to follow the advertised contract/change documentation.

@morluto commented on GitHub (Oct 31, 2026): Current-main paired check on `60149282` with the installed TypeScript MCP client 2.3.1 over the real stdio server: | Negotiated protocol | Output profile | `search_guidance` and a fresh-locator `read_guidance_section` | | --- | --- | --- | | 2025-11-25 | full (default) | Raw call succeeds, but SDK rejects successful content: advertised `{result: ...}` wrapper is missing. | | 2026-07-28 | full (default) | Same rejection. | | 2025-11-25 | compact | SDK accepts; successful structured content is wrapped in `result`. | | 2026-07-28 | compact | SDK accepts; successful structured content is unwrapped. | Both SDK calls supplied the live advertised tool definition explicitly. A fresh `search_guidance` result supplied the locator, and the raw section response was `status: section`; this is not just a stale-locator case. `binary_session` and `guided_workflows` were successful controls in all four combinations. The SDK skips its output-schema check for `isError`; this matrix concerns successful results. I applied the two commits from open PR #8326 (head `09980ead009ad900851e4909a3cbfcfc24cbfbf6`) without committing in a detached worktree based on `60149282`; all seven PR-touched files exactly matched the PR head. In the same four-profile/protocol matrix, the SDK accepted search and fresh section results and each was wrapped in `result`. The same controls succeeded. The PR's focused stdio, registration and contract-root tests also passed (3 files, 4 tests). This is one local build/SDK version, not other clients, HTTP transport, or full-suite coverage. The successful modern compact shape changes from unwrapped to wrapped, so clients consuming that existing shape need to follow the advertised contract/change documentation.

bsakaguchi commented

2026-11-01 21:12:03 +00:00

Author

Owner

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

Transport control for the preceding stdio matrix: on the same unmodified main 60149282, real rea mcp --http --port 0 bound to loopback and the TypeScript MCP SDK 2.3.1 successfully validated search_guidance, a fresh-locator read_guidance_section, and binary_session under both full and compact profiles. This held for explicit legacy protocol 2025-11-25, explicit 2025-06-18, and the SDK's default negotiation (which selected 2025-11-25). Successful structured contents were wrapped in result in these checks. The local listeners shut down after their sessions.

The isolated PR #8326-on-main build also passed the HTTP 2025-11-25 full/compact controls. Thus the observed default-profile guidance mismatch is specific to the tested stdio path, not a general claim about all REA transports. A client strictly pinned to 2026-07-28 failed version negotiation with the HTTP listener; the normal SDK client negotiated legacy successfully, and source currently creates this HTTP server with the legacy era. This is a protocol-availability observation, not a claim that the normal SDK client fails or that modern HTTP support is promised. No target or provider was opened; other clients and HTTP modes were not tested.

@morluto commented on GitHub (Oct 31, 2026): Transport control for the preceding stdio matrix: on the same unmodified main `60149282`, real `rea mcp --http --port 0` bound to loopback and the TypeScript MCP SDK 2.3.1 successfully validated `search_guidance`, a fresh-locator `read_guidance_section`, and `binary_session` under both full and compact profiles. This held for explicit legacy protocol `2025-11-25`, explicit `2025-06-18`, and the SDK's default negotiation (which selected `2025-11-25`). Successful structured contents were wrapped in `result` in these checks. The local listeners shut down after their sessions. The isolated PR #8326-on-main build also passed the HTTP `2025-11-25` full/compact controls. Thus the observed default-profile guidance mismatch is specific to the tested stdio path, not a general claim about all REA transports. A client strictly pinned to `2026-07-28` failed version negotiation with the HTTP listener; the normal SDK client negotiated legacy successfully, and source currently creates this HTTP server with the legacy era. This is a protocol-availability observation, not a claim that the normal SDK client fails or that modern HTTP support is promised. No target or provider was opened; other clients and HTTP modes were not tested.

bsakaguchi commented

2026-11-01 21:12:03 +00:00

Author

Owner

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

A real provider-task control on current main 60149282 and PR #8326 applied onto that same base used the TypeScript MCP SDK 2.3.1, stdio, protocol 2025-11-25, and live advertised output definitions. For each output profile and each provider (Kuna 1.986 and Ghidra 12.1.4), the scripted sequence searched installed native guidance, read the returned fresh locator, opened the same source-owned Mach-O, decompiled _evaluate, and closed the session.

On unmodified main with the default full profile, the SDK rejected the successful guidance-search content as described above, so the script could not obtain a locator. It still independently opened the target and obtained nonempty pseudocode from each provider. On main with compact profile, the complete scripted sequence succeeded for both providers. On the isolated PR #8326-on-main build, it succeeded for both providers under both profiles. The target SHA-256 remained ffad1b70c6a5a7ef3f7c3f59126be516520210777d949b35e97c9067f272aa2d; it was not executed.

These are scripted SDK workflows, not autonomous agent-selection trials, a broad provider correctness result, or a test of other protocols/clients. The provider calls were intentionally continued after the failed guidance step to show the available direct path; that does not mean the missing guidance was recoverable from the rejected SDK response.

@morluto commented on GitHub (Oct 31, 2026): A real provider-task control on current main `60149282` and PR #8326 applied onto that same base used the TypeScript MCP SDK 2.3.1, stdio, protocol `2025-11-25`, and live advertised output definitions. For each output profile and each provider (Kuna 1.986 and Ghidra 12.1.4), the scripted sequence searched installed native guidance, read the returned fresh locator, opened the same source-owned Mach-O, decompiled `_evaluate`, and closed the session. On unmodified main with the default full profile, the SDK rejected the successful guidance-search content as described above, so the script could not obtain a locator. It still independently opened the target and obtained nonempty pseudocode from each provider. On main with compact profile, the complete scripted sequence succeeded for both providers. On the isolated PR #8326-on-main build, it succeeded for both providers under both profiles. The target SHA-256 remained `ffad1b70c6a5a7ef3f7c3f59126be516520210777d949b35e97c9067f272aa2d`; it was not executed. These are scripted SDK workflows, not autonomous agent-selection trials, a broad provider correctness result, or a test of other protocols/clients. The provider calls were intentionally continued after the failed guidance step to show the available direct path; that does not mean the missing guidance was recoverable from the rejected SDK response.

bsakaguchi commented

2026-11-01 21:12:03 +00:00

Author

Owner

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

Current-main retest after #8305: the full-profile SDK rejection persists. A locally conflict-resolved combination of PR #8326 with current main validated the new focused/subsection search results and the real Ghidra/Kuna guidance-to-decompile workflow. GitHub currently reports the PR as conflicting; the local combination and its limits are documented at https://github.com/morluto/rea/pull/8326#issuecomment-6547494901.

@morluto commented on GitHub (Oct 31, 2026): Current-main retest after #8305: the full-profile SDK rejection persists. A locally conflict-resolved combination of PR #8326 with current main validated the new focused/subsection search results and the real Ghidra/Kuna guidance-to-decompile workflow. GitHub currently reports the PR as conflicting; the local combination and its limits are documented at https://github.com/morluto/rea/pull/8326#issuecomment-6547494901.

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

No description provided.

Rows
Columns