ScanWebMCP.com

See what AI agents can read, answer and call. Then let them act on the evidence.

Comment

Inspiration

The web is being rebuilt for AI agents, but most teams still cannot answer a basic question:

What can an agent actually do with our website today?

A manifest can claim that an integration exists. A script can mention WebMCP. An endpoint can return HTTP 200. None of those facts proves that an agent can discover a useful capability, understand its contract and invoke it safely.

WebMCP makes websites callable. A callable web needs observability.

We built ScanWebMCP.com to provide that missing layer: a public, evidence-backed scanner that shows what agents can read, answer and call across a website. The recursive idea is deliberate—ScanWebMCP uses WebMCP to make the emerging WebMCP ecosystem visible, testable and easier to improve.

What it does

Enter any public URL and ScanWebMCP runs a bounded scan across the site's agent-facing surface. It checks:

  • crawler and robots access;
  • server-rendered content and semantic structure;
  • llms.txt, Markdown and structured data;
  • OpenAPI and other documented API surfaces;
  • live MCP protocol handshakes and returned tools;
  • browser-registered WebMCP tools across relevant page contexts; and
  • whether the available capabilities are readable, useful and safe for an agent to call.

Every completed scan is placed on the Agent Surface Ladder:

Invisible → Readable → Answerable → Callable → Transactable

The result is not a decorative badge. It includes five dimension scores, the rubric version, source URLs, observation times, bounded evidence, a page-aware WebMCP inventory and ranked implementation opportunities.

The product already includes a live Observatory containing 511 public websites and 523 completed scans. It shows how agent readiness varies by sector while keeping the underlying method visible and versioned.

ScanWebMCP itself is available through several complementary interfaces:

  • a human-facing website and public result pages;
  • a REST API with a live OpenAPI 3.1 contract;
  • a four-tool product MCP server;
  • a separate two-tool documentation MCP server;
  • nine browser WebMCP tools;
  • a published Agent Skill and Codex plugin bundle;
  • ARD, MCP and RFC 9727 discovery documents; and
  • stable Markdown and llms.txt representations.

The durable product is the scanner and its evidence. The additional discovery formats make that same working product easier for different agents to find and use without guessing URLs.

Why WebMCP is essential

WebMCP is both the subject of the scan and the interface through which people use the result.

Without WebMCP, an assistant must scrape the visible interface, infer the meaning of score cards and locate evidence through page structure. With WebMCP, the page exposes the exact actions an assistant needs, with bounded schemas, descriptions and safety annotations.

Three tools are available across the site:

  • scan_agent_surface
  • get_ladder_definition
  • email_report

A scan result page adds six context-aware tools:

  • get_scan_findings
  • get_recommended_tools
  • get_webmcp_inventory
  • get_evidence
  • explain_opportunity
  • rescan

This is a non-trivial WebMCP implementation, not a single demo button. Tool availability changes with page context. Read-only tools return structured evidence from the page the person is viewing. Evidence and inventory calls enforce the report-access boundary. A re-scan is marked as consequential. Email delivery requires an address directly supplied by the human, while marketing updates remain a separate confirmed opt-in.

The agent can also update the shared visual state. When it opens a finding or opportunity, the human sees the same page move to the relevant evidence. The agent receives structured data while the person retains context and control.

A better human-agent experience

The user does not need to learn the report layout, inspect browser internals or translate scanner output into prompts.

They can simply ask:

Scan scanwebmcp.com and email the report to me.

The assistant selects the correct tools in sequence. It runs the scan, asks for an address if one was not supplied, respects the report gate, and delivers the signed report. It does not guess an email address or silently opt the user into marketing.

On the result page, the person can continue:

What did the scan find? Show me the evidence behind the weakest signal and explain the best opportunity.

The assistant reads the existing result rather than starting a duplicate scan, retrieves bounded evidence, opens the relevant section and explains the recommendation in the context of the site already on screen.

After deploying a fix, the person can say:

We changed the site. Re-run the scan.

The consequential rescan tool refreshes the shared result. What previously required developer tools, manual navigation, separate scanner output and human follow-up becomes one coherent human-agent session.

How we built it

ScanWebMCP is a Next.js 16 and TypeScript application deployed on Vercel, with Supabase Postgres for scans, evidence, browser context and invocation outcomes.

The scanning pipeline is deliberately bounded and evidence-first:

  1. It validates and pins public-network targets to defend against SSRF and DNS rebinding.
  2. It honours the target's robots.txt policy and discovers no more than six relevant same-origin pages.
  3. It inspects server-rendered content, crawler directives, structured data and machine-readable documents.
  4. It validates MCP endpoints through the real initialize and tools/list lifecycle rather than trusting a URL or status code.
  5. It launches a WebMCP-capable browser witness and observes the live registry across relevant page contexts.
  6. It normalizes tool schemas and annotations, preserving the first page on which each tool appeared.
  7. It stores the evidence and calculates a versioned Agent Surface Ladder result.

The website feature-detects document.modelContext and registers tools with bounded input schemas, explicit descriptions and standards-aligned annotations. External website evidence is marked as untrusted content. Invocation telemetry distinguishes successful, refused and errored outcomes instead of treating a safe refusal as success.

The same core service powers the website, REST API, MCP servers and WebMCP tools. That keeps behavior consistent across interfaces and prevents the browser demo from becoming a disconnected proof of concept.

The repository contains a 12-scenario WebMCP agent eval pack covering tool selection, parameter mapping, multi-tool ordering, consent, page-aware inventory use, mid-chain recovery and the complete scan-to-email journey. The final branch passes 127 automated tests, TypeScript checking and a production build.

Challenges we ran into

The hardest engineering problem was observing a browser-only, page-dependent protocol from a serverless scanner.

WebMCP tools can appear only after navigation. A homepage, product page and cart can expose different registries. Browser implementations can return schemas in different object or serialized shapes. Most importantly, a failed browser witness must never be reported as "zero tools."

We built an adaptive multi-context probe, normalized runtime and Chrome DevTools Protocol descriptors, retried bounded renderer failures and preserved the distinction between unavailable and verified absent.

The second challenge was agent UX and safety. Tool outputs must be useful without becoming unbounded data dumps. External page evidence may contain prompt injection and must remain explicitly untrusted. Consequential actions need clear ordering and human control.

We solved this with bounded schemas and outputs, read-only and consequential annotations, semantic invocation outcomes, a report-access gate, separate transactional and marketing consent, signed report links and deterministic evaluation scenarios for complete journeys.

Accomplishments we are proud of

  • Built and deployed a complete product during the challenge window; the public repository was created on 29 August 2026.
  • Created a scanner whose own human interface is also a nine-tool WebMCP surface.
  • Grew a live public Observatory to 511 websites and 523 completed scans.
  • Verified live WebMCP registrations across page contexts instead of counting declarations or scripts.
  • Preserved tool names, descriptions, schemas, annotations, classifications, page context and timestamped evidence.
  • Built both product and documentation MCP servers around the same core service.
  • Published OpenAPI, ARD, RFC 9727, MCP and Agent Skill discovery surfaces without making any of them substitutes for real behavior.
  • Completed a genuine agent-driven scan-to-email journey with explicit consent and a signed report link.
  • Added 12 agent-level evaluation scenarios and 127 automated tests.
  • Published the full implementation under an AGPL-3.0 license in a repository whose default branch contains complete setup, architecture, safety and verification documentation.

What we learned

WebMCP presence is not WebMCP readiness.

A useful agent surface needs discoverable tools, clear descriptions, reliable schemas, trustworthy annotations, bounded outputs and safe action boundaries. It must also be tested across page state because a tool that exists only on a product or cart page is invisible to a homepage-only scan.

We also learned that the strongest WebMCP experiences are visibly collaborative. The assistant should not disappear into a hidden automation flow. Its calls should help the human understand the current page, open the evidence and remain in control of consequential steps.

Finally, emerging discovery formats are valuable when they describe a working product accurately. They are not a replacement for a functioning API, a valid MCP handshake or tools witnessed in a live browser.

What's next

  • Expand the Observatory into longitudinal contract-readiness benchmarks.
  • Add more platform cohorts and monitor how tool surfaces change over time.
  • Run probabilistic model evaluations against the committed deterministic scenarios.
  • Add separately consented end-to-end transaction verification for sites that want to demonstrate the Transactable rung.
  • Turn evidence-backed recommendations into implementation templates for common business workflows.
  • Let teams monitor regressions and compare deployments against the exact rubric and browser evidence that produced each result.

The long-term goal is simple: make agent readiness observable enough that every website can improve it.

Built With

  • agent-skills
  • ard
  • chrome-devtools-protocol
  • markdown
  • mcp
  • next.js-16
  • openapi-3.1
  • playwright
  • react-19
  • resend
  • rfc-9727-api-catalog
  • supabase-postgres
  • typescript
  • vercel
  • vitest
  • webmcp
Share this project:

Updates

Submission history