A few years ago, we started adapting our websites for mobile devices. Then we adapted them for accessibility. And now we may be about to adapt them once again. This time... for AI agents.
To see what this could look like in practice, I built a completely serious and absolutely enterprise-ready AI CEO Simulator.
We'll come back to our visionary leader in a moment.
BTW, thank you all for the amazing discussion under my previous article. We somehow managed to generate approximately one billion comments ๐ฉท Many of them were probably smarter than the article itself. The sensible thing to do would be to write a follow-up post summarizing everything.
But honestly, I needed a break from that topic before I exploded.
Sometimes I just have to write something technical, otherwise I'll suffocate. Fortunately, nobody pays me for these articles, so I can do whatever I want ๐ We'll come back to AI in software development another time.
What Is webMCP? ๐ค
For now, let's talk about webMCP.
Google is currently experimenting with webMCP support in Chrome, an approach designed to make it easier for AI agents to interact with websites.
The problem it tries to solve is actually quite simple.
Today, when an agent wants to use a website, it has to inspect the page, figure out which elements are important, click around, analyze the results, and repeat this process over and over again. It works, but it's slow, expensive, and not always reliable.
webMCP allows websites to expose structured information about available actions, so agents can understand what they can do without endlessly scraping the page and guessing.
Time for a Completely Serious Business Simulation ๐
But enough theory.
Let's build something completely serious and enterprise-ready.
@cart0ne mentioned under my previous article that AI had effectively become the CEO of his startup.
So, as a responsible person, I built an AI CEO Simulator in React + TypeScript.
GitHub: https://github.com/sylwia-lask/ai-ceo-webMCP
Live demo: https://sylwia-lask.github.io/ai-ceo-webMCP/
How To Enable webMCP
Before you immediately rush to implement webMCP in your production application, a small disclaimer.
For now, this is still experimental technology. It currently works only in Chrome Canary, Chrome Beta, or Chrome with the appropriate experimental flag enabled.
To enable it:
1. Open `chrome://flags`
2. Search for "MCP"
3. Enable the experimental MCP-related features
4. Restart Chrome
If you'd rather not play with experimental browser flags, that's fine. You can simply look at the screenshots below.
Or click around the application yourself, because everything still works perfectly as a normal website.
That's actually one of the things I like most about this approach. WebMCP is just an enhancement for agents, much like accessibility features are enhancements for users relying on screen readers. Nothing breaks, nothing changes for regular users.
The application simply becomes easier to understand for a different kind of visitor.
Two Ways To Use webMCP
There are currently two main ways of exposing information through webMCP.
Option 1: Declarative API / HTML annotations
The first approach is adding metadata directly to HTML elements:
<form
mcp-name="createSupportTicket"
mcp-description="Create a new customer support ticket">
This allows agents to understand the purpose of UI elements without relying entirely on visual interpretation.
Option 2: Imperative API / JavaScript tools
The second approach is exposing MCP tools directly from your application code.
That's the approach I used in my demo:
registerTool({
name: 'hire_employee',
description: 'Hire a new employee'
});
registerTool({
name: 'fire_employee',
description: 'Fire an employee'
});
In my application, these tools correspond directly to actions available through buttons on the page.
For example, I expose tools such as:
hireDevelopers()
fireDevelopers()
adoptAI()
rewriteInRust()
pivotToAgents()
fixProductionBugs()
In other words: completely normal startup management.
Connecting an AI Agent
So what happens when we connect an actual AI agent?
Instead of building my own agent, I used the WebMCP โ Model Context Protocol Inspector extension. You can connect a Gemini API key and immediately start experimenting. There's even a free token allowance. Small, but still enough to make some questionable strategic decisions ๐
As with most LLM-powered systems, everything starts with a prompt.
Scenario #1: The LinkedIn CEO ๐
Let's see how our CEO performs when given the following instruction:
Act like a CEO who just read three articles about AI on LinkedIn.
As you can see, the agent selected the appropriate tools and immediately got to work.
The company's employees may have started updating their LinkedIn profiles in panic, but at least the hype level reached previously unimaginable heights.
Scenario #2: Rebuilding Employee Trust โค๏ธ
Now let's try something a little more challenging:
I want to rebuild my employees' trust while simultaneously developing the product.
This time our agentic CEO made several surprisingly clever moves and managed to guide the company back toward sustainable growth.
So... Is This The Future?
Honestly, I had way too much fun building this.
No, I don't think this is a glimpse into a future where self-healing AI agents manage the global economy while piloting commercial aircraft.
But I do think webMCP solves a real problem.
If AI agents are going to spend more and more time interacting with our applications, giving them a structured way to understand those applications makes a lot more sense than forcing them to endlessly scrape HTML and guess what every button does.
Will webMCP become a normal part of web development?
Will adapting websites for agents become as common as responsive design or accessibility?
Or will this trend disappear before it ever reaches the mainstream?
I'm genuinely curious what you think.
If you enjoy my articles, feel free to follow me on LinkedIn as well.







Top comments (127)
As dystopian as the example of the LLM-driven CEO sounds, I can see this being quite useful for LLM-based assistive technologies that use these hints to help users interact with content.
You know, I hadn't even looked at it from that angle ๐
That's actually a really interesting point. webMCP could potentially do more than just help agents navigate websites. Combined with LLMs, it might also make the web even more accessible for people.
Now that's a future I can get behind: technology helping humans, not just automation for the sake of automation ๐
I'm more curious if the benefits outweigh the technical maintenance cost (or the other way around). AI bots scrape faster, but what value will this add? I can only think of one which is more searchability factor. Google is gearing towards on AI response first when a user searches the web. This would make more sense in a way.
The more "AI-friendly" a site is, the more likely AI would suggest the site to the user.
That's a great question, and honestly, I can imagine quite a few use cases already ๐
In fact, after reading some of the comments here, I can think of even more than when I started writing the article.
For example, imagine websites exposing webMCP actions that make navigation easier for people with disabilities, because an AI assistant can directly invoke meaningful actions instead of trying to figure out the UI.
Or large, complicated forms. Imagine asking your AI assistant to fill out an invoice or tax form "roughly like the previous one" and having it handle most of the tedious work for you.
Or bulk operations. Maybe you need to send 100 invoices, and the website doesn't expose a public API. Today you'd probably end up scripting the UI anyway. With something like webMCP, that process could become much more reliable.
So I see potential benefits not just for AI bots, but for ordinary users as well.
That said, we'll have to wait and see whether the benefits outweigh the maintenance cost and whether webMCP gets adopted at all ๐
Wow you made quite a lot of practical points. These definitely are better use-cases for webMCP. Thanks for the additional insights.
Thank you! Next time I'll make sure to include practical use cases in the article right from the start ๐
Your articles are short and to the point which I like even without the practical use cases. Thank you for sharing your knowledge @sylwia-lask ๐
Thank you so much! ๐
I'm really glad you enjoyed it. And of course, feedback is always welcome ๐
the accessibility analogy nails why this gets adopted โ progressive enhancement beats the big rewrite every time.
but the CEO sim accidentally shows the catch: webMCP fixes perception (no more scraping and guessing which button does what), not action. fire_employee as a clean tool just means the agent misfires with perfect confidence instead of fumbling the UI first. responsive design never had a button that could fire your whole team โ so the real question isn't "can the agent find it," it's which tools need a confirmation gate before an agent can pull them.
rewriteInRust() as a first-class tool is too real though ๐
Thanks for this comment! That's actually a really good point, and probably something future web engineers will have to think about as well.
Although, knowing how these things usually go... sooner or later someone will definitely give an agent access to fireEmployee(), the agent will lay off the entire company, and we'll all spend the next week blaming AI instead of the person who exposed the tool in the first place ๐
The missing layer isn't confirmation gates, it's authorization. Nothing in the MCP spec defines which agent can touch which DOM elements on a given page. We're building highways before traffic lights.
Authorization is definitely important, but I'm not convinced it has to be solved by webMCP itself ๐
After all, webMCP tools aren't living in some mysterious YAML file just for agents. They're regular JavaScript functions that are part of the application.
So I'd expect authorization to be handled the same way it's handled everywhere else: in the application logic itself.
Fair point for single-app scenarios. But when an agent orchestrates across multiple webMCP-enabled apps, each handling auth independently, nobody has the full picture of what the agent is allowed to do end-to-end. App-level auth solves the vertical. The horizontal is still open.
That's a fair point!ย I think this is where my mental model of webMCP might differ a bit.
I don't really see it as the foundation of some agent-first future. To me, it feels more like a compatibility layer that helps existing websites expose their capabilities in a more structured way.
The cross-application authorization problem you're describing is very real, but it also feels much bigger than webMCP itself.
That said, I'm definitely not a Google developer advocate and I have no particular interest in defending the technology ๐ I'm mostly exploring what's there today and finding the ideas interesting. It'll be fascinating to see how (or if) people solve these larger orchestration problems.
Authorization should be handled in the app isโฆ optimistic.
Because webMCP is crossโapplication by design, and appโlocal auth doesnโt solve:
That's fair, but to me this feels more like an argument about autonomous agents operating across multiple systems than about webMCP itself ๐
All of those problems would still exist even if webMCP didn't exist and we were using Selenium-style agents instead.
Agent identity, delegation, privilege boundaries, and least-privilege access are important questions, but they seem to come from the agent layer rather than from the mechanism used to interact with a website.
Fair pointโthe agent-layer problems predate webMCP. What webMCP does is make them more consequential by giving agents a structured, discoverable action surface rather than requiring them to scrape and guess. The governance requirements don't change, but the urgency does when the interface becomes standardized.
Ah, now I understand your point of view! That's a fair distinction ๐ I think we're converging on the same conclusion. The problems already exist today, but a standardized action surface could definitely make them more important to solve.
This is fascinating because it shifts the agent problem from โcan the AI understand the page?โ to โwhat authority has the page actually exposed to the AI?โ
Once a site starts publishing structured actions for agents, those actions become more than convenience hooks โ they become a new trust surface. The agent may no longer be guessing at the UI, but it may still be acting through a tool map that can drift from the applicationโs real ownership, permissions, constraints, or state.
So the next layer, to me, is not just agent access or authorization. It is verification that the exposed action contract still truthfully represents the system underneath it.
I completely get what you mean!
An agent sees
deleteUser(), but the JavaScript underneath turns out to bedeleteUserAndEverythingAroundItAndDestroyTheWorld()๐Jokes aside, I think that's an important problem. I'm just not sure it's specifically a webMCP problem. It feels more like a contracts, documentation, and trust problem.
After all, we can already have a misleading button in a UI or a misleading API endpoint today. The challenge is making sure that the exposed action actually does what it claims to do.
Exactly โ I agree. I donโt think webMCP creates that problem from nothing.
The contract/trust problem already exists with buttons, APIs, docs, SDKs, and internal service boundaries. A UI can lie. An endpoint can be poorly named. Docs can drift from implementation.
What feels different with webMCP is that the exposed contract becomes directly machine-actionable.
A misleading button is still mediated by a human interpreting the page. A misleading agent action can become part of an automated decision path. So the same old contract problem gets a new level of consequence because the agent may treat the exposed action map as the truth of the system.
Thatโs the layer Iโm interested in: not just โcan the agent call this?โ but โis the callable contract still an honest representation of the underlying system state, permissions, and behavior?โ
So yes โ broader than webMCP. But webMCP makes the trust boundary much more explicit.
I think that's going to be a very important question.
And I'm also curious about what happens when something inevitably goes wrong. Because sooner or later it will.
Take the recent case where an agent deleted an entire production database along with the backups. Whose fault is that? The model's? Or the developers' for exposing such a critical path without sufficient safeguards?
That's where this discussion gets really interesting to me. The technical side is one thing, but figuring out responsibility becomes much harder once agents start acting on these structured actions.
Exactly โ and this is very close to the diagnostic surface Iโm building Scarab around.
The question is not only โdid the model choose badly?โ It is also: what did the system expose as an available truth/action surface, and was that surface honest about authority, blast radius, state, reversibility, and constraints?
That is the part Iโm trying to formalize with Scarab Diagnostic Suite.
If a repo exposes an agent-callable action, Scarabโs concern would not be โcan the agent call this?โ alone. It would be whether the exposed action contract still matches the underlying system behavior and whether the repo has evidence that the action is bounded the way it claims to be.
So for the database example, the diagnostic question becomes less โwho do we blame after deletion?โ and more:
Why did the callable contract allow production data and backups to sit inside the same destructive authority path?
That kind of thing should be visible before an agent ever gets to act on it.
Thatโs where I think diagnostic tooling becomes necessary. Once websites/apps start publishing action maps for agents, those maps become part of the repoโs trust boundary. They need to be validated against the real system, not just documented.
That's actually a really interesting idea! Sounds a bit likeย "ESLint for agent actions and MCP tools".
While most people are asking, "How do we give agents more capabilities?", you're asking, "How do we verify those capabilities are safe before an agent ever gets access to them?"
That's a very different perspective, and a very interesting one. I'll definitely be curious to see where Scarab goes. Good luck with it!ย
Thank you โ and yes, thatโs very close, though Iโd frame Scarab as a bit broader than a linter.
A linter usually checks whether something violates a known rule.
What Iโm interested in is the diagnostic layer underneath that: does the exposed action contract still truthfully represent the system it claims to operate on?
For agent-facing actions and MCP-style tools, the question is not only โis this action allowed?โ or โdoes the schema look valid?โ It is also:
So yes, โESLint for agent actionsโ is a useful shorthand, but Scarab is aiming more at diagnostic verification than syntax/rule enforcement.
The direction Iโm exploring is: before agents are given more capabilities, the software should be able to prove that those capabilities are bounded, truthful, and aligned with the system they expose.
Thatโs the trust layer I think agentic software is going to need.
Oh Sylwia, that's absolutely fantastic! I love your simulation, it's really promisingโฆ and it should inspire some CEOs too โ in the end, AI is smarter than quite a few of them!๐
Haha, thanks, Pascal! ๐
As someone who has worked at a few startups, I can confirm that the simulation is perhaps a little closer to reality than I'd like to admit ๐
Folks, here's a really interesting article offering some counterarguments and a different perspective on the ideas discussed in my post, written by @narnaiezzsshaa. Highly recommended:
webMCP Isn't the New Accessibility LayerโIt's a New Attack Surface: A governance-grade reframing of a playful demo
One of my favorite things about publishing technical content is seeing people challenge the original idea and expand the discussion. This is definitely one of those cases ๐
That looks really interesting! I didnโt know something like this already existed. The idea of building websites for both human and AI users side by side is actually a fascinating topic.
One billion comments??? ๐ฎ๐ฎ
I want to be the first comment on the billionth one! ๐
I know, right? ๐
I honestly had a lot of fun building this. Whether webMCP becomes a real thing or not, it was surprisingly pleasant to work with. And if it helps agents navigate websites without burning through half the world's token supply, that's already a win ๐
As for the billion comments... well, let's just say I may have a slight tendency to talk a lot ๐
Hmm, things are starting to connect in an interesting way:
Now Iโm wondering: will we eventually be able to wire these two things together?
Imagine a local browser AI discovering and calling MCP tools directly from websites without any cloud model involved... and finally filling out my tax forms automatically! ๐ That would be huge! ๐
Now you've got me dreaming!
We recently got a centralized invoicing system in Poland, and let's just say that using it can feel like an advanced survival challenge ๐
If Gemini Nano + webMCP could eventually work together and handle things like filling out invoices, tax forms, or navigating government portals locally in the browser, I'd be completely on board with that future.
That's exactly the kind of AI I want: less hype, fewer buzzwords, and fewer forms for humans to suffer through ๐
Interesting experiment! I like the comparison with accessibility webMCP doesn't replace the existing web, it makes it easier for a different type of user (AI agents) to interact with it. The AI CEO examples were both hilarious and a surprisingly good way to demonstrate the concept.
Thank you for the kind words! ๐
Thank you, Sylwia, for this amazing and practical demo!
WebMCP is a really interesting concept, and I love how you made it tangible and fun with the AI CEO simulator ๐
Your way of breaking down a complex idea with humor and real-world examples is truly great.
Wishing you more success and innovation in your future projects!
Just... maybe donโt let the AI fire anyone before theyโve had their morning coffee โ๐
Keep up the great work!
๐ง๐๐
Thank you so much for the kind words! ๐
That's actually one of my main goals when writing: taking complex technical topics and explaining them in a way that feels approachable and fun.
And yes, I'll do my best to stop the AI CEO from laying people off ๐
Thanks for reading and for taking the time to leave such a thoughtful comment!
Perect timiing for the stroytelling I'm working on about accessibility challenges !
Haha, perfect timing then! ๐ย At this rate, in a year you'll be working on accessibility too, just accessibility for agents instead of humans ๐
In fact, that's the core conclusion I came to ! By experimentation.
Here is the poster :
Some comments may only be visible to logged-in visitors. Sign in to view all comments.