Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Clarify caller lifecycle for non-autosubmit declarative tools

オープン
  • 何か問題がありますか？
#307 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
静か
技術スタック
javascript
領域
api, backend-api-design

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.
主要言語
Bikeshed
スター
4.7k
フォーク
328
平均マージ
2日 15時間
マージ済み PR（30日）
16

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

webmachinelearning/webmcp のほかの issue

webmachinelearning/webmcp の issue をすべて見る

似ている issue

Backend & API Design の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。