AnyWebMCP

Inspiration

OpenAI’s post about using WebMCP with Codex made us examine the standard in the context of our browser automation work. Codex already could complete our tasks, but dynamic websites required repeated cycles of inspecting, scrolling, and collecting page content. Each cycle added another model call and more tokens. We wanted to replace those loops with small, structured tools.

What it does

AnyWebMCP is a Chromium extension that adds WebMCP tools to existing websites. It detects the current domain, loads the matching adapter, and exposes a bounded set of operations to the agent.

The tools use the current browser session and return structured results. AnyWebMCP currently supports Amazon, eBay, Hacker News, LinkedIn, Product Hunt, Reddit, Temu, and X. A macOS launcher loads the extension into Codex’s built-in browser.

How we built it

We created a TypeScript monorepo with separate packages for the extension, shared WebMCP contracts, and each website adapter. Adapters collect data from the DOM, public APIs, or same-origin endpoints, depending on the site.

Our Chrome prototype required an unpacked extension, experimental flags, and a remote debugging connection. We wanted the extension inside the browser where our Codex workflows ran.

We inspected the macOS Codex build and found that it was Electron-based. It accepted the Chromium flags we needed:

--load-extension=<extension>
--enable-features=WebMCPTesting

We built a launcher that creates a verified runtime copy of the installed Codex app and starts it with those flags. The launcher leaves the installed app untouched and does not include or redistribute Codex.

Challenges we ran into

The first challenge was installation. Our colleagues understood the extension but found the Chrome debugging setup cumbersome. Chrome also displayed a persistent debugging notification and mixed agent-created tabs with their work browser.

Website differences created the second challenge. Each site exposes data through different page structures and endpoints. Dynamic feeds, hidden content, authentication, and tool discovery required bounded recovery logic for each adapter.

Accomplishments that we're proud of

First of all, we made it successfully work in Codex in-app browser. It's a bit hacky now, but we hope codex in-app browser adds native support for browser extensions at some point.

In paired benchmarks, WebMCP reduced median total-token use by up to 90% and completion time by up to 55%.

We also added safety boundaries. Most tools are read-only. Drafting tools leave final submission to the user, and commerce tools cannot purchase products or begin checkout.

What we learned

Structured tools work best when one call replaces several model and browser turns. Tool calls have their own latency, so short tasks may save tokens without finishing faster.

We also learned that useful WebMCP tools need site-specific design. A small operation with a clear schema and bounded output helps the agent more than a generic dump of page content.

What's next for AnyWebMCP

We plan to add adapters based on real browser workflows, simplify installation and updates, and improve the adapter SDK for contributors. We also want to support more desktop platforms and follow the WebMCP standard as browser support develops.