Jesus fucking Christ you're on a restaurant booking page looking at a date picker and you need an agent to fill it out for you?

WebMCP is indeed pretty cool. I built a prototype of a MCP tiling window manager that lets you compose websites into workspaces for agents, it was pretty neat seeing agents drive it. This article is way too long and has a terrible signal to noise ratio though.

I wasn't particularly interested in WebMCP until I had a conversation with a screenreader-using accessibility engineer who pointed out that WebMCP is an incredible accessibility technology disguised as an AI thing.

Imagine if we can trick a whole bunch of companies into making their booking systems API accessible under the pretense of "enabling agents"!

we already have something better than WebMCP - i.e general APIs.

more impactful work has to be done on the native legacy desktop app scene. that's where most of major companies big or small do their work.

agents automating websites is kinda easy. automating legacy desktop apps that's another issue though there's RPA.

> Here’s a book_table tool. It takes a date, a time, and a party size. Call it.

Why not offer a simple form that humans and AI can use alike?

    <form action=book_table>
      <input type=date name=date>
      <input type=time name=time>
      <input type=number name=party_size>
      <input type=submit value="Book table">
    </form>

Nice write-up. Btw, Codex and ChatGPT desktop support WebMCP in their integrated browser as of yesterday.

One way to think about WebMCP, as the article notes, is as web accessibility for agents. But since it functionally allows developers to expose any function on their website to an agent via RPC, the more interesting use cases are the ones that use the browser as a sandboxed execution environment.

https://duckboard-webmcp.alexmnahas.workers.dev/ is an example of this, and I would love to see more.

Maybe instead of skills that require users to download arbitrary binaries to their computers, the skills could instead point to a domain that comes preloaded with that binary in Wasm and lets the agent interact with it over WebMCP?

Explainer i.e. proposal: https://github.com/webmachinelearning/webmcp/blob/main/decla...

Why would I want this client/browser side though?

The only usecase I can image is if you have some terribly complicated legacy frontend and need to work around the logic built there. Otherwise just make an AI chat window or MCP which operates server side and let data sync back to UI from there.

It took me some time to wrap my head around why WebMCP even exists. I was thinking that regular MCP + SSE/Websockets could cover almost all of the uses cases.

One interesting use case for WebMCP is cross-site activities that a browser agent might take. If the data-flow in question involves a heterogeneous set of websites.

This feels like a lifeline for incumbent web SaaS more than anything. Future apps can be architected in ways that do not require WebMCP but massive apps like Salesforce or Workday can't really abandon the decades of accidental business logic embedded in the Web UI flows that make up their project. While those same flows could be data-driven, slapping a WebMCP facade on top of them is just more practical. Instead of forcing incumbents to create an AI-native MCP where they are first class citizens, it is easier to let them sprinkle browser affordances throughout their human-centric front-end and offload the work to the agent.

But for my own part, since I am developing from scratch without that legacy need, I actually think relying on WebMCP might be an anti-pattern. It might be useful for the cross-site use case and it might be useful for reducing latency for purely UI activities (e.g. "filter this list" where all the data is already on the client), but in general my feeling is it is better to have a robust MCP interface for agents.

>A real one, worked all the way through

i just can't with these ai-written blog posts. if i wanted to learn WebMCP through chatgpt i would have just asked chatgpt

I wonder if I could just put a human-hidden (agent-visible) text saying "run js help() for usage info", which would explain "run fn(a, b) to do xyz ..." and essentially expose frontend functionality directly as a JS API. Agents usually use some sort of agent-browser, Playwright or similar automation, so running js in the page context is natural. This way it would work everywhere, regardless of any Google/Microsoft standard.