morluto/rea

Fork 0

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

[GH-ISSUE #3069] [Bug] binary_session reports JEB tools provider_missing without checking the JEB endpoint #1075

New issue

Closed

opened 2026-10-15 18:30:52 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

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

Owner

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

Before submitting

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

Area

Provider or capability discovery

Observed behavior

binary_session reports the four JEB tools as unavailable with reason: "provider_missing" and a fixed remediation, and it does not contact the configured JEB MCP endpoint to decide this. In source, the JEB availability input that tool_availability reads is never supplied, so the JEB tools cannot be reported available even when a JEB client is serving MCP at REA_JEB_MCP_URL. Agents that choose operations from tool_availability, as the MCP contract instructs, would then skip JEB work that can run.

On both builds, the four jeb-provider tools (decompile_jeb_item, inspect_jeb_client, list_jeb_units, open_jeb_project) were reported with the fixed entry shown under Relevant output, and a logging HTTP listener on the default endpoint received no request from either session, so binary_session did not contact the endpoint before reporting the JEB tools unavailable. Because no JEB client was running, this observed result is itself correct; the defect is shown by source (see Analysis). Runtime reproduction with a live JEB endpoint was not run: I have no licensed JEB. The missing fact is a binary_session result taken while a licensed JEB client serves MCP at REA_JEB_MCP_URL.

Reproduction

Start any HTTP listener on 127.0.0.1:8425 that logs each request it receives. REA_JEB_MCP_URL defaults to http://127.0.0.1:8425/mcp.
With REA_JEB_MCP_URL unset, start npx -y rea-agents@6.4.0 mcp. For the main build, start node scripts/rea.mjs mcp from the compiled checkout (npm ci --ignore-scripts, npm run compile) instead.
From a stdio MCP client, send these newline-delimited messages in order, waiting for the initialize response before sending the rest.

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"availability-probe","version":"1.0.0"}}}
{"jsonrpc":"2.0","method":"notifications/initialized"}
{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"binary_session","arguments":{}}}

In response 2, read result.structuredContent.result.tool_availability and select the jeb-provider entries (on main, expand tool_availability.groups first). Then check the listener's log.
Not executed: repeat steps 2 to 4 while a licensed JEB client serves MCP at that URL.

Expected behavior

docs/mcp-contracts.md (lines 114-119 at the 6.4.0 tag; lines 337-347 on main in grouped form) says: "Call binary_session with {} and read result.tool_availability to choose a callable operation for the current target, provider, host, and negotiated client capabilities", with each tool's availability, reason, and remediation. The JEB tools need no open_binary target; their engine is the JEB client at REA_JEB_MCP_URL. When that endpoint serves JEB's MCP interface, at least inspect_jeb_client should be reported available, and any JEB tool the engine cannot serve (for example open_jeb_project on headless JEB builds that do not advertise open_project, per docs/jeb-analysis.md) should be unavailable for that reason rather than provider_missing; when no JEB endpoint answers, they should be reported unavailable with JEB guidance, as today.

Restoration check: with a JEB client serving MCP at REA_JEB_MCP_URL, the per-tool facts in binary_session (expanded from groups where applicable) report at least inspect_jeb_client available. Control: with nothing listening at that URL, or with a listener that does not speak JEB's MCP interface, the JEB entries stay unavailable with JEB-specific guidance.

Impact and scope

Affected, from the source path: the four jeb-provider entries in binary_session.tool_availability on both builds. Agents following the documented availability contract are always told the JEB tools are unavailable, which would make them skip JEB work against a running JEB. This was not observed with a live JEB.

Not affected: the JEB tools themselves are not changed by this; no data is lost.

Possible workaround (not verified against a live JEB): call inspect_jeb_client directly, which docs/jeb-analysis.md lists as reporting the engine version and mode, to see whether the endpoint answers.

REA version

6.4.0 (npm, tag rea-agents-6.4.0 at a56f7bb668); same source path and observation on main e049ef70f7

Runtime and platform

Node 26.10.0; macOS 27.0 arm64; no JEB installation (a plain HTTP listener stood in for the endpoint)

Target and artifact context

No target; target-free binary_session call

Interface

MCP

Earliest failure stage

Setup or provider admission

Relevant output or evidence

binary_session (both builds), each of the 4 jeb-provider entries:
{"available":false,"reason":"provider_missing","remediation":"Start a JEB client serving MCP (GUI client, or headless via its programmatic launcher) and point REA_JEB_MCP_URL at it (default http://127.0.0.1:8425/mcp). REA does not install or launch JEB."}

listener on 127.0.0.1:8425 during both sessions: no requests logged

Analysis or suspected cause

Static proof from source. AvailabilityPolicy in src/application/CapabilityInventory.ts has a jebAnalysisAvailability field (line 43 at the tag, 57 on main), and the jeb-provider check (lines 360-368 at the tag, 470-478 on main) reports the tools available only when that field's status is available. No other file under src names the field, so nothing sets it: the only per-engine availability input that src/server/createServer.ts (line 334 at the tag, 570 on main) passes to the session tools is androidAnalysisAvailability, and src/server/registerSessionStatusTool.ts (lines 64-70 at the tag, 68-74 on main) builds the binary_session policy from the base policy plus only androidAnalysisAvailability. With the field always unset, the check always takes its unavailable branch, whatever runs at REA_JEB_MCP_URL. By contrast, the Android entries come from android.inspectAvailability, which createServer.ts passes in.

Additional context

The ADB and Apktool tools are also misreported in the same result through a different path (they have no availability check at all); those are reported separately. Related but separate: #3008 asks rea doctor to report these providers.

Originally created by @coygeek on GitHub (Oct 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3069 ### 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 Provider or capability discovery ### Observed behavior `binary_session` reports the four JEB tools as unavailable with `reason: "provider_missing"` and a fixed remediation, and it does not contact the configured JEB MCP endpoint to decide this. In source, the JEB availability input that `tool_availability` reads is never supplied, so the JEB tools cannot be reported available even when a JEB client is serving MCP at `REA_JEB_MCP_URL`. Agents that choose operations from `tool_availability`, as the MCP contract instructs, would then skip JEB work that can run. On both builds, the four `jeb-provider` tools (`decompile_jeb_item`, `inspect_jeb_client`, `list_jeb_units`, `open_jeb_project`) were reported with the fixed entry shown under Relevant output, and a logging HTTP listener on the default endpoint received no request from either session, so `binary_session` did not contact the endpoint before reporting the JEB tools unavailable. Because no JEB client was running, this observed result is itself correct; the defect is shown by source (see Analysis). Runtime reproduction with a live JEB endpoint was not run: I have no licensed JEB. The missing fact is a `binary_session` result taken while a licensed JEB client serves MCP at `REA_JEB_MCP_URL`. ### Reproduction 1. Start any HTTP listener on `127.0.0.1:8425` that logs each request it receives. `REA_JEB_MCP_URL` defaults to `http://127.0.0.1:8425/mcp`. 2. With `REA_JEB_MCP_URL` unset, start `npx -y rea-agents@6.4.0 mcp`. For the `main` build, start `node scripts/rea.mjs mcp` from the compiled checkout (`npm ci --ignore-scripts`, `npm run compile`) instead. 3. From a stdio MCP client, send these newline-delimited messages in order, waiting for the `initialize` response before sending the rest. ```json {"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"availability-probe","version":"1.0.0"}}} {"jsonrpc":"2.0","method":"notifications/initialized"} {"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"binary_session","arguments":{}}} ``` 4. In response 2, read `result.structuredContent.result.tool_availability` and select the `jeb-provider` entries (on `main`, expand `tool_availability.groups` first). Then check the listener's log. 5. Not executed: repeat steps 2 to 4 while a licensed JEB client serves MCP at that URL. ### Expected behavior `docs/mcp-contracts.md` (lines 114-119 at the 6.4.0 tag; lines 337-347 on `main` in grouped form) says: "Call `binary_session` with `{}` and read `result.tool_availability` to choose a callable operation for the current target, provider, host, and negotiated client capabilities", with each tool's availability, reason, and remediation. The JEB tools need no `open_binary` target; their engine is the JEB client at `REA_JEB_MCP_URL`. When that endpoint serves JEB's MCP interface, at least `inspect_jeb_client` should be reported available, and any JEB tool the engine cannot serve (for example `open_jeb_project` on headless JEB builds that do not advertise `open_project`, per `docs/jeb-analysis.md`) should be unavailable for that reason rather than `provider_missing`; when no JEB endpoint answers, they should be reported unavailable with JEB guidance, as today. Restoration check: with a JEB client serving MCP at `REA_JEB_MCP_URL`, the per-tool facts in `binary_session` (expanded from groups where applicable) report at least `inspect_jeb_client` available. Control: with nothing listening at that URL, or with a listener that does not speak JEB's MCP interface, the JEB entries stay unavailable with JEB-specific guidance. ### Impact and scope Affected, from the source path: the four `jeb-provider` entries in `binary_session.tool_availability` on both builds. Agents following the documented availability contract are always told the JEB tools are unavailable, which would make them skip JEB work against a running JEB. This was not observed with a live JEB. Not affected: the JEB tools themselves are not changed by this; no data is lost. Possible workaround (not verified against a live JEB): call `inspect_jeb_client` directly, which `docs/jeb-analysis.md` lists as reporting the engine version and mode, to see whether the endpoint answers. ### REA version 6.4.0 (npm, tag rea-agents-6.4.0 at a56f7bb668ab23fec8d33f7af353ac7ed2fe1895); same source path and observation on main e049ef70f71aeb9965e9d75d4d4a84ea02eaee11 ### Runtime and platform Node 26.10.0; macOS 27.0 arm64; no JEB installation (a plain HTTP listener stood in for the endpoint) ### Target and artifact context No target; target-free `binary_session` call ### Interface MCP ### Earliest failure stage Setup or provider admission ### Relevant output or evidence ```text binary_session (both builds), each of the 4 jeb-provider entries: {"available":false,"reason":"provider_missing","remediation":"Start a JEB client serving MCP (GUI client, or headless via its programmatic launcher) and point REA_JEB_MCP_URL at it (default http://127.0.0.1:8425/mcp). REA does not install or launch JEB."} listener on 127.0.0.1:8425 during both sessions: no requests logged ``` ### Analysis or suspected cause Static proof from source. `AvailabilityPolicy` in `src/application/CapabilityInventory.ts` has a `jebAnalysisAvailability` field (line 43 at the tag, 57 on `main`), and the `jeb-provider` check (lines 360-368 at the tag, 470-478 on `main`) reports the tools available only when that field's status is `available`. No other file under `src` names the field, so nothing sets it: the only per-engine availability input that `src/server/createServer.ts` (line 334 at the tag, 570 on `main`) passes to the session tools is `androidAnalysisAvailability`, and `src/server/registerSessionStatusTool.ts` (lines 64-70 at the tag, 68-74 on `main`) builds the `binary_session` policy from the base policy plus only `androidAnalysisAvailability`. With the field always unset, the check always takes its unavailable branch, whatever runs at `REA_JEB_MCP_URL`. By contrast, the Android entries come from `android.inspectAvailability`, which `createServer.ts` passes in. ### Additional context The ADB and Apktool tools are also misreported in the same result through a different path (they have no availability check at all); those are reported separately. Related but separate: #3008 asks `rea doctor` to report these providers.

bsakaguchi

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

closed this issue
added the
bug
label

bsakaguchi commented

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

Author

Owner

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

Delivered on main in fffb07419.

JEB live operation discovery was not wired into session capability reporting. Session/server composition now shares authenticated live per-operation probes, explicit SDK page requests and one owned discovery deadline.

Validation: Actual HTTP MCP SDK catalog tests cover paging, missing operations, repeated cursors, timeout and recovery; JEB engine compatibility was not exercised. Full exact-revision qualification passed.

@morluto commented on GitHub (Oct 14, 2026): Delivered on main in [fffb07419](https://github.com/morluto/rea/commit/fffb0741936067530d1ce9777461cd53e87398c2). JEB live operation discovery was not wired into session capability reporting. Session/server composition now shares authenticated live per-operation probes, explicit SDK page requests and one owned discovery deadline. Validation: Actual HTTP MCP SDK catalog tests cover paging, missing operations, repeated cursors, timeout and recovery; JEB engine compatibility was not exercised. Full exact-revision [qualification](https://github.com/morluto/rea/actions/runs/38629313022) passed.

bsakaguchi referenced this issue

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

[PR #1075] [MERGED] fix(metadata): stop schema changes churning generated skill evidence #2624

bsakaguchi referenced this issue

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

[PR #1086] [MERGED] fix(build): make catalogs and packaged skills generated outputs #2634