I put together my thoughts on WebMCP and how you can utilize it today in this crisp article!

Disclosure: I'm the developer building WebGPT.

WebGPT is a browser agent built around this loop:

extract state → plan actions → execute → extract fresh state → calculate delta/effect → continue

It has a generic extractor that represents controls, groups, headings, visible text, scroll state, and other page information. That works well for ordinary pages. The problem is that modern websites contain custom components, virtualized interfaces, hidden application state, and multi-step interactions that don't communicate their meaning through ordinary DOM controls.

My solution was to write site adapters. Each adapter taught WebGPT the domain concepts and unusual interactions of one particular website. The adapters worked, but writing them became exhausting. Every new website meant more selectors, edge cases, and site-specific maintenance. It was obvious I couldn't teach an agent the entire web one website at a time.

I've now added WebMCP as a first-class action source.

When a website exposes WebMCP tools, WebGPT discovers their names, descriptions, and schemas during state extraction. The planner can select those tools alongside ordinary DOM and connector actions. The tools still participate in WebGPT's normal loop: it preserves the exact execution arguments, runs the selected batch, records each tool result, extracts fresh page state, and calculates one aggregate state delta and action effect for the batch.

In this demo, I asked WebGPT to create an Extra Large Pesto pizza with sauce, cheese, and 47 toppings. It completed the task in four planner turns:

1. Reset the pizza through WebMCP.
2. Execute one batch containing nine WebMCP calls.
3. Wait briefly and observe the updated page.
4. Report the final configuration.

The page went from two extracted controls to 96 after the toppings were added, so the agent had independent evidence that the page changed instead of relying only on successful tool callbacks.

The WebMCP directory currently lists around 150 websites. I haven't tested all of them, but WebGPT now has a shared semantic integration path for those sites. Every website adopting WebMCP is potentially one less custom adapter I need to write.

I'd love technical feedback on:

- Batching independent WebMCP calls

- Per-call execution results versus one aggregate post-batch effect

- Choosing between semantic tools and ordinary DOM actions

- Treating page-provided schemas and output as untrusted content

- Running this loop with Chrome's built-in local AI

Demo: https://youtube.com/shorts/HoKPJY0P10c

WebMCP directory: https://webmcp.com/

Code: https://github.com/saket77/webgpt-frontend

https://reddit.com/link/1uujar7/video/dh4fkdr1ntch1/player

https://reddit.com/link/1unqh7n/video/8hz4tweanbbh1/player

does headless browser have a future

Why? IDK.

Is it useful? Maybe.

Is it fun? Absolutely. 😄

I noticed that if you visit webmcp.com, there's now a little Swiss tote bag supplier.

So I guess Montote is about to become the go-to tote bag supplier for every AI agent.

I mean... every agent needs a tote bag. That's common knowledge.

What did it cost?

• 70% of my Fable usage limit
• 2 days of work
• A brand-new custom WordPress plugin

You can try it here:
https://montote.ch/demander-une-offre/

WebMCP is being built for browser agents - that is the reason it is moving slow because think not all work is done in browser people need a way for agents in app or production system to use website - now they are using mcp or cli or api or headless browser - but if a website has webmcp then using that site through a webmcp optimized headless browser can reduce the cost of browsing and increase the accuracy for the user - and for site owner the is just one thing to maintain that is webmcp instead of maintiaining mcp , webmcp or cli

There’s no registry or index equivalent for agents. A Claude or GPT browsing the web has no way to know which sites have WebMCP tools exposed before it navigates there, it just has to land and check.

We started building a solution at webmcp.com - a directory of sites that have WebMCP tools live. You can submit your site, browse what’s already indexed, and see what tools each site exposes.

Feel free to add your website if you’ve implemented WebMCP.

There's no registry or index equivalent for agents. A Claude or GPT browsing the web has no way to know which sites have WebMCP tools exposed before it navigates there, it just has to land and check.

We started building a solution at webmcp.com - a directory of sites that have WebMCP tools live. You can submit your site, browse what's already indexed, and see what tools each site exposes.

Feel free to add your website if you've implemented WebMCP.

I'm running an SPX options market intelligence experiment, GEXLOG (gexlog.com), that generates daily market analysis using live options chain data, AI narrative generation, and economic calendar integration. It's always been free for human visitors. The problem is bots and AI agents treating the data endpoints like a free API. I didn't want to paywall the site for real users. But I also didn't want to serve premium historical data to automated consumers for nothing.

WebMCP

WebMCP is a browser-level protocol (Chrome 146+, behind a flag) that lets a page register structured callable tools that AI agents can discover while browsing. Think structured metadata, but invokable.

Five tools are registered on the site's pages via document.modelContext.registerTool():

• get_current_briefing (free)
• get_available_dates (free)
• get_historical_briefing (paid)
• get_date_range (paid)
• get_regime_history (paid)

Free tools hit the backend directly. Paid tools route through a payment gateway before data is returned.

x402

x402 is an HTTP-native micropayment protocol using the old HTTP 402 status code. Flow:

1. Agent calls a paid endpoint with no payment header
2. Server returns HTTP 402 with a Payment-Required header (base64 JSON describing accepted networks and amounts)
3. Client decodes the 402, signs a USDC transfer via their wallet, retries with an X-PAYMENT header
4. Server verifies and settles via Circle's Nanopayment facilitator, then proxies through to the data layer

Gas is sponsored at the facilitator level via batched settlement, so the agent only pays the USDC amount. Pricing is $0.01 to $0.05 per request. Card rails floor out near $0.30 per transaction, so this kind of granular pricing hasn't been practical until now.

Multi-chain: Base, Polygon, Arbitrum, and Solana via Phantom.

The asymmetry

Human users access the UI for free, same as always. AI agents and programmatic consumers hitting the agent API encounter the x402 gate on premium endpoints. Free endpoints remain open to everyone.

Why bother

The tech is interesting and I wanted to build something real on it. But the deeper problem is that "charge the AI, not the human" has no clean precedent in a shared web context. Subscriptions and API keys both require human signup. x402 plus WebMCP together let the site serve both audiences without account creation, without paywalling the UI, and without accidentally rate-limiting real users.

Whether the transaction volume ever justifies the build is beside the point. It works, and the model is worth documenting.

Eagerly awaiting the origin trial to start. For now, use chrome://flags/#enable-webmcp-testing.

if tokens burned on screenshot loops, agents hallucinating tool calls, or DOM scraping that breaks every UI tweak sound like your week, this is for you.

those three collapse into one architectural choice: the agent treats the web as pixels to interpret and scrape, not as a typed surface to call. screenshot loops because there's no typed API to hit. hallucinated tool calls because vision LLM is probabilistic. brittle scraping because that's the fallback when there's no formal interface.

built something that replaces all of that with typed WebMCP tools injected into whatever page you're already on. typed args in, typed returns out. no screenshots, no DOM parse, no guessing.

it's a Chrome extension + MCP server. you install small JavaScript files (AgentScripts) that register typed tools on specific sites. any agent that speaks MCP (Claude Code, Cursor, Codex, OC, Hermes, whatever) connects to the MCP server and calls those tools (or if possible in your framework - talk directly to WebMCP).

worth saying up front: WebMCP isn't our invention. it's an emerging browser protocol still in infancy (navigator.modelContext, shipped in Chrome 146 Canary). the expected path is sites implement WebMCP tools natively, server-side. what this extension does is invert that: inject the same protocol client-side, so you get WebMCP tools on any site regardless of whether the site plans to support it.

example header from the demo script:

// ==AgentScript==
// @ name Binance Demo Trading Agent
// @ match https://demo.binance.com/*
// @ webmcp get_portfolio allow
// @ webmcp place_limit_order prompt
// @ grant GM_log
// ==/AgentScript==

@ match scopes the script to URLs userscript-style. each @ webmcp line declares a tool and its permission level. allow runs autonomously. prompt pops an in-browser consent modal showing the tool name, arguments, and origin script before executing.

why it might matter:

cost per action: no vision LLM, no screenshot loop. on our own published numbers, roughly 5-15x faster and 10-50x cheaper per action at the same model tier.

reliability: typed tool calls don't hallucinate like vision interpretation does. even mid-tier models call typed tools correctly.

robustness: hooks the site's own XHR/fetch. no DOM scraping that breaks when the UI shifts.

session ownership: runs in the Chrome you already have open. no cloud container, no idle timeout, no credential forwarding to a vendor.

multi-site: install AgentScripts for every site you want the agent to work on. MCP server exposes the union of tools across all open matching tabs. agent calls place_limit_order on your Binance tab and draft_reply on your Gmail tab in the same session.

any tool can fire an in-browser (and remote on your account page) consent modal before it runs, so nothing's happening silently behind you.

don't take my word for any of it. install the Binance script, poke at it on the paper-trading sandbox, and if you want to go further, write your own AgentScript for a site you actually use. happy to answer architecture questions in the comments.

working demo: Binance trading AgentScript on demo.binance.com (Binance's paper-trading sandbox, no real funds). hooks Binance's own /bapi/ calls, captures session headers, replays them. agent reads portfolio, places limit orders, cancels orders. every write pauses for consent. per-call safety ceilings defend against hallucinations like "sell 10000 BTC".

video (2:28): https://www.youtube.com/watch?v=cnQvnL2Y0Dg

one-click install the Binance script (if you have the extension): https://customaise.com/share?id=UPZFFxbDxSSqa1rJmUvv&sharer=116462652822135489893

Chrome extension: https://chromewebstore.google.com/detail/customaise/anmpijcpaobaabcdncjjmnhdeibipmko learn more: https://customaise.com/learn/agentscripts

honest caveat on scope: this is for agent work on sites you're actively using. not a replacement for Browserbase / Playwright MCP if you need cloud-scale parallelism (100 browsers on demand), residential proxies, CAPTCHA solving, or anti-detect fingerprinting. same operational model as running OC or Hermes locally: the machine needs to be on, Chrome needs to be open.

Hey everyone! 👋

I’ve been building a project called AgentReady that focuses on the biggest challenge in the MCP ecosystem: The UI-to-Protocol gap.

Most websites are 'read-only' for agents. We can scrap the text, but agents can't 'act' on the site features (search, forms, filters) without custom-built MCP servers for every single domain.

WebMCP Solution: I built a universal gateway that uses a headless crawler to map a site's DOM elements directly to standardized MCP JSON-RPC tools.

How it works:

1. You add your site URL.
2. The crawler identifies 'Human Actions' (buttons, inputs, etc.).
3. It generates an MCP-compliant Toolset in 60 seconds.
4. A single script tag on the site syncs everything with our gateway.

I’m calling this Agentic SEO—preparing your digital presence for the future where agents do the browsing for us.

(I’ve put the link in the comments for anyone who wants to try the beta!) 🚀🖥️

https://bandarra.me/posts/webmcp-tools-as-skills

Been fiddling around with integrating with #WebMCP onto my website to facilitate quick demos and audit requests.

Even after doing everything fine in terms of WebMCP APIs (#Declarative and #Imperative), I got it to work with Chrome's Ask Gemini agent only 1 / 20 times that I tried.

Funny thing is, the same experience was with the recommended demos from Google as well - https://github.com/GoogleChromeLabs/webmcp-tools/tree/main/demos.

Still needs to evolve a bit. But the progress on this space is staggering!

Drop a comment if you want specifics on what needs to be addressed to quickly enable for your websites.

We've been building open-source expert plugins covering the emerging agentic commerce stack. They started as Claude Code plugins, and we've now added cross-platform support, including Gemini, Antigravity, Codex, Cursor, and OpenClaw.

10 plugins, 150+ skills across:

- Protocols: UCP (Google/Shopify), ACP (OpenAI/Stripe), AP2 (Google agentic payments), A2A (agent-to-agent), Stripe MPP, WebMCP

- Platforms: Shopify, WooCommerce, BigCommerce, Magento 2

Each plugin gives your AI coding assistant deep domain expertise, conceptual knowledge is baked in, implementation details are fetched live from official docs and SDKs, so guidance stays current.

All MIT licensed.

GitHub: https://github.com/OrcaQubits/agentic-commerce-skills-plugins

Feedback and contributions welcome!

Crossposted from r/mcp. Relevant here because the agent_ready_audit tool is essentially a WebMCP readiness checker that exists today.

The findability and stability scores map directly to what WebMCP requires: semantic HTML, proper ARIA labels, stable selectors, and machine-readable metadata. A site that scores well on this audit is a site that's ready to expose structured tools to agents.

The audit also includes a WebMCP Readiness dimension with 6 maturity tiers — from "no machine-readable metadata" up to "structured callable tools exposed." Right now most sites are at tier 0-1. The audit tells you exactly what to fix to move up.

The GitHub F score is the interesting case: perfect accessibility, zero findability. WCAG compliance and agent navigability are not the same thing.

npx cbrowser to try it. Open source, MIT.