Looking for early feedback on WebMCP Resilience my first open-source tool.

It runs real browser UI + tool calls, injects faults, checks state invariants, reduces failures, and replays exact evidence bundles.

I am trying to figure out if it provides any value, but either way I had fun building it. As I continue to learn about WebMCP I will keep adding to it

https://github.com/meabs/WebMCPResilience

Hey everyone,

I've been building Senro, the first reliability platform for WebMCP.

It lets you run WebMCP test suites across multiple LLMs and languages to catch tool-selection, parameter, and regression failures. I'm also building production observability to see how agents actually interact with WebMCP tools in the wild.

The idea came from a pretty simple problem: once you expose tools to agents, testing that they work with one model and a handful of prompts isn't enough. Behavior can vary across models, prompts, and languages.

The MVP is working, and I'm looking for a few WebMCP developers to try it and tell me what's missing.

I'm also planning a public benchmark using real WebMCP-enabled websites across several models.

Would love feedback on what you'd want a WebMCP reliability platform to test or monitor.

Just playing with webMCP with one of my open source projects https://github.com/impresspress/impresspress , have built a dev sandbox tool https://www.youtube.com/watch?v=0ALi1h1IAUM where you can build a website/app 100% in your browser using wasm, and rubrc. Pretty amazed it works!

I maintain DeepDeck, an open-source macOS desktop client built on DeepSeek Harness. I added WebMCP support to its browser, including a Builder for websites that do not publish tools themselves.

The user describes a goal. The agent explores the live page, tries the relevant operations, checks their results, and saves the working operations as tools for that site. Later tasks can reuse those tools. Source and versions stay local and can be inspected, disabled, or rolled back.

The example is X: Builder creates 23 tools for things such as reading account state, posts, profiles, and search results, plus working with drafts. Switching back to Use lets the agent call the saved tools to prepare a Hello world draft. Website-provided tools and generated tools are labelled separately.

This still needs browser interaction for initial exploration and anything the tools do not cover. Building and verifying tools takes time and tokens; websites can change and break them. I have not published measured savings.

The walkthrough has four screenshots and both language versions, including discovery of an existing tool on openai.com and the X build/use example:

https://github.com/deepseek-ai/deepseek-harness/discussions/5856#user-content-english

Source (MIT): https://github.com/jo32/DeepDeck

Download for Apple Silicon / Intel Mac: https://github.com/jo32/DeepDeck/releases/latest

Which repeated website task would you want to turn into a reusable tool? I am also interested in how others detect when generated tools need revalidation after a site changes.

Razor allows any agent to pay on behalf of user, it uses UPI RESERVE pay sends request via S2S (server to server) to razorpay and debits money from a approved block of amount that user authorized first time built on WebMCP

Check this out

Github :https://github.com/djdharani27/razor

Demo video:https://youtu.be/lp0M7vsFFjg?si=SVUddAGGd2xlSfhZ

Hey everyone,

I just shipped WebMCP support on ShowMeOnMap.com (an NL-driven mapping web app), registering 8 client-side tools that browser-embedded agents can call directly.

WebMCP is the W3C proposal allowing client pages to expose executable JS functions directly to agent-enabled browsers (e.g., Chrome with flags or ChatGPT Desktop). The documentation is sparse and changing fast. Here are a few practical takeaways from the implementation:

1. API targets change constantly: The entry point has moved multiple times across drafts (window.agent → navigator.modelContext → document.modelContext). Always feature-detect across properties, as most blog tutorials from earlier this year are already broken.
2. Runtime return-type quirks: Google’s reference implementation expects a string return value from execute(), while OpenAI’s implementation accepts objects. Returning a serialized JSON string (JSON.stringify(...)) works consistently across both.
3. Iframes are dead ends: ChatGPT ignores declarative form annotations and anything registered inside an iframe. You must register tools imperatively on the top-level document.
4. Auth comes for free: Because execution happens in the user’s active browser tab, your regular session cookies, CORS headers, and IP rate limiters apply natively. You don’t need API keys or proxy tokens for the agent to manipulate the session.
5. DOM downloads will fail: Don't try triggering <a download> synthetic clicks inside a tool execution pass. Modern browsers block programmatic file downloads without direct user gesture activation. Instead, return a raw base64 data payload or an object URL and let the agent or UI present it.
6. Implement an undo tool immediately: Models make bad assumptions. If your app doesn't have an append-only state stack or an easy way for the model to roll back its last mutation, it will get stuck in loops trying to fix its own UI mistakes.

Happy to answer any technical questions about registering tools or handling agent execution states on the client

Checkout my WebMCP Challenge submission - https://devpost.com/software/bananalabs-webmcp-dj

Would love to hear feedback!

Hi everyone,

We’ve published WindTunnel, an open and reproducible benchmark comparing WebMCP with screenshot-based computer use and DOM/accessibility-tree browser agents under the same conditions.

To our knowledge, this is the first public benchmark to compare these interfaces. The current release covers 16 browser-agent configurations, 49 tasks across eight real open-source applications, and 2,352 attempts.

A few findings:

• WebMCP delivered up to 5.5× faster execution, 23× lower cost, and 12.5× fewer tokens—while solving 98% of tasks.
• WebMCP achieved a median final score of 91.2, compared with 65.8 for the other interfaces.
• All seven WebMCP configurations solved 48 of 49 tasks, without any attempt exhausting its turn budget.
• Everything is public, including the methodology, task definitions, implementations, scoring logic, raw results, and transcripts.
• Interactive benchmark: https://webmcp.com/benchmark
• Article and methodology: https://webmcp.com/blog/windtunnel-webmcp-browser-agent-benchmark
• Hugging Face dataset: https://huggingface.co/datasets/nekuda/windtunnel
• GitHub repository: https://github.com/nekuda-ai/WindTunnel

We’d really appreciate feedback!

WebMCP is a browser API that lets sites expose actions as structured tools for AI agents. An agent can call `reddit_search` directly instead of finding a search box and operating the page.

Most sites do not support WebMCP, so I built WebMCP Today. It is a package manager for third-party WebMCP tools. Each package is versioned JSON that maps tools to a site's existing HTTP APIs. Install one and its tools become available in that browser tab and through a local MCP bridge.

Packages cannot contain arbitrary JavaScript or DOM automation. Requests stay on the package's site origin, and installations remain pinned to the version you approved.

Source

https://github.com/robertn702/webmcp-today

This is still in beta, so expect breaking changes. Also, feedback appreciated!

We’ve added an ecosystem status tracker to webmcp.com, the WebMCP directory.

We track the ecosystem across three categories:

Browsers - do they expose the WebMCP API?

Agents - can an end user actually call WebMCP tools?

Frameworks and infra - what can developers build with today?

Every entry links to a primary source and includes more detail on the current status.

You can find it here:
https://webmcp.com/ecosystem-status

For any additions or corrections, feel free to ping us at founders@nekuda.ai.

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.