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

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

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

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

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

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
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時間
マージ済み 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 を短くまとめたダイジェスト。