Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Clarify caller lifecycle for non-autosubmit declarative tools

Aperta
  • Qualcosa non va?
#307 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
javascript
Ambito
api, backend-api-design

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
Bikeshed
Stelle
4.7k
Fork
328
Merge medio
2g 15h
PR unite (30g)
16

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di webmachinelearning/webmcp

Tutte le issue di webmachinelearning/webmcp

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.