Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#351 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
javascript
Ambito
api, web-dev

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Bikeshed
Stelle
4.7k
Fork
328
Merge medio
2g 15h
PR unite (30g)
16

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di webmachinelearning/webmcp

Tutte le issue di webmachinelearning/webmcp

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.