MetaWebMCP

WebMCP builds WebMCP. Turn observable website workflows into bounded, reusable WebMCP tools. Then activate, test, and export them.

Comment

Inspiration

As new standards and protocols come, adoption is key.

WebMCP gives agents a clean, semantic way to interact with websites, but most of the web will not add native integrations overnight. We wanted to see whether compatibility could grow from the other direction: let an agent observe an existing workflow, give it a narrow WebMCP interface, use it immediately, and export it as a native integration later.

What it does

MetaWebMCP is WebMCP that builds WebMCP.

It turns the useful, observable parts of a website into bounded, reusable tools. An agent can inspect a site, define tools grounded in its interface, activate them on the current page, test them, and export the same contracts as a standalone WebMCP repository.

How we built it

We built MetaWebMCP through a lot of small iterations. We intentionally kept the architecture lightweight so we could focus on the hard problem of creating a useful compatibility layer between existing websites and WebMCP.

The core runs on Node.js without runtime package dependencies. A permanent set of seven meta-tools handles analysis, contract creation, activation, testing, export, state inspection, and reset. Activating a project dynamically registers a second set of domain tools on the same top-level page.

One of our most important decisions was to use the same ToolSpec objects for live activation, execution, testing, and export. The exported integration is not a separate code-generation demo. It is another representation of the exact contracts the agent reviewed and used.

For public websites, MetaWebMCP uses an isolated browser session to capture the rendered page and its accessibility model. For owned sites, it exports a standalone repository containing direct document.modelContext.registerTool(...) calls. It also includes a fallback registry so the complete workflow remains usable in ordinary browsers without native WebMCP support.

Challenges we ran into

The hardest part was, of course, not generating code. It was finding the right boundary between brittle browser automation and a useful semantic tool.

Real websites are messy. Controls may be ambiguous, inaccessible, repeated, dynamically rendered, or changed without warning. We had to ground every generated tool in observed evidence while refusing to expose arbitrary JavaScript or unrestricted browser operations.

The recursive lifecycle was another challenge. MetaWebMCP needs to keep its permanent tools active while safely adding, replacing, and removing generated tools. It also needs the live implementation and exported implementation to behave consistently.

## Accomplishments that we're proud of

The main accomplishment is that MetaWebMCP is legitimately useful. It is not only a recursive gimmick built for a hackathon.

In our native test, the page exposed seven permanent WebMCP tools, dynamically expanded to eleven, passed all four generated-tool checks, and exported a standalone repository whose tools continued to work without MetaWebMCP as the runtime.

Our limited benchmarks also produced a concrete result. Across the matched tests, MetaWebMCP reduced model-facing tool text by 4.11× to 57.31× and non-cached token usage by 1.28× to 6.81×. It was also 1.39× to 2.18× faster on the larger, multi-page workloads.

It was slower on one shorter, single-page task because the initial analysis and tool-authoring cost did not have time to amortize. That counterexample matters. The strongest result is not that MetaWebMCP always makes an agent faster, but that a small semantic interface can keep large amounts of repetitive browser output out of the agent’s context.

What we learned

Agents have come a long way.

They can now inspect an unfamiliar interface, reason about its useful capabilities, shape those capabilities into typed contracts, and use the resulting tools without requiring a separate model API inside the application. A weaker version of this was already possible some years ago, with a lot of issues, but now the agents seem to get it consistently, enough for tools like this to exist.

What's next for MetaWebMCP

The next step is to develop MetaWebMCP into a robust platform with fully managed services, so agents can connect to the existing web reliably through WebMCP.

That means persistent and versioned integrations, stronger evaluations, monitoring for interface drift, managed browser execution, better owner-installation workflows, and production-grade controls for authentication, authorization, auditing, and confirmation.

The goal remains the same: make WebMCP adoption incremental, practical, and useful across the web.

Built With

Share this project:

Updates

Submission history