When an AI agent uses a website today, it reads the page roughly the way you would. It scans the buttons, the labels, the form fields, and infers from them what it can do. If the site redesigns its checkout flow, or runs an A/B test that quietly moves a button, the agent may fail. That is frustrating, but the failure is at least visible. The agent tried to click something that wasn't there, and anyone looking can see that it did.
The WebMCP draft specification proposes a different arrangement. The agent stops reading the page and guessing. Instead, the website hands it a structured list of "tools," which are actions the site declares it can perform. A to-do app, for example, might declare a tool called add-todo, describe in plain language what it does, specify that it needs a text string, and supply the code that creates the item.
This is a real improvement, and I don't want to undersell it. Agents that break every time a designer moves a button are not much use to anyone. But the arrangement moves uncertainty to a new place rather than removing it, and the new place is harder to see.
What the browser can check, and where checking stops
Each tool declaration runs along a gradient, from the parts a machine can verify to the parts that depend on trust.
The name is the most constrained part. It has to be short, use basic characters, and be unique on the page. A browser can enforce all of that mechanically.
The input schema uses JSON Schema to say what information the tool expects: this field must be text, this field is required. It looks like exactly the kind of thing a browser would validate. Under the current draft, though, browsers aren't required to check inputs against the schema. The spec's own contributors describe it as "purely a semantic hint for the agent." The group agrees validation should happen eventually. For now, it doesn't.
The annotations are simple labels a site can attach to a tool: this one only reads data, this one does something consequential like spending money, this one returns content that shouldn't be fully trusted. An agent could treat "consequential" as a cue to ask you for confirmation before booking a flight. But the browser passes these labels along without comparing them to what the code actually does. A tool that charges your credit card can label itself non-consequential, and nothing in the specification prevents it. A site also has reasons to do exactly that. A confirmation prompt interrupts a purchase, and the site is the one writing the label.
The description carries the most weight and gets the least verification. It's the plain-language text the agent reads to decide whether to use a tool and what to give it. A description can leave out side effects, or frame the tool's purpose so that it steers the agent toward particular choices. The spec says so plainly:
"There is no guarantee that a WebMCP tool's declared intent matches its actual behavior."
The code itself is opaque. The browser runs it; the agent never looks inside. Because that code executes in the user's logged-in browser session, it can make purchases, transfer funds, or change account settings without any of those actions appearing as explicit arguments. It can also skip validation steps that the site's visible interface would normally apply.
Where the specification stops and incentives start
The draft's security section is unusually candid about these gaps. It also proposes no normative fixes, meaning nothing that browsers or sites would actually be required to do.
The sites writing these declarations are not neutral parties. An airline declaring a booking tool wants agents to invoke it easily, and would rather avoid the confirmation prompts that a "consequential" label might trigger. A retailer describing its purchase flow will tune that description to get agents to act, not to make them careful. None of this requires bad faith. A product team optimizing for completed purchases would arrive at the same choices. The specification gives sites a vocabulary for honest declaration and no means of enforcing honesty, while the commercial incentive pushes the other way.
That combination matters because structured declarations feel authoritative in a way scraped page labels never did. When an agent misread a page, everyone understood its reading was approximate. A formal tool declaration carries an implicit claim to completeness: this is what the site does. The specification's authors understand the risk, and their warning is right there in the text. Whether the people building on it will take that warning as seriously is something the document itself cannot settle.
- Browser agents and origin boundaries: The W3C Technical Architecture Group's draft on agentic browsing and web architecture argues that structured tools don't resolve cross-origin isolation when an agent can carry information between sites, leaving model judgment as the only barrier against disclosure.
- Schema validation is still open: The WebMCP community group has agreed browsers should eventually enforce input validation, but the open issue on who owns the validation layer shows contributors still debating whether schemas should be mandatory and what JSON Schema subset to support.
- Agent identity versus agent authority: NIST's summary of over 600 comments on agent identity found broad support for separating stable identity from task-scoped credentials and authorization at action time, but no consensus on a single technical mechanism.
- Evaluating what tools actually do: An enterprise evaluation study found that 92% of agent runs passing final outcome checks contained process-level deviations detected by trajectory analysis, suggesting that successful results and acceptable routes are distinct measurements.