Chris Shank & Orion Reed doing some very nice work with accessibility trees. https://bsky.app/profile/chrisshank.com/post/3m3q23xpzkc2u

I tried to play along at home some, play with rust accesskit crate. But man I just could not get Orcas or other basic tools to run, could not get a starting point. Highly discouraging. I thought for sure my browser would expose accessibility trees I could just look at & tweak! But I don't even know if that's true or not yet! Very sad personal experience with this.

We're building an app that automatically generates machine/human readable JSON by parsing semantic HTML tags and then by using a reverse proxy we serve those instead of HTML to agents

I see two totally different things from where we are today

1. This is a contextual API built into each page. Historically site's can offer an API, but that API a parallel experience, a separate machine-to-machine channel, that doesn't augment or extend the actual user session. The MCP API offered here is one offered by the page (not the server/site), in a fully dynamic manner (what's offered can reflect what the state of the page is), that layers atop user session. That's totally different.

2. This opens an expectation that sites have a standard means of control available. This has two subparts:

2a. There's dozens of different API systems available, to pick from, to expose your site. Github got half way from rest to graphql then turned back. Some sites use ttrpc or capnweb or gproto. There hasn't actually been one accepted way for machines to talk to your site, there's been a fractal maze of offerings on the web. This is one consistent offering mirroring what everyone is already using now anyways.

2b. Offering APIs for your site has gone out of favor in general. It often has had high walls and barriers when it is available. But now the people putting their fingers in that leaky damn are patently clearly Not Going To Make It, the LLM's will script & control the browser if they have to, and it's much much less pain to just lean in to what users want to do, and to expose a good WebMCP API that your users can enjoy to be effective & get shit done, like they have wanted to do all along. If webmcp takes off at all, it will reset expectations, that the internet is for end users, and that their agency & their ability to work your site as they please via their preferred modalities is king. WebMCP directs us towards a rfc8890 complaint future, by directly enabling site agency. https://datatracker.ietf.org/doc/html/rfc8890

In theory you could use a protocol like this, one where the tools are specified in the page, to build a human readable but structured dashboard of functionality.

I'm not sure if this is really all that much better than, say, a swagger API. The js interface has the double edge of access to your cookies and such.

No, I don't think you're thinking about this right. It's more like hacker news would expose an MCP when you visit it that would present an alternative and parallel interface to the page, not "click button" tools.

As someone heavily involved in a11y testing and improvement, the status quo, for better or worse, is to do it the other way around. Most people use automated, LLM based tooling with Playwright to improve accessibility.

Interesting. I'd appreciate an example. Thanks!

I certainly do - it’s wonderful that making your site accessible is a single prompt away!

You're both right. The page can expose MCP tools like via a form element which is as simple as adding an attribute to an existing form and completely aligns with existing semantic HTML - eg submitting an HN "comment". Additionally, the page can define additional tools in javascript that aren't in forms - eg YouTube could provide a transcript MCP defined in JS which fetches the video's transcript

https://developer.chrome.com/blog/webmcp-epp

Because the nightmares associated with having an API, authentication, database, persistent server etc. are worse. If all you have is an SPA you shouldn't be forced to set up an API just to be called by an LLM.

Question: Are you writing this under the assumption that the proposed WebMCP is for navigating websites? If so: It is not. From what I've gathered, this is an alternative to providing an MCP server.

Instead of letting the agent call a server (MCP), the agent downloads javascript and executes it itself (WebMCP).

In response to microphone or camera access proposals you could have said "so we're going to let every website have a vector to spy on us?"

This is what permissions are for.

Yeah, this seems like a weird niche where an agent has to interact with an existing browser session.

That, or they expect that MCP clients should also be running a headless Chrome to detect JS-only MCP endpoints.

It's not meant to describe how to use the site, it should / can replace the need for playwright and DOM inspection / manipulation entirely.

Think of it like an "IDE actions". Done right, there's no need to ever use the GUI.

As opposed to just being documentation for how to use the IDE with desktop automation software.

Mainly for web browser plugin authors implementing AI assistants (Gemini/Claude/OpenAI/Copilot).

Instead of parsing or screen-shooting the current page to understand the context, an AI agent running in the browser can query the page tools to extract data or execute actions without dealing with API authentication.

It's a pragmatic solution. An AI agent, in theory, can use the accessibility DOM to improve access to the page (or some HTML data annotation); however, it doesn't provide it with straightforward information about the actions it can take on the current page.

I see two major roadblocks with this idea:

1. Security: Who has access to these MCPs? This makes it easier for browser plugins to act on your behalf, but end users often don't understand the scope of granting plugins access to their pages.

2. Incentive: Exposing these tools makes accessing website data extremely easy for AI agents. While that's great for end users, many businesses will be reluctant to spend time implementing it (that's the same reason social networks and media websites killed RSS... more flexibility for end users, but not aligned with their business incentives)

Why would Facebook or LinkedIn ever give you this?

I disagree. I run a sudoku site. It’s completely static, and it gets a few tens of thousands of hits per day, as users only download the js bundle & a tiny html page. It costs me a rounding error on my monthly hosting to keep it running. To add an api or hosted mcp server to this app would massively overcomplicate it, double the hosting costs (at least), and create a needless attack surface.

But I’d happily add a little mcp server to it in js, if that means someone else can point their LLM at it and be taught how to play sudoku.

Likely no.

Every generation needs its own acronyms and specifications. If a new one looks like an old one likely the old one was ahead of its time.

Demo I built 5 months ago: https://www.youtube.com/watch?v=02O2OaNsLIk This exposes ecommerce specific tool calls as regular javascript functions as it is more lightweight than going the MCP route.

It's great they are working on standardizing this so websites don't have to integrate with LLMs. The real opportunity seems to be able to automatically generate the tool calls / MCP schema by inspecting the website offline - I automated this using PLayright MCP.

In what world is this simpler than just giving the agent a list of functions it can call?

Do expose the accessibility tree of a website to llms? What do you do with websites that lack that? Some agents I saw use screenshots, but that seems also kind of wasteful. Something in-between would be interesting.

The purpose of this appears to be for sites that cannot be controlled via prompt instructions alone.

I do like agent skills, but I’m really not convinced by the hype that they make MCP redundant.

This GitHub readme was helpful in understanding their motivation, cheers for sharing it.

> Integrating agents into it prevents fragmentation of their service and allows them to keep ownership of their interface, branding and connection with their users

Looking at the contrived examples given, I just don't see how they're achieving this. In fact it looks like creating MCP specific tools will achieve exactly the opposite. There will immediately be two ways to accomplish a thing and this will result in a drift over time as developers need to take into account two ways of interacting with a component on screen. There should be no difference, but there will be.

Having the LLM interpret and understand a page context would be much more in line with assistive technologies. It would require site owners to provide a more useful interface for people in need of assistance.

Skills are great for static stuff but they kinda fall apart when the agent needs to interact with live state. WebMCP actually fills a real gap there imo.

check out https://moltbook.com/skill.md

I think that rest and html could probably be already used for this purpose BUT html is often littered with elements used for visual structure rather than semantics.

In an ideal world html documents should be very simple and everything visual should be done via css, with JavaScript being completely optional.

In such a world agents wouldn’t really need a dedicated protocol (and websites would be much faster to load and render, besides being much lighter on cpu and battery)

I'm building this. Initially it was to do codegen for tools/sdks/docs but will incorporate webmcp as part of it.

I wanted to make FOSS codegen that was not locked behind paywalls + had wasm plugins to extend it.

Who implements those functions? E.g., store.order has to have its logic somewhere.

I actually do use cross-platform accessibility shenanigans, but for websites this is rarely as good as just doing like two passes on the DOM, it even figures out hard stuff like Google search (where ids/classes are mangled).

seems like skill is a better interface, but state still needs to be externally managed, even if not using mcp as the protocol

So usually MCP tool calls a sequential and therefore waste a lot of tokens. There is some research from Antrophic (I think there was also some blog post from cloudflare) on how code sandboxes are actually a more efficient interface for llm agents because they are really good at writing code and combining multiple "calls" into one piece of code. Another data point is that code is more deterministic and reliable so you reduce the hallucination of llms.

> Having the LLM interpret and understand a page context

The problem is fundamentally that it's difficult to create structured data that's easily presentable to both humans and machines. Consider: ARIA doesn't really help llms. What you're suggesting is much more in line with microformats and schema.org, both of which were essentially complete failures.

LLMs can already read web pages, just not efficiently. It's not an understanding problem, it's a usability problem. You can give a computer a schema and ask it to make valid API calls and it'll do a pretty decent job. You can't tell a blind person or their screen reader to do that. It's a different problem space entirely.

What prevents them with working with live state. Coding agents deal with the live state of source code evolving fine. So why can't they watch a web page or whatever update over time? This seems to be a micro optimization that requires explicit work from the site developer to make work. Long term I just don't see this taking off versus agents just using sites directly. A more long term viable feature would be a way to allow agents to scroll the page or hover over menus without the user's own view being affected.

I really like how the shell and regular API calls has basically wholesale replaced tools. Real life example of worse-is-better working in the real world.

Just give your AI agent a little linux VM to play around that it already knows how to use rather than some specialized protocol that has to predict everything an agent might want to do.

no workie

What do the calls being sequential have to do with tokens? Do you just mean that the LLM has to think everytime they get a response (as opposed to being able to compose them)?

LLMs can use CLI interfaces to compose multiple tool calls, filter the outputs etc. instead of polluting their own context with a full response they know they won't care about. Command line access ends up being cleaner than the usual MCP-and-tool-calls workflow. It's not just Anthropic, the Moltbot folks found this to be the case too.

That makes sense! The only flaw here imo is that sometimes that thinking is useful. Sub-agents for tool calls imo make a nice sort of middle ground where they can both be flexible and save context. Maybe we need some tool call composing feature, a la io_uring :)