TinCan WebMCP

Number of agent on websites is growing fast but they have no way to report issues. TInCan is a tool for agents to report website issues and unexpected behavior with otel compatible evidence attached.

Comment

AI agents now use websites the way people do: navigating, filling forms, changing settings, checking results. When something goes wrong there is no site-native way for the agent to tell the website what happened. That covers every kind of issue an agent runs into: wrong results, unexpected behavior, failed actions, slow responses, and UI state that does not match what the tools report. The hardest cases are invisible to monitoring: a request returns 200 OK, there are no JavaScript errors, performance looks healthy, and yet the site completed the wrong action.

WebMCP is the right layer for this because the agent already has a structured, browser-mediated channel into the page. TinCan adds one tool to that channel, report_site_issue, so the agent can report any problem to the site it happened on, with a category, a severity, and what it expected versus what it observed. No screen-scraping and no separate support integration.

How it improves the user experience

For the person using the agent: issues get reported and tracked instead of silently ignored or retried. The agent can verify a mutation with a read-only tool, notice a mismatch, and file a precise incident. Timeouts, errors, and slow operations can also be reported

For the site owner: every report arrives with sanitized, bounded diagnostic evidence from the site's own browser flight recorder, metrics, and traces that map straight into an existing OpenTelemetry pipeline. No more "the AI said it didn't work" tickets with nothing attached.

For privacy: Request and response bodies, credentials, cookies, storage, form values, keystrokes, DOM contents, and screenshots are never captured. The raw evidence is never returned to the agent, only a confirmation and an incident ID.

What people and agents can accomplish together

A person hands a task to an agent. The agent performs it through the site's WebMCP tools, verifies the persisted result, and whenever the site misbehaves it reports the category and severity, what was expected and observed, and which operation was involved. The site turns that into an incident with the technical context the engineering team needs. The human gets an honest outcome, the agent gets a way to escalate, and the site owner gets a bug report that arrives with evidence rather than a shrug. None of the three could do this alone before.

Implementation approach

  • Tools are registered with document.modelContext.registerTool, following the WebMCP Draft Community Group Report. The demo SaaS exposes add_licenses, remove_licenses, get_subscription, and export_usage_report. The TinCan package registers report_site_issue.
  • report_site_issue accepts a category (wrong_result, unexpected_behavior, action_failed, network_failure, performance, ui_state_mismatch, other), a severity (info, degraded, blocking), a summary, and the expected and observed outcome. Agent input is treated as untrusted and cannot change what the site captures.
  • The demo contains two deliberate defects in two different categories. A wrong result: adding n licenses persists n+1 while every request succeeds. A network failure: removing a license returns a 504 and leaves state unchanged. The agent detects both by reading back state, then reports them.
  • A browser flight recorder built on OpenTelemetry fetch/XHR instrumentation, with a Resource Timing fallback, keeps the last 120 seconds of signals. On report, the site attaches a bounded, sanitized slice as logs, metrics, and traces.
  • API validates and classifies each incident, sanitizes again server-side, and stores it. An admin view lets an engineer inspect incidents and their OTLP-compatible evidence.
  • A developer harness at /agent discovers tools with getTools() and executes them with executeTool() for deterministic testing.

Try it

Built With

Share this project:

Updates

Submission history