Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#351 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
javascript
Área
api, web-dev

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Bikeshed
Estrellas
4.7k
Forks
328
Merge medio
2 d 15 h
PR fusionados (30 d)
16

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de webmachinelearning/webmcp

Todos los issues de webmachinelearning/webmcp

Issues similares

Más issues de Backend & API Design

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.