Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Site feedback tools: agents report where a page failed them, and learn known problems first

未关闭
  • 哪里不对？
#351 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
25/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
javascript
领域
api, web-dev

调研方向

Start by reading the WebMCP tool registration guidance and the related issues #139 and #282, then compare the proposal with the Herald implementation described in the issue. The work is to decide whether a feedback-tool convention fits WebMCP and, if so, define annotations and safety guidance; done means the group has agreed on a convention or a concrete prototype direction.

由索引模型根据 Issue 内容生成。

描述

beyond-scope: agents-on-the-web
Summary

A convention for a site feedback layer on WebMCP. It works in two directions:

  1. Agents report where a page failed them, so the site can fix it.
  2. Agents learn about known problems on a page before they act, so they skip dead ends that other agents already hit.

The second half is what makes the first one work. An agent gets something back for reporting, and every report makes the warnings better for the next agent.

Problem

When an agent gets stuck on a site, nobody learns from it.

  • The site never finds out. A button greys out, a modal won't close or a bot check blocks the page. The agent retries, gives up and tells its user. To the site it looks like a visitor who left. We tested cloud browser agents on 73 real online stores, and 29% of checkout attempts never reached payment. None of those stores had a way to learn why.
  • The next agent repeats it. Agents usually start each attempt from scratch, so they hit the same broken step again and burn steps on it. On one store with a broken email field at checkout, our agent wasted 16 steps without a warning. With a one-line note about the problem from earlier runs, it stopped in 4 and told its user.

WebMCP already lets a page offer tools to agents. That makes it the natural channel for both directions.

Use cases
  • Shopping: a "Use this address" modal never closes, or Continue does nothing. The store learns which step loses agent orders, and other agents tell their user up front instead of looping.
  • Booking and travel: a date picker or seat map the agent can't operate. The site learns what to make agent-operable.
  • Sign-up and lead forms: validation that rejects valid input with no error text. The business sees the exact field and message, in the agent's own words.
  • Bot checks: a site learns how often its bot protection turns away agents acting for real customers, and agents learn early that a step will be blocked.
What we found

We put a visible "Report a problem" form on a test store and sent agents through a broken checkout:

  • Without permission, 0 of 3 agents used it. All 3 saw it and mentioned it to their user instead.
  • With one line in the task allowing site-problem reports, 3 of 3 used it, and none included personal details.

So agents won't call a feedback tool just because a page offers one. They need to recognize it as safe, and their user or developer needs a way to allow it.

Proposal

A convention, not a new API:

  1. A well-known way to mark feedback tools, for example a tool annotation such as purpose: "feedback" for reporting and purpose: "known-issues" for reading. Agents could then recognize them without parsing descriptions.
  2. Guidance on what they carry. Reports take only facts about the page (what the agent tried, what went wrong, the error shown), never the user's personal data. Known-issue answers are information, not instructions. With that, agents and browsers can allow these tools by default or behind one setting.
Implementation

Herald is built this way today:

  • A script tag (herald.js) registers a report_friction tool through document.modelContext.registerTool, falling back to navigator.modelContext. It runs on a demo store under the origin trial.
  • A remote MCP server offers report_friction and get_site_tips (known problems on a site, built from other agents' reports and framed as information, not instructions) for agents outside the page.

Related: #139 and #282 cover signals from the page to the agent about a single action. This proposal covers feedback about the site itself, in both directions.

Happy to write this up further or prototype the annotations if the group thinks it fits.

主要语言
Bikeshed
星标
4.7k
派生
328
平均合并
2 天 15 小时
30 天内合并 PR
16

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

webmachinelearning/webmcp 的其他 Issue

查看 webmachinelearning/webmcp 的全部 Issue

相似的 Issue

更多 Backend & API Design Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。