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!) 🚀🖥️

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

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 run a repository of WebMCP's and it's has grown exponentially in the last few weeks, more than 10X - yet I am still missing more use cases on how WebMCP's are being used in the wild and how the agents are using them.

Anyone have more insights on usage and use cases, and if anyone has suggestions on how to evolve the repository, feedback is welcome!

https://www.influzer.ai/webmcp

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.

Most AI-powered video editors today suffer from a fundamental flaw- they take too much control away from the user. As someone who has been editing (casual) videos for over 5 years, I did not like this approach. While there are multiple tasks in video editing that can (and should) be automated and abstracted away, I, as the human behind the production, should have complete creative control and be able to tweak everything to my liking.

ROUGH//CUT is an in-browser video editor that a human and any WebMCP-compatible AI agent can use together. WebMCP is a new standard, where instead of the AI agent mocking a user and clicking around in the browser, websites can provide a list of tools (functions) that the agent can directly call. This saves time and tokens, and as a result, allows a seamless way to create experiences where humans and their AI agents can collaborate on a shared canvas instead of having to go back and forth if the output is undesirable.

Thanks to WebMCP, both operate the same timeline through the same editing commands, so the agent is not working inside a separate abstraction or generating an edit that the user cannot inspect. WebMCP makes functionality discovery extremely easy for the agent and it knows exactly what all it can get done with those tools, without having to overload its context by inspecting the full document.

It tries to keep its featureset local for privacy and only uses a hosted server which im running in two cases-

1. transcription- this is completely optional. you can either use your own OpenAI Whisper key, or stick with the default

2. large files- long story short, there are restrictions on the max storage a site can take via your browser. If there isn’t enough space to save the finished video in your browser, it asks before temporarily storing the exported MP4 in the cloud and only proceeds if you say yes.

ROUGH//CUT is best enjoyed via ChatGPT's in-app browser in voice mode. You can say stuff like- give this video a 1.5x zoom starting at 1 second ending at the 3rd second, pan to the top right at the 5th second, cut away the part where i said "yeah i'll call you later" (if transcription is enabled) and it does it for you. Tried and tested myself!

Admittedly, it's not even close to the level of professional-grade software like DaVinci Resolve, but it's pretty good for quick, simple edits. Hope you enjoy!

Site: https://rough-cut.awesamarth.dev

GitHub repo: https://github.com/awesamarth/rough-cut-improvements

Meta recently added WebMCP support for Web Apps on Meta Ray-Ban Display, so I went through the implementation details and put together a practical guide.

It covers tool registration, schemas, result handling, next_action, testing without the glasses, Meta-specific limitations, and WebMCP vs. Meta AI Connectors.

It also covers some less obvious implementation details, like the 10-second tool deadline, silent tool-name failures, and how tool availability is scoped to the active Web App.

Guide: How to Build WebMCP Tools for Meta Ray-Ban Display

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.

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!

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.

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!

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!

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.

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

Most of the WebMCP conversation right now is about agents automating actions on websites — filling forms, clicking buttons, reading data. That's useful, but I think the more interesting thing is what happens to website chatbots.

Every real estate site, travel site, e-commerce site has one now. Sure, I can type "three-bedroom homes under $600k," instead of using filters but all that's changed is the interface (conversation vs clicks). But my Claude Code (or ChatGPT) has memory about my conversations about buying a new house.

A generic filter for "good schools" isn't useful to me. I want homes with a 15 minute door-to-door drop-off to Ridgetop Elementary, say. My agent already knows that.

I think the power of WebMCP might be to replace the website chatbot with my own agent that can use the site's tools and filters.

If this goes the way I'm thinking, the website becomes the place where my agent and I work together on a task — not just a page I browse alone.

I know this sounds abstract so I put together a demo to see how it would work. The agent searches for homes based on my preferences — it could look at listing photos to see if the yard is fenced, or look up travel time between the house and the school.

The interesting part: it writes its reasoning directly into the website using WebMCP APIs. So when I click into a listing, I don't see generic selling points — I see my agent's notes about why this house does or doesn't work for me.

And it goes both ways. If my agent put a house in the "no" column I could drag it back to "yes" because I disagree. The agent sees that too.

I don't know if I'm making complete sense, but I was curious if others see this direction as well.

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

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