Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Clarify caller lifecycle for non-autosubmit declarative tools

Open
  • Is something wrong?
#307 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
javascript
Domain
api, backend-api-design

Research direction

Read the related discussions #21, #139, #165, and #196, then trace how declarative form population and submission are represented to browser-to-agent callers. The issue does not identify source files or tests, so first locate the tool invocation and response lifecycle entry points. Done means callers can identify the populated, awaiting-submission state while the final tool result still reflects submission or cancellation.

Written by the indexing model from the issue text.

Description

declarative

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 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 #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

  • #21 identifies the need for agents to display a waiting state and adjust their timeouts during in-page elicitation.
  • #139 discusses the lack of feedback after declarative form population and before submission.
  • #165 discusses how user-interaction requests should reach remote and non-browser clients.
  • #196 proposes returning an execution object immediately, with progress events and a separately awaited result.
Dominant language
Bikeshed
Stars
4.7k
Forks
328
Avg merge
1d 21h
Merged PRs (30d)
15

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from webmachinelearning/webmcp

All issues in webmachinelearning/webmcp

Similar issues

More Backend & API Design issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.