WebMCP Wants to Make Websites Work for AI Agents

The web was built for human eyeballs. Every design decision — the button placement, the product carousel, the checkout flow — assumes a person is doing the looking and the clicking. That assumption has held for thirty years. It is now running into something new, and the collision is more interesting than most of the AI coverage you've read this week.

The new visitor is an AI agent. Not a scraper, not a bot in the old spam sense — an agent acting on someone's behalf, with their context and their goals, trying to complete a task. Book the appointment. Compare the machines. Apply the coupon. File the claim. The problem is that websites are not built to be understood by agents any more than a restaurant menu is designed to be read by a blind kitchen robot. The structure is implicit, the logic is buried in HTML, and the authentication is a wall the agent can't easily climb.

Greg Isenberg and a developer he identifies only as Vince walked through a technology called WebMCP in a recent episode that deserves more attention than the usual startup-idea podcast typically earns. The core concept is simple enough to state in one sentence: a website can declare a clean list of things an agent is allowed to do, and an agent can call those things directly, without parsing the entire page.

Vince demonstrates this on an espresso gear store. He wants to upgrade his machine, needs something that fits a 32-centimeter counter space and can handle two flat whites a day. His agent talks to the store's WebMCP tools, pulls up two machines side by side, and highlights the specs that answer his actual question — porta filter compatibility, dimensions, capacity. Then he asks what accessories fit the machine he's chosen. The agent consults the store's tool list, finds the right items, adds one to his cart, and applies a coupon it discovered in the process. Vince watches it happen in real time on screen.

I want to stop there and translate this out of espresso-nerd territory, because that's where it gets genuinely interesting.

If you are a 68-year-old comparing Medicare supplement plans and you have an agent that knows your doctors, your prescriptions, and your budget, that agent could — in principle — navigate an insurance company's website the same way Vince's agent navigated the coffee store. Not by scraping confusing plan grids, but by calling tools the insurer explicitly provides: check my doctors are in-network, compare Plan G and Plan N for my zip code, tell me the out-of-pocket maximum. The same logic applies to the person buying a hearing aid and needing to know which models are compatible with their audiologist's fitting software, or the small business owner trying to figure out which accounting package integrates with their existing payroll setup. The complexity that currently forces people to call a sales line or muddle through on their own is exactly the problem WebMCP is designed to dissolve.

What makes this more than a nice demo is where it sits technically. Vince walks through the landscape of how agents currently meet applications: raw APIs require the agent to hold authentication tokens and do significant integration work; browser agents that read the full DOM are slow and brittle because they're essentially screen-reading; in-app agents built by vendors lock you into that vendor's model. As Spronta noted in a July 2026 assessment, WebMCP occupies a genuinely different position — it sits inside the browser session, which means the user's existing login handles authentication automatically. Log in, and the full tool list appears. Log out, and it shrinks to whatever the site makes publicly available. No API keys. No token management. No separate authentication layer for the agent to navigate.

"It's like the least technical approach to making an app or a website or web store agent native," Vince says, "but with the most flexibility and the most features."

That's a reasonable description of why this approach has traction. The question is whether it has enough.

WebMCP is still experimental — Isenberg and Vince are clear about that. It requires enabling Chrome flags and allowing remote debugging, which is not something any normal user will do unprompted. That's a meaningful constraint right now. But the signal worth watching is at the infrastructure level. Cloudflare has previewed automatic WebMCP support for web pages, according to InfoQ. When a company that sits between hundreds of millions of websites and the internet decides to build automatic support into its platform, that tells you something about where the infrastructure bets are going. Cloudflare does not build things it expects to stay experimental.

I think WebMCP wins the middle ground — not because the demo is impressive, but because the authentication architecture is right. Every previous approach to making websites agent-readable forced someone to do extra work: the developer had to maintain a separate API, the agent had to carry credentials, or the operator had to deploy and pay for an in-app model. WebMCP's browser-session approach eliminates most of that friction. The user already logged in. The agent rides that session. That's not a clever hack — it's the correct layering.

Isenberg's two business ideas follow from this naturally. The first is an agency that makes traditional business websites — law firms, medical practices, home service companies — agent-ready by building out a starter set of WebMCP tools: request a quote, book a consultation, check availability. Isenberg proposes setup fees and ongoing monitoring retainers, figures he laid out in the episode that I won't repeat without more precise attribution. The second idea he calls the "agent mystery shopper" — an automated testing service that runs agents through the key user journeys on a site and reports back where they fail. Where does the agent get stuck? What tools are missing? What product descriptions are so ambiguous that no agent can work with them? Sell that as a recurring report.

The mystery shopper idea is the one I find genuinely useful, and not only as a business. It is essentially a new kind of quality audit — not for human usability, but for agent legibility. Those are not the same thing. A page can be beautifully designed for humans and completely opaque to an agent. The businesses that discover that gap early will have time to close it. The ones that discover it when their competitors' sites are already completing agent-driven purchases will not.

"I don't want to use your product's agent," Vince quotes a sentiment circulating in developer conversations. "I want my agents to be efficiently enabled to use your product." That preference — one agent, portable context, works everywhere — is where the consumer market is heading. The question for every business with a website is not whether agents will visit, but whether the site will make sense to them when they do.

The web was built for human eyeballs. For three decades, that was fine. The humans doing the looking and clicking are now, increasingly, delegating that work. Whether the web meets them — or forces them to navigate the same confusing pages that were already a problem — is a design decision that businesses are making right now, mostly by not making it at all.

---

By Bob Reynolds, Senior Technology Correspondent, BuzzRAG