There’s a particular kind of idea in tech that shows up quietly, in a spec draft or a GitHub discussion, and only later turns out to have been the thing everyone was actually waiting for. Web MCP might be one of those ideas — or it might be a promising detour. Here’s the case for both.
First, what problem are we even solving?
For the last couple of years, “AI agents that use the web” has mostly meant one of two things:
- Scraping and clicking — an agent takes a screenshot, reasons about pixels and DOM elements, and pretends to be a human with a mouse. This works, but it’s slow, brittle, and breaks the moment a site redesigns its checkout flow.
- Bespoke APIs and connectors — a company builds a dedicated integration (a plugin, a connector, an MCP server) so an agent can talk to their service in a structured way. This is reliable, but it doesn’t scale — someone has to build and maintain a connector for every single site an agent might need to touch.
The Model Context Protocol (MCP), which Anthropic introduced as an open standard for connecting AI models to tools and data sources, solved a version of this for local and server-side tools: instead of every AI app writing its own bespoke integration with every tool, both sides speak one protocol. It’s been widely adopted well beyond Anthropic’s own products.
Web MCP takes that same idea and asks a more ambitious question: what if a website itself could expose an MCP server directly to whatever agent or browser is visiting it? Instead of an agent guessing its way through a UI built for humans, the site would say, in effect, “here’s what I can do, here’s how to ask for it, here’s the schema” — the same way an API does today, but discoverable and usable in-browser, on the fly, without a developer having to hand-build a connector in advance.
The bull case
It fixes the scraping problem at the root. Agents clicking through a checkout page is a workaround for the absence of a machine-readable interface. If the site just exposes “add_to_cart,” “apply_coupon,” and “checkout” as callable tools with defined inputs and outputs, there’s nothing to guess. That’s a categorical improvement in reliability, not an incremental one.
It scales in a way bespoke connectors can’t. Nobody is going to hand-build an MCP connector for every florist, local restaurant, and niche SaaS tool on the internet. But if exposing an MCP server becomes as standard a part of building a website as exposing a sitemap or a robots.txt file, the long tail of the web becomes agent-accessible essentially for free.
It matches how the browser is already evolving. Agentic browsing products — Claude in Chrome among them — are already trying to let an AI act on a person’s behalf inside real websites. Right now that mostly means visual/DOM-based interaction. A native, standardized way for sites to declare their capabilities is the natural next layer underneath that, the same way HTML forms gave browsers a standard way to declare “here’s an input a human can fill out.”
It could realign incentives. Right now, a site that wants AI agents to interact with it well has to either tolerate scraping or build a proprietary integration with whichever AI company they’ve partnered with. A shared, open protocol removes the “pick a side” problem — much as HTTP and open web standards, rather than proprietary online-service protocols, are what let the web itself become universal instead of fragmenting into competing walled gardens.
The bear case
Standards take time, and incentives aren’t automatically aligned. Plenty of good ideas for “let websites describe themselves to machines” have existed for a long time — RSS, microformats, schema.org markup, even the semantic web dream more broadly. Some caught on in narrow ways; most didn’t reach the scale their advocates hoped for, because the parties who’d have to do the work (site owners) don’t always capture the benefit (better agent access), while the parties who benefit (agent builders and users) can’t force adoption.
Security and trust get harder, not easier. An MCP server embedded in a webpage means the page itself is handing your agent a menu of actions to take — including, potentially, actions that benefit the site rather than you. Prompt injection is already a live concern for agentic browsing; a formalized “here are tools you can call” interface is powerful, but it’s also a more concentrated attack surface if a malicious or compromised site can shape what tools it exposes and how they’re described.
Commercial incentives can cut against exposing clean interfaces. A lot of the modern web’s dark patterns — forced multi-step checkouts, buried unsubscribe flows, deliberately confusing pricing pages — exist because friction benefits the business. Those same businesses have limited incentive to expose a tidy cancel_subscription() tool to an agent acting purely in the user’s interest. The sites most worth automating are sometimes the ones least motivated to make automation easy.
“The future” competes with several other futures. Improved vision-and-DOM-based browsing, agent-specific APIs offered by individual companies, and even old-fashioned negotiated partnerships between AI labs and specific platforms are all viable alternate paths. Web MCP doesn’t have to fail for one of these to end up handling most real-world traffic anyway, especially in the near term.
Where this probably lands
The realistic middle path looks less like universal adoption and more like MCP-for-the-web winning in specific niches first: developer tools, documentation sites, e-commerce platforms that want to be agent-friendly as a selling point, and internal enterprise tools where a company controls both the agent and the site. Those are the places where the incentives already point in the same direction — nobody’s fighting an information asymmetry, and reliability matters more than friction.
The more difficult scenario is broader consumer-web adoption, which will probably depend less on the protocol’s elegance and more on whether users begin to demand and expect agent-friendly websites in the same way that they do mobile-friendly ones. It will also depend on browser vendors and major AI providers coming to a consensus on shared expectations rather than competing standards.
The honest answer
Web MCP is an excellent concept that addresses an actual need and fits very well with the current direction of agentic surfing. It has to be seen if it will become the norm, something that every significant website eventually adopts, or just one helpful pattern among many; this will depend as much on trust and economics as on technological quality. It’s too soon to declare it inevitable, but it’s worth keeping a close eye on.