Outbound MCP client should handle input_required / multi-round tool calls

[serge-ivo]

Problem

The outbound MCP connector assumes a remote call returns a final JSON-RPC result or error. It unwraps normal MCP tool results, but does not handle multi-round interactions where the MCP server needs more input from the user before completing the call.

Current MCP supports input-required style results / multi-round trip requests for cases like:

• missing required user input
• confirmation before a risky action
• choosing among app resources
• provider-specific consent/step-up prompts

Without this, a PAGS MCP agent may connect successfully but fail or hallucinate when a remote server asks for more information.

Expected behavior

When a remote MCP call returns input-required data, PAGS should pause the tool call, surface the request to the user, collect the answer, and retry/resume the original call with the provided input responses.

Acceptance criteria

• Outbound MCP client detects input-required responses instead of treating them as final opaque data.
• Chat UI can render the requested inputs/confirmation clearly.
• User answer is routed back to the original remote call.
• The resumed call preserves endpoint, remote tool, args, auth context, and audit trace.
• Timeouts/cancel paths are clear.
• Sensitive input requests are handled carefully and are not stored in memory or logs unless explicitly safe/redacted.
• Tests cover successful resume, user cancellation, timeout, and malformed input-required payload.

Related

• Outbound MCP connector needs OAuth/browser sign-in for authenticated MCP servers #258: OAuth/browser sign-in for authenticated MCP servers
• MCP agent instances should import remote MCP tools as first-class callable tools #261: first-class remote tools
• Outbound MCP consent should be per server and per remote tool, not one global write grant #262: per-tool consent

Code pointers

• workers/api/src/lib/connectors/mcp.ts
• workers/api/src/routes/instances.ts
• store/console/src/pages/InstanceDetail.tsx

[serge-ivo]

Not reached this run (capacity went to #286). Leaving open, with one finding worth recording before anyone builds it.

Check the premise first. This ticket describes "input-required style results / multi-round trip requests" as something "current MCP supports". Across the four protocol revisions this client speaks (SUPPORTED_VERSIONS — 2026-07-28, 2025-11-25, 2025-06-18, 2025-03-26), the mechanism for a server needing more from the user is elicitation — a server→client request, which requires the client to declare the capability and to be able to receive server-initiated messages. This client sends clientCapabilities: {} (see withRequestMeta and the legacy initialize params) and is strictly request/response over one POST. A server therefore cannot ask it for anything today, by construction. So step one is confirming which wire shape is actually being targeted: declared elicitation, or a server that returns a sentinel payload inside an ordinary tools/call result. They are very different builds and only the second works over the current transport.

If it is elicitation, the transport assumption changes: modern-era calls are one stateless POST, and legacy-era calls hold no open channel after the response. Receiving a server-initiated request means either SSE stream handling that outlives the response (parseRpcBody today drains the stream and returns the last frame carrying a result or error — it discards everything else) or a resumable session. That is a transport change, not a handler change.

Whichever shape: the pause/resume machinery already exists and should be reused rather than reinvented — browserHandoff / browserHandoffStatus / browserResume with reasons challenge|stuck|needs_input, and the console's openNeedsInput. The apply pipeline's needs_input handoff is exactly this problem solved once.

The constraint that must not be relaxed: this ticket's own acceptance criteria say sensitive input requests must not be stored in memory or logs. That is already the connector's standing rule — agent_events records argument key names and byte counts only, never values, because arguments to an arbitrary remote tool are the most PII-dense thing this connector touches. A resumed call must preserve endpoint, tool, args, credential context and traceId without the answer becoming a second copy of the user's data on the way through. Note also that a resume re-enters mcp_call_tool, so it re-checks #262 consent and (since #286) re-resolves the credential for that endpoint — both correct, and both must stay on the resume path rather than being skipped as "already authorized".

[serge-ivo]

The premise does not hold. Confirmed against the code, not assumed. Partial work shipped in 4062a07; leaving open, because what remains is a transport change and should be scoped as one.

What was checked

The previous comment was right to say "check the premise first", and the answer is that a remote MCP server cannot ask this client for anything today, by construction, in three independent ways. Any one of them alone is fatal to elicitation:

1. We declare no capability. withRequestMeta sends io.modelcontextprotocol/clientCapabilities: {}, and the legacy initialize params send capabilities: {}. A spec-abiding server may not send elicitation/create at all.
2. The modern era has no server→client channel. A 2026-07-28 call is one stateless POST: one request, one answer, no session, nothing left open. There is nowhere for a server request to arrive.
3. The legacy era would deadlock. Answering means POSTing a JSON-RPC response on a second request while the server holds the original stream open waiting for it. rpc() does await safeFetch(...) then await res.text() — it does not return until the server closes the stream, and the server will not close the stream until it gets the answer. Neither side moves. parseRpcBody additionally drains the stream and keeps only the last frame carrying a result/error, discarding everything else, so even observing the request mid-stream is not possible on the current reader.

So the ticket's "current MCP supports input-required style results" describes elicitation, which is a server→client request, not a sentinel inside a tools/call result. There is no sentinel shape in any of the four revisions this client speaks (SUPPORTED_VERSIONS). Building against an invented one would be inventing a protocol.

What shipped instead

Not a fake, and not nothing: the failure is now honest. Before, a stream carrying only an elicitation/create frame parsed to nothing answering, so finish() reported "MCP server returned an unparseable response" — which sends the user to debug a transport that is working perfectly. The same message arriving as a bare JSON body was worse: it parsed as a response with no result, and finish() returned success with a null payload — a call that silently did nothing, reported as done.

serverRequestIn() now recognises a server→client request (a method with an id; a notification has no id and is not an ask, so progress frames are unaffected — tested) across both framings, and the call fails with a new input_required failure class and this text:

The MCP server asked this client a question ("elicitation/create") instead of returning a result, so the call did NOT complete and nothing was submitted. […] Supply the missing values as tool arguments if the tool accepts them, or ask the server's operator for a non-interactive way to make this call. Do not report this as done.

That last sentence is the point of the ticket as far as it can be reached without a transport change: the failure mode named in the description is the agent hallucinating a submission, and an opaque error is exactly what invites that. connectionStatusFor maps it to unsupported_protocol — deliberately reusing the existing status rather than inventing a ninth, since it is a missing client capability seen from the other side, and a console that has never heard of a new status renders "unknown" instead of "protocol shortfall".

Trace rows carry failure: "input_required", so how often real servers actually try this is now measurable — which is the number that should decide whether the rest is worth building.

What is left, if it is wanted

This is a transport change plus a capability declaration, not a handler change, and it is a materially larger piece of work than the ticket implies:

• Declare elicitation in clientCapabilities — and only then, because declaring it while unable to answer is worse than not declaring it.
• A reader that surfaces a server request from an SSE stream without draining it, and a way to POST the response on a second request while the first is still open. In a Worker that means not await res.text().
• Or a resumable session, which is the same amount of work in a different place.
• The pause/resume machinery should be reused, not reinvented: browserHandoff / browserHandoffStatus / browserResume with reason needs_input, and the console's openNeedsInput. The apply pipeline solved this exact human-in-the-loop problem once already.
• The constraint that must not be relaxed: a resumed call re-enters mcp_call_tool, so it re-checks Outbound MCP consent should be per server and per remote tool, not one global write grant #262 consent and re-resolves the MCP bearer/OAuth credentials should be scoped by endpoint, not one global mcp token #286 credential — both correct, both must stay on the resume path rather than being skipped as "already authorized". And the answer itself is the most PII-dense thing the connector would ever hold: agent_events records key names and byte counts only, and a resume must not become the place that finally writes a value down.

Note also that the modern era makes this impossible in principle, not merely unimplemented — a stateless POST has no back-channel. So even a full build only ever covers legacy-era servers, and it gets narrower as servers upgrade. That is worth weighing before anyone starts.

[serge-ivo]

Verdict: not yet. Leaving open, unbuilt, with the trigger that should reopen it written down.

The previous run's premise check holds — I re-verified all three against current main rather than taking them on trust, and then went looking for the number that was supposed to decide this.

The three blockers, re-confirmed

1. We declare nothing. withRequestMeta sends "io.modelcontextprotocol/clientCapabilities": {}; legacyCall's initialize sends capabilities: {}. A spec-abiding server may not send elicitation/create at all.
2. Modern era has no back-channel. modernCall issues exactly one rpc(), and rpc() is one safeFetch POST. No session, nothing left open, nowhere for a server request to arrive.
3. Legacy would deadlock. rpc() does await safeFetch(...) then await res.text(). It cannot return until the server closes the stream; the server will not close it until it gets the answer. Neither side moves. And parseRpcBody consumes the whole body before returning anything, so the ask is not even observable mid-stream on the current reader.

The measurement, which is the part that changed

The last comment said the input_required class makes the frequency measurable and that number should decide it. So I went and read it. The answer is more useful than a count:

The classifier has measured nothing, because nothing has run through it.

• The API Worker carrying input_required went live on the deploy at 2026-08-06 ~21:39Z (run 31128434379, 17ec147, which contains 4062a07).
• The most recent outbound MCP call in the trace is 2026-08-06 08:28:19Z — roughly 13 hours before that deploy.

So the zero is "no observation window yet", not "measured zero". Building a transport now would be speculating against an instrument that has not yet been read once.

What the pre-classifier history does say

Every outbound MCP call the trace holds, against two real independently-operated servers (mcp.proagentstore.online, mcp.freeagentstore.online), across tools/list and tools/call: no server has ever attempted a server→client request. Failures are no_credential and one unparseable.

That single unparseable is worth naming, because it is the exact class that would have masked an elicitation before serverRequestIn existed — an SSE stream carrying only an ask parsed to nothing and reported as an unparseable response. It carries status: 522, a Cloudflare origin timeout with an empty body. So it is attributable, and there is no retrospective candidate hiding in the one place one could have hidden.

Also relevant: the observed era is modern / 2026-07-28. That is the era where elicitation is impossible in principle, not merely unimplemented. A full build only ever covers legacy-era servers, and that population shrinks as servers upgrade — so the work gets less valuable over time, which is an unusual and decisive property for a "build it now" argument.

What is already true, and is most of the user-facing value

The failure mode the ticket description is actually about is the agent hallucinating a submission. That is fixed. 4062a07 made the ask legible: previously an SSE elicitation frame read as "unparseable response" (sends the user to debug a working transport) and the same message as a bare JSON body reported success with a null payload — a call that did nothing, narrated as done. Now it fails with input_required and text ending "Do not report this as done."

An agent that stops and says why is not the feature this ticket asks for, but it is the part that stops the damage.

The trigger to reopen

Not a date — a fact. A non-zero count of failure: "input_required" rows in agent_events against a server someone actually wants to use. One real occurrence turns this from speculative transport work into a specific server with a specific need, and it also tells us which era that server speaks, which decides whether a build is even possible for it.

If it does come back, the scope in the previous comment stands and none of it is negotiable: declare the capability only once answerable, a non-draining SSE reader (in a Worker, that means not await res.text()) or a resumable session, reuse browserHandoff/browserResume with needs_input rather than reinventing it, keep the #262 consent check and the #286 per-endpoint credential re-resolution on the resume path rather than skipping them as "already authorized" — and the answer value is the most PII-dense thing this connector would ever hold, so a resume must not become the place that finally writes one down.

(CI note: no CI run verified anything in this comment — Actions fired no runs for the last commits. The evidence here is production trace data read through the live API, plus source re-read at main.)

[serge-ivo]

Already built — 5d8e497 on main, deployed. Verified against the acceptance criteria and against production; closing.

Picked this up to build it and found it built. The last comment here ("Verdict: not yet") was written before 5d8e497 landed, and no one came back to update the ticket, so recording the check rather than repeating the work.

The premise, re-verified once more

All three blockers still hold at main, and 5d8e497 did not pretend otherwise — it did not touch the transport. withRequestMeta still sends clientCapabilities: {}; modernCall is still one stateless POST with no back-channel; rpc() still cannot return before the server closes a stream it will not close without an answer. The commit adds a fourth reason no transport change fixes: a human takes minutes, and no Worker request may wait for one.

So it does what the acceptance criteria ask in their own words — "retry/resume the original call with the provided input responses" — instead of the in-band answer the framing implies. The ask is parsed, the call pauses, one pending row holds the remote tool's arguments envelope-encrypted, the owner answers above the chat thread, and the answer re-sends the original call with the values merged.

Acceptance criteria, checked against the code and tests

Criterion	Where
Detects input-required instead of treating it as final data	serverRequestIn (both SSE and bare-JSON framings), failure: "input_required", its own mcp.input_required event
Chat UI renders the requested inputs	store/console/src/components/McpInputRequests.tsx, mounted in InstanceDetail
Answer routed back to the original call	resume re-enters mcp_call_tool with mergeElicitedArgs
Resume preserves endpoint, tool, args, auth context, trace	test: "resumes the original call, preserving endpoint, tool, args, auth and trace"
Timeout / cancel paths clear	30-min deadline derived from the clock, not from a sweeper; tests for refuse-after-deadline, expire-on-list, and cancel-sends-nothing
Sensitive input not stored in memory or logs	no column for the answer; trace records field names and a byte count only; held arguments are ciphertext (JSON.stringify(row) asserted not to contain an argument name)
Tests cover resume, cancellation, timeout, malformed	all four, plus MAX_ROUNDS, double-click one-shot claim, and cross-tenant 404

The non-negotiable from the earlier comments survived: the resume re-checks #262 consent and re-resolves the #286 per-endpoint credential rather than skipping them as "already authorized", with a test that revokes the grant between the ask and the answer and asserts nothing reaches the server. The elicitation capability is still not declared, which is right while an in-band answer is impossible.

Production

GET /v1/instances/:id/mcp/input-requests answers 200 {"requests":[]} live, so migration 0094 and the read path are deployed and healthy.

What is not verified, and cannot be yet: no remote server has ever elicited against this client. The last outbound MCP call in the trace is still 2026-08-06 08:28:19Z, and there are still zero failure: "input_required" rows. So the loop is proven by a full-stack test (real connector, real store, real routes; only network, clock and D1 doubled) and not by a live server. The pause/resume design also means the first real one is recoverable rather than lost, which is the difference from the state this ticket was filed about.

Closing as delivered. If a real server ever elicits and the loop misbehaves, that is a new bug with a live reproduction — worth a fresh ticket rather than reopening this one, whose question ("can we handle it at all") is answered.