Sign up
View stargazers13Sign up

feat(mcp): expose pending user questions#10556

merged1
agents/mcp-thin/queue
agents/mcp-thin/questions
openedSep 7, 2026byJJulius Marminge
4 files changed
View on GitHubTwo-way sync enabledPR last imported 3d ago

Part 6/16 of the shared-core and MCP stack. Based on #10555. Next: #10557.

Expose pending user-input requests and dispatch answers through the existing runtime-request.respond command.

Approval requests are excluded. Existing live/message response handling and validation stay in orchestration; no parallel question-response state machine.

MCP-only rebuild of #8716, preserving attribution to Julius Marminge's original work. Original branches remain available for separate service follow-ups.

Validation: The composed stack passes 94 tests across 12 focused files, including shared core MCP and real MCP/V2 integration, attachment intake, project RPC/service contracts, and client model command selection. Server/contracts/shared/client-runtime typechecks and targeted format/lint/diff checks pass. New behavior coverage lives with the shared operation; no per-tool mock suite was added. Current-head CI is shown below.

Layer size: 4 files, +110/-0. No domain-service production implementation or documentation files change in this MCP layer.

Prepared with Codex in the OpenAI agent runtime.

Note

Add MCP tools to list, read, and respond to pending user questions in threads

  • Adds three read/write MCP tools (t3_pending_request_list, t3_pending_request_read, t3_pending_request_respond) to the thread toolkit, with handlers that locate pending user-input requests and dispatch answers via the existing runtime-request.respond command
  • Adds a readQuestion helper that validates a runtime request is a pending user-input request and finds its matching question turn item, raising an invalid-request failure when either is missing
  • Pre-approves the list and read tools for Claude read-only sessions; the respond tool is excluded from the read-only allowlist
  • Adds presentation labels for all three new tools in the display registry
  • Risk: approval/permission requests are excluded by the user-input kind filter, so callers cannot use these tools to approve permission requests

Macroscope summarized 51483ab.

MmacroscopeappBotSep 7, 2026
Synced from GitHub

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This adds three production MCP tools that expose pending user questions and let callers submit answers, including a new mutating runtime-request workflow and expanded Claude read-only access. The implementation is localized and additive, but the coordinated user-facing capability and response side effect warrant human review.

No code changes detected at 51483ab. Prior analysis still applies.

You can add or adjust custom eligibility rules. Learn more.

Ggithub-actionsBotSep 7, 2026
Synced from GitHub

Thread transfer impact

⚠️ The latest CI run did not produce a thread transfer result for 51483ab.

This comment will update automatically after the next completed run.

apps/server/src/mcp/toolkits/thread/handlers.tslines 65–92Outdated · 61205e4Open thread
……@@ -36,7 +37,59 @@ const dispatch = Effect.fn("mcp.dispatchThreadCommand")(function* (
89+ })
90+ .pipe(Effect.mapError(unavailable));
91+ return { sequence: result.sequence };
92+ }),
MmacroscopeappBoton lines 65–92Sep 7, 2026

These three handlers add new backend behavior (pending-request filtering, question lookup failure, and a runtime-request.respond dispatch), but no test exercises them — the thread toolkit currently has no test module and the integration test only invokes t3_thread_organize. Consider adding a focused test alongside the existing toolkit tests (apps/server/src/mcp/toolkits/core.test.ts or OrchestratorMcpToolkit.integration.test.ts) covering at least the respond path and the invalid_request case for a non-pending/unknown requestId, using test layers for ThreadManagementService rather than mocking the handler logic itself.

Posted via Macroscope — Effect Service Conventions

JJulius MarmingeSep 7, 2026

The maintainer explicitly requested shared MCP coverage rather than per-tool service-test duplication for this rebuild. These handlers reuse readThread/readWritableThread for scope and ceilings, the existing ProviderUserInputAnswers contract, and the existing runtime-request.respond command. The filter/lookup only selects pending user_input records; no response execution or provider state machine is introduced. Shared production registration/schema/capability/error tests and the existing real MCP/V2 integration remain in the stack; runtime response behavior remains tested with the service. No concrete faulty behavior was identified here, so no wrapper-only dispatch mock suite is being added.

MmacroscopeappBotSep 7, 2026

The service-layer coverage does not exercise these MCP handlers. Current shared MCP tests cover infrastructure only, and the integration suite does not invoke the pending-request tools. The requested focused MCP test—especially invalid_request plus the respond dispatch path—remains warranted.

Added 1 commit

  • feat(mcp): expose pending user questions51483ab