Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Clarify caller lifecycle for non-autosubmit declarative tools

Đang mở
  • Có gì không ổn?
#307 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
javascript
Lĩnh vực
api, backend-api-design

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.
Ngôn ngữ chính
Bikeshed
Star
4.7k
Fork
328
Merge trung bình
1 ngày 21 giờ
Pull request đã merge (30 ngày)
15

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của webmachinelearning/webmcp

Tất cả issue của webmachinelearning/webmcp

Issue tương tự

Thêm issue về Backend & API Design

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.