Clarify caller lifecycle for non-autosubmit declarative tools
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 功能
- 描述清晰度
- 基本清楚
- 活跃度
- 冷清
- 技术栈
- javascript
调研方向
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 内容生成。
描述
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 [email protected]@modelcontextprotocol/[email protected]- 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:
- Navigate to the checkout.
- Invoke
select_payment_methodwithcard. - Discover the resulting
fill_payment_formtool. - Invoke it with Stripe test card and billing data.
- Bound the raw
tools/callexternally 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
124because of the external GNU timeout - produced exactly zero bytes on stdout
- did not return an MCP result or timeout error
- received no
WebMCP.toolRespondedevent 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
ToolExecutionhandle 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
- 平均合并
- 1 天 21 小时
- 30 天内合并 PR
- 15
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
webmachinelearning/webmcp 的其他 Issue
-
Say how an agent should weigh annotations that the page wrote about itself可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 2/5 1-3 小时 新手友好度 72/100
webmachinelearning/webmcp#353 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 67/100
webmachinelearning/webmcp#343 · 1 个 reaction ·
维护者通常 1 天内回复
-
Agenda+ i18n-tracker
难度 2/5 1-3 小时 新手友好度 75/100
webmachinelearning/webmcp#273 · 3 条评论 ·
维护者通常 1 天内回复
-
a11y-tracker Agenda+
难度 2/5 1-3 小时 新手友好度 67/100
webmachinelearning/webmcp#272 · 4 条评论 · 2 个 reaction ·
维护者通常 1 天内回复
-
enhancement
难度 2/5 1-3 小时 新手友好度 68/100
webmachinelearning/webmcp#234 · 5 条评论 ·
维护者通常 1 天内回复
查看 webmachinelearning/webmcp 的全部 Issue
相似的 Issue
-
area:editor bug issue-form:bug P0 platform:windows review: low
难度 2/5 1-3 小时 新手友好度 64/100
1lck/Lithe-IDEA#1388 ·
维护者通常 1 天内回复
-
fix(api): isToolAuditEnabled swallows database read errors on auditToolOperations without logging未关闭area: backend bug priority: low
难度 2/5 1-3 小时 新手友好度 82/100
snapotter-hq/SnapOtter#3238 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 75/100
open-webui/open-webui#32805 ·
维护者通常 1 天内回复
-
rig up --plan times out after 5 s and reports an UNKNOWN outcome while the daemon completes the plan未关闭
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复