mcp-stdio-fail-closed c3 (follow-on): the stdio transport now answers, but registers ZERO tools — advertises `tools` capability, `tools/list` → -32601

[baozhoutao]

Follow-on to #7645, found by re-testing it. #7645 is genuinely fixed and this is not a regression of it — the stdio transport is no longer deaf: initialize now answers immediately (it used to time out with zero bytes on stdout), and resources/list, resources/templates/list and resources/read all answer. The five fail-closed clauses were each re-proved from scratch rather than carried over, and they all hold. What the fix made visible is a second, independent gap that was previously masked by the deafness.

This is not an RLS bypass. The one principal-bound read path stdio does expose (the record resource template) was driven on both sides and the gate held: a member key reads its own row in full and gets not found for another principal's row; an admin key reads both — matching REST row-for-row.

Symptom

The stdio server's initialize result advertises capabilities.tools: {}, but the tool surface is empty:

• tools/list → -32601 Method not found
• every tools/call → -32601 Method not found
• across 4 fresh boots, and on retry at +3 s and +8 s after notifications/initialized (ruling out a registration race)

Decisive isolation: in the same process, with the same osk_ key, the HTTP transport (POST /api/v1/mcp) returns all 11 tools. So the bridge, the key, and the principal are all fine — the tools are simply never registered on the stdio server.

Boot log corroborates: [MCP] Bridged 4 resource endpoints, Agent prompts bridged, [MCP] Bridged 0 skill prompts — and no tool-bridging line at all.

Root cause

The object/action tool surface is built per HTTP request, on a throwaway server, and never on the long-lived stdio server.

packages/mcp/src/mcp-server-runtime.ts — handleHttpRequest() constructs a fresh McpServer per request and registers the tools onto that instance:

// mcp-server-runtime.ts:1157,1166 — inside handleHttpRequest()
registerObjectTools(server, opts.bridge, opts.toolOptions);
...
registerActionTools(server, opts.bridge as McpActionBridge, opts.toolOptions);

The long-lived server used by stdio (this.mcpServer) only ever receives tools through bridgeTools(toolRegistry) (mcp-server-runtime.ts:663), which is a different surface — the AI service's function-calling ToolRegistry, wired in packages/mcp/src/plugin.ts:138:

const aiService = ctx.getService<IAIService & { toolRegistry?: ToolRegistry }>('ai');
if (aiService?.toolRegistry) this.runtime.bridgeTools(aiService.toolRegistry);

The showcase registers no ToolRegistry tools, so zero tools land on the stdio server. registerObjectTools/registerActionTools are imported only at line 9 and called only from inside handleHttpRequest — there is no path that reaches them for stdio.

The -32601 alongside an advertised tools capability is consistent with this: the MCP SDK only wires the tools/list handler once at least one tool is registered, while the capability object is declared statically at construction.

Reproduction

1. Boot the showcase with stdio MCP enabled: node packages/cli/bin/run.js serve -p <port> --dev with stdio: ['pipe','pipe','pipe'], OS_MCP_STDIO_ENABLED=true, and a valid osk_ key.
2. Write JSON-RPC initialize, then notifications/initialized, then tools/list to the child's stdin.
3. Against the same process, POST /api/v1/mcp with the same key and body {"jsonrpc":"2.0","id":1,"method":"tools/list"}.

Expected both transports expose the same tool surface (11 tools).
Actual HTTP returns 11 tools; stdio returns -32601 Method not found, while its own initialize result claims capabilities.tools: {}.

Blast radius

Every MCP client that speaks stdio (the transport most desktop MCP hosts default to) sees an ObjectStack server with resources and prompts but no tools — it cannot query or mutate a single object. The 17/17 unit pins stay green because they exercise handleHttpRequest and bridgeTools separately, never asserting the two transports agree on the tool surface.

Downstream in the checklist

ai.mcp-stdio-fail-closed clauses 4/5 are blocked by this (no aggregate to reconcile against on stdio). Clause 5 has a separate fixture gap worth recording: the factory showcase has no readable: false FLS-masked field anywhere (repo-wide grep is zero), runtime authoring of one is refused 403 NOT_OVERRIDABLE, and the scratch-artifact escape hatch fails because the connector provider factory comes from objectstack.config.ts.

Suggested shape (not prescriptive)

Register the object/action tools on the long-lived server too — either by hoisting the registerObjectTools/registerActionTools pair into a shared wireTools(server, bridge, opts) called from both start() (stdio branch) and handleHttpRequest(), or by having stdio route through the same per-request assembly. Whatever the shape, the gate that keeps this from coming back is a test that asserts the two transports expose the same tool names for the same bridge — the current pins can't see a divergence.

Source

Extracted from the checklist retest run (framework b602d536, console 6314e87f2d49), re-testing #7645.

[hotlong]

Triage: lands in packages/mcp (mcp-server-runtime.ts — object/action tool registration happens only inside handleHttpRequest()'s per-request server; the long-lived stdio server only ever receives the AI-service ToolRegistry bridge). Re-routed domain:ai → domain:cli: packages/mcp is domain:cli per the lane table, and domain:ai is not a lane. Queued pm:queue.

Rationale: concrete located defect, 4× repro, and the same-process HTTP-vs-stdio isolation is decisive. The acceptance gate should include the transport-parity test the card names (both transports expose the same tool names for the same bridge) — the current 17/17 pins structurally cannot see this divergence.

Serial note for the cli seat: #7915 (dispatched, in flight) touches the stdio/os serve surface of the same package family — check its claim's file surface before batching.
Size/model suggestion: M, opus.

---

Generated by Claude Code

[hotlong]

Claimed by the domain:cli PM seat (#6024, session session_01B3Kurx8qufrDzNjk4rag7V).
Branch: claude/issue-8034-stdio-mcp-register-tools · dispatch: mode:subagent, model: claude-opus-5.

Third link in the stdio MCP chain: #7645 made the transport answer (PR #7914); #7915 (in flight) stops the banner corrupting the frames; this one is why a client that gets a clean connection still cannot do anything. The three only add up to a working os serve stdio session together — landing two of three leaves the feature broken in a way that reads as "MCP is broken".

The defect class is one this lane has closed twice today

Advertising the tools capability while tools/list answers -32601 is a dishonest self-report: the server claims something it does not serve. Exactly #7939 (handlerReady: true for a slot with no handler) and #7602 (capabilities.search enabled with no route), on a third surface. The governing contract is the same — #2462 / ADR-0076 D12: advertise what you actually serve.

Ruling

Register the tools — the machinery exists (registerToolFromDefinition / registerTool at mcp-server-runtime.ts:668/:677/:684); find why the stdio path reaches it with an empty set while the HTTP path does not. Diagnose before patching: an empty registry, a registration that runs after the transport is already serving, and a filter that drops every tool are three different bugs with the same symptom.

⛔ Do not "fix" this by dropping the tools capability advertisement. That would make the self-report honest and the feature useless — the opposite of what the chain is for. If registration turns out to be genuinely impossible on this transport, stop and report; that inverts the card and is a ruling, not a patch.

Pins

• tools/list over the stdio transport returns a non-empty set — assert the tool names, not just "no error".
• The advertised capability and the served surface agree: assert them against each other, not as two literals. That is the pin that stops this class returning.
• A tool is actually invocable over stdio end-to-end. tools/list succeeding while every call fails would be the same defect one layer down.
• Reverse-verify: revert the registration, confirm the test fails with the empty set / -32601 — the defect reproduced, not a compile error.

Serial constraint

#7915 is in flight on packages/cli/src/commands/serve.ts (banner → stderr). Different file from packages/mcp/**, but the same feature, and both are exercised by the same end-to-end stdio session. If your test boots a real os serve, expect banner noise on stdout until #7915 lands — ⛔ do not "fix" that here and do not weaken your assertion because of it. Note it and move on.

---

Generated by Claude Code