Clarify caller lifecycle for non-autosubmit declarative tools

[rgarcia]

I may be missing part of the intended browser-to-agent integration here.

When a declarative form does not have toolautosubmit, Chrome populates its fields and leaves the invocation active until the form is later submitted or canceled. That makes sense for a browser-native, human-in-the-loop flow.

Through a conventional MCP client, however, the tool call remains pending with no indication that field population succeeded or that submission is now awaited. From the caller’s perspective, this is indistinguishable from a tool that is stuck or whose promise never resolves.

Reproduction

I reproduced this against Stripe’s public test checkout using only published tooling:

• Chromium 151.0.7922.169
• chrome-devtools-mcp@1.8.0
• @modelcontextprotocol/inspector@2.5.0
• Stripe test checkout: https://buy.stripe.com/test_fZuaEW5UndC54Sy5gN6J200

Chromium was launched with:

--enable-features=WebMCP,WebMCPTesting,DevToolsWebMCPSupport
--remote-debugging-port=9222

Chrome DevTools MCP was attached with:

--browserUrl http://127.0.0.1:9222
--categoryExperimentalWebmcp

I then used Inspector CLI to:

1. Navigate to the checkout.
2. Invoke select_payment_method with card.
3. Discover the resulting fill_payment_form tool.
4. Invoke it with Stripe test card and billing data.
5. Bound the raw tools/call externally at 15 seconds.

The fill invocation was equivalent to:

gnutimeout 15s ./node_modules/.bin/mcp-inspector \
  --cli \
  --config inspector.json \
  --server chrome \
  --format json \
  --method tools/call \
  --tool-name execute_webmcp_tool \
  --tool-args-json "$FILL_ARGS"

The MCP command:

• exited 124 because of the external GNU timeout
• produced exactly zero bytes on stdout
• did not return an MCP result or timeout error
• received no WebMCP.toolResponded event during the observation window

The form had no toolautosubmit attribute.

Question

Is the intended browser-to-agent contract that external callers keep the tool call open until someone eventually submits or cancels the form?

If so, how should a caller distinguish this expected state from an arbitrary unresolved tool execution?

A terminal Completed result at the field-population boundary does not seem accurate because the form’s action has not completed. Some possible nonterminal approaches might be:

• return a ToolExecution handle immediately and expose the final result separately, as discussed in WebMCP tool execution progress report #196
• surface an explicit lifecycle signal such as awaiting_submission
• require browser-to-agent adapters to translate declarative activation into an elicitation or progress event while preserving the pending final result

I do not have a strong preference among these. The main issue is that the successful transition from “invoked” to “form populated and awaiting submission” is currently invisible to a conventional MCP caller.

Related discussions

• Elicitation #21 identifies the need for agents to display a waiting state and adjust their timeouts during in-page elicitation.
• Communicate Validation Errors to Agent Prior to Form Submission #139 discusses the lack of feedback after declarative form population and before submission.
• WebMCP elicitation via requestUserInteraction() (was: Human in the Loop support for non-browser clients) #165 discusses how user-interaction requests should reach remote and non-browser clients.
• WebMCP tool execution progress report #196 proposes returning an execution object immediately, with progress events and a separately awaited result.