WebMCP Breaks Synthetic Monitoring. Nobody Has Noticed Yet.

Greg Isenberg spent the closing minutes of a recent episode of The Startup Ideas Podcast pitching a business he called the Agent Mystery Shopper. You point an AI agent at the journeys that matter, buy the hoodie, book the consult, file the claim, reorder the item, and you send the site owner a report. Where did the agent get stuck? Were the descriptions bad? Were tools missing? Where is the conversion risk? Charge a hundred dollars a month, a few hundred for a bigger client.

It is a good idea. It is also synthetic monitoring, which our industry has been selling since the late 1990s, and which most people reading this already have running.

That is not a dig at Greg. It is the most useful thing in the episode, because it tells you where this is heading. When a marketing audience independently reinvents scripted transaction checks, the discipline is about to acquire a large new population of users who have never heard of it and will not use a single one of our words.

The better question is not whether they have reinvented our wheel. It is whether our wheel still turns.

WebMCP is a proposed browser standard that lets a website hand an AI agent an explicit list of things it can do, instead of making the agent work it out by reading the page. Google's Chrome team opened it to early preview participants in February 2026, describing it as a way of "exposing structured tools, ensuring AI agents can perform actions on your site with increased speed, reliability, and precision". There are two halves: a declarative one that rides on ordinary HTML forms, and an imperative one in JavaScript for anything dynamic.

Isenberg's guest Vinny, who built the demo the episode is based on, put it more plainly. It is MCP, in the browser, in the user interface. If you know what MCP is, you are most of the way there. The difference is that the tools live inside the page the human is already looking at, rather than on a server the agent connects to separately.

His demo is an espresso equipment shop. He asks his agent for a machine that will make two flat whites a day and fit a 32 cm counter. The agent calls the shop's tools, puts two machines side by side, highlights the specifications that match, works out which portafilter fits, adds a water softener to the basket and applies a coupon. Sixteen tools are exposed on that store. Three of them are visible when he logs out.

That last detail is the one to hold on to.

Before WebMCP, an agent working a website had two options, and both were miserable. Computer use means screenshotting the screen and clicking things like a person. Browser automation means pulling the entire DOM and reasoning about which element to interact with. Vinny's description of both is fair: slow and fragile.

Exposing a short list of named tools removes the guessing. It is faster, it is cheaper in tokens, and it fails in ways you can actually explain.

The authentication model is cleverer still. There are no API keys and no separate credential exchange. The browser session is the auth layer, so the tools available to the agent are conditional on who is logged in. Sixteen tools signed in, three signed out. For anyone who has spent a quarter arguing about token custody for an MCP server, that is a real simplification.

And it sidesteps the thing users have started to resent, which is being forced to use a vendor's own in-app assistant. People want to bring the agent they already have, with their own context and history, and use it on your site. WebMCP lets them.

So far, so good. Now the part nobody is discussing.

Determinism goes. A synthetic check today is a fixed script. Go to the URL, click this selector, assert that text. Under WebMCP the agent decides which tools to call and in what order, so the same intent produces a different path on every run. Reproducibility is the assumption the entire discipline rests on. When a run fails you inherit a triage problem that does not exist today: is the site broken, or did the model simply choose badly? Nobody has written that runbook.

The tool manifest becomes a monitored surface. A tool quietly dropping out of the manifest after a deploy is an outage for agent traffic and completely invisible to a browser check. So is a schema that drifts. And because the manifest is conditional on session state, an unauthenticated probe sees a fraction of your surface. You need a check per persona, because logged out, logged in and entitled are now three different products.

Prose enters the failure path. The agent picks tools by reading their descriptions. That means a badly worded sentence is a reliability defect, sitting in production, with no version control and no review gate. Isenberg's own report format lists "bad descriptions" as a finding, which is the correct instinct and a strange thing to have to monitor.

Real user monitoring starts describing fewer of your users. Largest Contentful Paint, layout shift, interaction delay, rage clicks, session replay. An agent has no viewport, perceives no layout shift and never rage clicks. Your Core Web Vitals will keep looking healthy while the population they measure quietly shrinks. What replaces them is unglamorous and familiar: rate, errors and duration on tool invocations, plus task completion and the distribution of which tools get chosen. The four golden signals survive intact. The object they point at moves.

This is experimental. It sits behind a Chrome flag, the demo asks you to enable remote debugging, and adoption outside demos is close to nothing. Vinny says as much on the episode. Anyone telling you to rebuild your monitoring strategy this quarter is selling something.

There is a real security question the episode skates past, too. If the browser session is the auth layer, then a prompt injection on a page becomes a route to making somebody's authenticated agent act on their behalf. The suggested mitigation, shipping read-only tools in regulated sectors, is a sensible start and not an answer. The operational question underneath it is harder: how would you detect an agent being talked into calling a destructive tool? That is an agent observability problem before it is a browser problem.

And the telemetry does not exist yet. The OpenTelemetry project has been building GenAI semantic conventions covering model identity, token accounting and execute_tool spans, and they are under active development. They are also server-side. There is currently no agreed way to say that an agent called a named tool on a given page, with these arguments, and it took 400 milliseconds. That gap is the most interesting thing in this whole story, and it is the one an observability community could close.

If you run a complex commerce site, a self-service portal or an admin console, this is worth an afternoon. Not to implement, but to answer one question honestly: if a third of your journeys were completed by agents next year, what would you currently see? For most teams the answer is a page-load metric and a scripted check that no longer represents anybody.

If you run internal tooling, it is a safer place to experiment than anything customer facing, and Vinny is right that it is where most people should start.

If you are a monitoring vendor, someone is about to sell your product to your customers' marketing department under a better name, and the difference between observability and monitoring is about to matter commercially rather than philosophically.

The ladder Isenberg draws is a good one. SEO asked whether Google could understand the page. Answer engine optimisation asked whether the AI would cite you. WebMCP asks whether the agent can finish the job.

There is a fourth rung, and nobody has named it. Can you tell when it doesn't?

A proposal in early preview. Google's Chrome team opened it to early preview participants in February 2026, it sits behind a browser flag, and adoption outside demos is close to nothing. Nothing here needs to be on your roadmap this quarter.

No. The useful move is much smaller. Take one journey you already monitor and ask what you would actually see if an agent completed it instead of a person. For most teams the answer is a load-time metric and a script that no longer represents anybody, and knowing that is worth more today than a rebuild.

Determinism. A scripted check asserts a fixed route, and under WebMCP the agent chooses which tools to call and in what order, so the same intent walks a different route each run. The second thing is the tool manifest itself, which becomes a surface you have to watch: a tool quietly dropping out after a deploy is an outage for agent traffic and completely invisible to a browser check.

Yes, and that is the part with the most operational consequence. The browser session is the auth layer, so signed out, signed in and entitled are three different surfaces. An unauthenticated probe sees a fraction of what a signed-in agent sees, which means a check per persona rather than one check for everybody.

Not for the browser side. The GenAI semantic conventions cover model identity, token accounting and execute_tool spans, and they are server-side and still under active development. There is currently no agreed way to record that an agent called a named tool on a given site, with these arguments, in this many milliseconds. That gap is the most interesting thing in this whole story.

An in-app assistant is the vendor's agent working inside the vendor's product. WebMCP lets someone bring the agent they already have, with their own context and history, and use it on your site. The tools are declared by the site rather than owned by the vendor, and the session decides which of them the agent can see.

AI made PMs faster. Multiplayer mode is still broken.

A PM can summarize research, draft a PRD, and mock up a prototype before lunch. The hard part starts when the team has to decide what actually gets built.

Jira Product Discovery gives product teams one place to capture insights, prioritize ideas with consistent frameworks, and build living roadmaps stakeholders can rally around.

And because it’s connected to Jira, the context behind every decision stays with the work—so developers and their agents know not just what to build, but why.

AI helps PMs move faster. Jira Product Discovery helps the whole team build with confidence.

Get Started for Free.