This feels inverted and impractical in so many ways.
On one hand the claims are being made that AI is smart enough to replace software engineers and on other hand the website owners are beings asked to provide information in a certain format to the Agents so they can do their job better. Remember this is the same information that every regular user is able to use.
Secondly if you maintain two versions of information, one for regular humans and one for agents, its just a matter of time before they start to diverge from each other. One can pick up and compare the native app and Browser application for any company, 99% chances are they are not exactly the same.
I think it's an efficiency thing. And at scale, efficiency matters. Whether this is the right implementation idk, but when I see Claude Code use Chrome via MCP, it's incredible to see just how inefficient the status quo is.
> Remember this is the same information that every regular user is able to use.
This is not true. The users don't see the HTML, CSS and JavaScript. If they would, even if they're frontend devs, they'll be just as confused as the agents.
The user see images, and while you can make the agents see the image as well, unlike humans the effective agents we have today work with text, not images.
To clarify, I am referring to the information present on the webpage which the users using the website are already consuming. The page already has a structure, thats how browser is able to display it to end user. Its just not tailored explicitly to a agent.
Lets leave the image vs text from the discussion from now, its a altogether different challenge.
The structure already exists for a particular set of client , browsers in normal scenario here. The debate is on the topic of relative value from maintaining two different set of structures, one for browsers and another for agents
This is going to sound incredibly silly but I have every HTMX component expose an AI summary with actions possible and then I have a small copy to AI button on the page which creates a new short-lived access token and copies into a prompt the token, and all the components as text.
When I give this even to relatively small-model agents, they use this initial seed to browse the site and do things very well.
The initial prompt suffices. After that most agents just use the HTML to navigate very well. I suppose I could have that description in an aria label if I wanted but it’s the same.
I don't know anything about you or where you're based.
but in Main Street US - guess what the dentists are using ? guess what the auto-shop is using, the auto-dealer ?
mostly desktop software running on on-premise hardware, with some using cloud version but just being a small population overall. most of the software has no APIs, & no web version.
it's not sexy, nor fun. actual FDEs are needed for those industries, if anything A.I will unlock so much lost productivity.
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.
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?
I'd also throw in schema.org Potential Actions as longstanding precedent for declaring what is on offer from the page. https://schema.org/docs/actions.html
It does get a bit tricky though. WebMCP allows the page to respond to the agent. Where-as these other systems the page itself has to update and respond.
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.
This is interesting, but instead of tying it to a specific JS library and all I’d prefer putting a list of options and their arguments into the .well-known tree.
That way any user agent can get the data and make a call directly to the right endpoint with the right data. It could be an AI agent, a web browser, a specialized tool, a cURL command, or whatever.
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.
One argument for the client/browser side: when the logic only exists in
the frontend (validation, pricing rules), a server-side MCP would have to
reimplement it and the two copies drift. Running the action inside the
user's own session also means no long-lived API tokens handed to the
agent — the agent's access dies with the tab.
Yeah I call those legacy frontends because I see not having that business logic serverside in 2026 as a dated concept. Client side heavy SPAs still have some niche use cases, so automation makes sense there but generally you should be aiming for proper server stuff and not over relying on crutches. Adding an MCP or chat agent or APIs is a good excuse to build that out properly for machine consumption. That's the future. Web browser consumption is a temporary stopgap.
I think pinning WebMCP to the browser was the wrong choice. To list or call tools, you have to have access to the browser environment. "Declarative" WebMCP allows you to read the HTML, but to call tools you still need the JS execution env.
This limits the utility of WebMCP to in-browser agents. In practice, what's the use case? Computer Use can work, but at that point you can circumvent WebMCP entirely.
IMO the better option would be to unify MCP with a standard protocol, like HTTP. Right now, you have to rely on the MCP registry for discovering MCP servers, but wouldn't it make more sense to have this natively in HTTP?
IMO this relates to who the end consumer of websites ends up being. All the arguments for just using MCP ignore the reasoning that agents need based on contextual clues (e.g. if you're booking seats at a movie theaters, you'd want to choose based on personal preferences and taking the movie itself into account) and treat the website itself as the first class product.
Developing MCPs only works if the capabilities for the site don't involve any iterative reasoning and acting for the user, which things like travel and dining do :p
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.
I hope this works out. It seems helpful but we can’t even get a lot of web sites to format their user/password fields or address fields to work correctly with password managers and autofill. This has to be more complicated than that.
Yes, and the form fillers are also terrible. I have and need a street and number field. Iphone puts the number behind the straatnaam and leaves the huisnummer field empty.
If enough websites have duplicate functionality it should most likely be implemented in the browser.
Let Mozilla or Alphabet define an API for country addresses and let national registers implement it.
Having some tiny website buy a db with an outdated version of ALL the worlds addresses is terrible. People with new addresses buy a disproportionate amount of stuff.
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"!
But it is not a pretense or disguise though if that's what they are doing right? Like its clearly an AI thing and the other benefits are side effects. But not everything is inception.
I think of it as similar to how SEO encouraged a lot of sites to start using more accessible markup and headings, which resulted in accessibility improvements even though the developers weren't thinking about that at all.
It’s a nice idea but I don’t know if it will help.
The history of the web is one big loop of:
1. Nifty feature that’s suitable for a wide variety of user agents, from GUI browsers to screen readers to text interfaces to automation.
2. Approximately 0.1% of web sites adopt it properly. The rest hack up something that mostly works for most of their visitors while ignoring any use case outside of a human driving a mainstream browser.
3. Automation works around it by pretending to be a human driving a mainstream browser.
4. Other cases should be handled better, so let’s add a nifty new feature that’s suitable for a wide range of things. Goto 1.
See: forms, CSS, “semantic web.” Even REST APIs mostly exist as monstrous piles of client-tied functionality that can’t be reasonably used from a client other than the company’s official apps and web site.
The thing I'm far more interested in than WebMCP is who are the supposed 50 people that have opened this slop and decided it was worthy of their upvote.
This isn't for when you are looking at the restaurant booking page, it's for when your agent is on that page. Personally I don't need an agent to help me with this specific problem, but I could see it being a real boon for people with accessibility needs.
Sometimes it helps to not think of why we should reject things but instead to think of why someone might accept them.
I think the notion that the solution to accessibility is to place a unreliable agent in-between is ludicrous.
If a page has good accessibility an agent should have no problem to interact with it. If WebMCP becomes an acceptable solution for accessibility then the only way people who need accessibility will be able to interact with services is via agents.
Absolutely. I am always complaining that natural language creation of calendar events is not a thing. “Meeting next Thursday at 9 am at the starbucks near me”
"Hey AI, find me a X cuisine restaurant around Y location that has availability at 7pm tonight" .. "Cool, book Z"
Seems obvious why an API would be helpful on that page instead of having the AI attempt to navigate the page, open up a date picker and click all around..
And as others have said, if you are disabled in some way being able to just speak and get something like this done seems pretty life changing.
The accessibility tools most computers have had since the 90's? Apple has a plethora of screen navigation tools in their OS's. Or, calling the restaurant and booking a table directly in this case.
This feels inverted and impractical in so many ways.
On one hand the claims are being made that AI is smart enough to replace software engineers and on other hand the website owners are beings asked to provide information in a certain format to the Agents so they can do their job better. Remember this is the same information that every regular user is able to use.
Secondly if you maintain two versions of information, one for regular humans and one for agents, its just a matter of time before they start to diverge from each other. One can pick up and compare the native app and Browser application for any company, 99% chances are they are not exactly the same.
I think it's an efficiency thing. And at scale, efficiency matters. Whether this is the right implementation idk, but when I see Claude Code use Chrome via MCP, it's incredible to see just how inefficient the status quo is.
I agree it's not a good idea, but:
> Remember this is the same information that every regular user is able to use.
This is not true. The users don't see the HTML, CSS and JavaScript. If they would, even if they're frontend devs, they'll be just as confused as the agents.
The user see images, and while you can make the agents see the image as well, unlike humans the effective agents we have today work with text, not images.
To clarify, I am referring to the information present on the webpage which the users using the website are already consuming. The page already has a structure, thats how browser is able to display it to end user. Its just not tailored explicitly to a agent.
Lets leave the image vs text from the discussion from now, its a altogether different challenge.
This is not a smart reply. Structure is always good otherwise why even create unit tests and compilers?
The structure already exists for a particular set of client , browsers in normal scenario here. The debate is on the topic of relative value from maintaining two different set of structures, one for browsers and another for agents
[dead]
> 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?
That’s part of webmcp :)
[flagged]
[flagged]
This is going to sound incredibly silly but I have every HTMX component expose an AI summary with actions possible and then I have a small copy to AI button on the page which creates a new short-lived access token and copies into a prompt the token, and all the components as text.
When I give this even to relatively small-model agents, they use this initial seed to browse the site and do things very well.
The initial prompt suffices. After that most agents just use the HTML to navigate very well. I suppose I could have that description in an aria label if I wanted but it’s the same.
I'd be interested to read a blog post with more details about how this works.
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.
APIs and WebMCP don't have the same purpose:
- WebMCP allows agents to assist humans on their own interface ie the web UI.
- APIs bypass the human interface completely
And I'm not sure most of the work today is done on legacy desktop apps. We're in 2026, not 2016
I don't know anything about you or where you're based.
but in Main Street US - guess what the dentists are using ? guess what the auto-shop is using, the auto-dealer ?
mostly desktop software running on on-premise hardware, with some using cloud version but just being a small population overall. most of the software has no APIs, & no web version.
it's not sexy, nor fun. actual FDEs are needed for those industries, if anything A.I will unlock so much lost productivity.
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?
The Apple standard-positions in this was a pretty good read, noting indeed that this is a parallel new way to define accessibility. https://github.com/WebKit/standards-positions/issues/670
I'd also throw in schema.org Potential Actions as longstanding precedent for declaring what is on offer from the page. https://schema.org/docs/actions.html
It does get a bit tricky though. WebMCP allows the page to respond to the agent. Where-as these other systems the page itself has to update and respond.
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.
This is interesting, but instead of tying it to a specific JS library and all I’d prefer putting a list of options and their arguments into the .well-known tree.
https://en.wikipedia.org/wiki/Well-known_URI
That way any user agent can get the data and make a call directly to the right endpoint with the right data. It could be an AI agent, a web browser, a specialized tool, a cURL command, or whatever.
https://agenticresourcediscovery.org/how_to_publish/ and the caldav stuff might serve as decent examples of where to start.
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.
One argument for the client/browser side: when the logic only exists in the frontend (validation, pricing rules), a server-side MCP would have to reimplement it and the two copies drift. Running the action inside the user's own session also means no long-lived API tokens handed to the agent — the agent's access dies with the tab.
Yeah I call those legacy frontends because I see not having that business logic serverside in 2026 as a dated concept. Client side heavy SPAs still have some niche use cases, so automation makes sense there but generally you should be aiming for proper server stuff and not over relying on crutches. Adding an MCP or chat agent or APIs is a good excuse to build that out properly for machine consumption. That's the future. Web browser consumption is a temporary stopgap.
I think pinning WebMCP to the browser was the wrong choice. To list or call tools, you have to have access to the browser environment. "Declarative" WebMCP allows you to read the HTML, but to call tools you still need the JS execution env.
This limits the utility of WebMCP to in-browser agents. In practice, what's the use case? Computer Use can work, but at that point you can circumvent WebMCP entirely.
IMO the better option would be to unify MCP with a standard protocol, like HTTP. Right now, you have to rely on the MCP registry for discovering MCP servers, but wouldn't it make more sense to have this natively in HTTP?
IMO this relates to who the end consumer of websites ends up being. All the arguments for just using MCP ignore the reasoning that agents need based on contextual clues (e.g. if you're booking seats at a movie theaters, you'd want to choose based on personal preferences and taking the movie itself into account) and treat the website itself as the first class product.
Developing MCPs only works if the capabilities for the site don't involve any iterative reasoning and acting for the user, which things like travel and dining do :p
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.
Explainer i.e. proposal: https://github.com/webmachinelearning/webmcp/blob/main/decla...
I hope this works out. It seems helpful but we can’t even get a lot of web sites to format their user/password fields or address fields to work correctly with password managers and autofill. This has to be more complicated than that.
Yes, and the form fillers are also terrible. I have and need a street and number field. Iphone puts the number behind the straatnaam and leaves the huisnummer field empty.
If enough websites have duplicate functionality it should most likely be implemented in the browser.
Let Mozilla or Alphabet define an API for country addresses and let national registers implement it.
Having some tiny website buy a db with an outdated version of ALL the worlds addresses is terrible. People with new addresses buy a disproportionate amount of stuff.
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.
This whole thing reminds me of the "I am writing to inform you that a fire has broken out..." scene from IT crowd. It's ridiculously inefficient.
"Picture an AI agent trying to book you a table on a restaurant’s website. "
Are we there already? asking because I genuinely cannot find an agent that will do this end to end for me.
Use Claude Code with Chrome MCP / Claude in Chrome and it'll happily do it for you, 100%
This is from 2018
https://www.youtube.com/watch?v=D5VN56jQMWM
>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 don't see why WebMCP is a big deal, rather invest in creating a better MCP or CLI that can do what your website can
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"!
But it is not a pretense or disguise though if that's what they are doing right? Like its clearly an AI thing and the other benefits are side effects. But not everything is inception.
I think of it as similar to how SEO encouraged a lot of sites to start using more accessible markup and headings, which resulted in accessibility improvements even though the developers weren't thinking about that at all.
Imagine if we can trick software engineers into tolerating AI by marketing it as accessibility!
Which has happened countless times here already.
Hey are we re inventing Tim berners Lee solid protocol
It’s a nice idea but I don’t know if it will help.
The history of the web is one big loop of:
1. Nifty feature that’s suitable for a wide variety of user agents, from GUI browsers to screen readers to text interfaces to automation.
2. Approximately 0.1% of web sites adopt it properly. The rest hack up something that mostly works for most of their visitors while ignoring any use case outside of a human driving a mainstream browser.
3. Automation works around it by pretending to be a human driving a mainstream browser.
4. Other cases should be handled better, so let’s add a nifty new feature that’s suitable for a wide range of things. Goto 1.
See: forms, CSS, “semantic web.” Even REST APIs mostly exist as monstrous piles of client-tied functionality that can’t be reasonably used from a client other than the company’s official apps and web site.
The thing I'm far more interested in than WebMCP is who are the supposed 50 people that have opened this slop and decided it was worthy of their upvote.
"Sponsored by Google"
[flagged]
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?
This isn't for when you are looking at the restaurant booking page, it's for when your agent is on that page. Personally I don't need an agent to help me with this specific problem, but I could see it being a real boon for people with accessibility needs.
Sometimes it helps to not think of why we should reject things but instead to think of why someone might accept them.
I think the notion that the solution to accessibility is to place a unreliable agent in-between is ludicrous.
If a page has good accessibility an agent should have no problem to interact with it. If WebMCP becomes an acceptable solution for accessibility then the only way people who need accessibility will be able to interact with services is via agents.
It does mention something about "using the page you're already logged into" so I presumed that it meant the browser you had open in front of you
Absolutely. I am always complaining that natural language creation of calendar events is not a thing. “Meeting next Thursday at 9 am at the starbucks near me”
"Hey AI, find me a X cuisine restaurant around Y location that has availability at 7pm tonight" .. "Cool, book Z"
Seems obvious why an API would be helpful on that page instead of having the AI attempt to navigate the page, open up a date picker and click all around..
And as others have said, if you are disabled in some way being able to just speak and get something like this done seems pretty life changing.
But you go ahead and be mad about an api...
Right, because disabled people have been sitting at home not able to book a restaurant until now
If I have an injury or I am disabled, then yes, an agent helping me fill out forms might be a life-changing improvement.
We already have accessibility tools for that
Which ones?
The accessibility tools most computers have had since the 90's? Apple has a plethora of screen navigation tools in their OS's. Or, calling the restaurant and booking a table directly in this case.
This is immeasurably better.
Well one works reliably and the other is "agentic" AI
They couldn't get a biometric voice sample and unique identifier without this AI crap. And people here cheer it on.