If you've been following the agentic-web standards fight, you've seen the headlines: Chrome shipped a WebMCP origin trial in Chrome 149, and WebKit's standards-positions tracker landed on a one-word verdict — ** oppose**.
It's tempting to read that as "Apple says no, so wait." That's the wrong takeaway. The opposition is mostly good engineering feedback, and once you internalize it, it tells you exactly how to build for agents today — in a way that's safe even if the spec stalls.
WebKit's position cites the usual list — API design, duplication of existing platform functionality, i18n, portability, privacy, security, unclear use cases. Boilerplate-sounding, but one of those is the load-bearing critique, and it shows up most sharply in the WebMCP repo itself: ** redundancy with the accessibility tree**.
The argument is clean:
The accessibility tree already exposes a machine-readable action space — labels, roles, states, expected inputs, validation errors, relationships. It's
derived from the DOM, so it can't desync. A separately-maintained JavaScript tool registrycan and willdiverge from the page over time.
This is correct. If you hand-write a parallel description of your UI for agents, you've created a second source of truth, and second sources of truth rot. That's a real smell, and "agent-only APIs that don't help humans" is a legitimate thing to be suspicious of.
Here's the part the opposition under-weights. The a11y tree is excellent at describing state — what's on the page, what each control is, what's required. It's much weaker at describing actions, especially compound ones.
Consider "filter products under €50, in stock, then add the top result to the cart." For a human with a screen reader that's a sequence of discrete control interactions. For an agent, inferring that whole flow from roles and labels is brittle — it has to reverse-engineer your app's intent from primitives. A tool with a typed input schema ({ maxPrice, inStock }
) and a single handler collapses that guesswork into one verified call.
So both things are true at once:
The resolution isn't "pick a side." It's how you implement the tools.
The redundancy objection only bites if your tool definitions are a second implementation. So don't make them one.
The right posture, in order:
add_to_cart
tool should bottom out in one code path.Do this and the "two sources of truth" problem evaporates, because there's still only one. The tool registry isn't a parallel description of the page; it's a typed front door to the handlers the page already runs. They can't desync because they're the same code.
The imperative API is just a typed wrapper over a function you already have:
navigator.modelContext.registerTool({
name: "add_to_cart",
description: "Add a product to the cart by id and quantity",
inputSchema: {
type: "object",
properties: {
productId: { type: "string" },
quantity: { type: "number", default: 1 },
},
required: ["productId"],
},
// same handler your "Add to cart" button calls — no second implementation
async execute({ productId, quantity = 1 }) {
await cart.add(productId, quantity);
return { content: [{ type: "text", text: `Added ${quantity} x ${productId}` }] };
},
});
And feature-detect, because most browsers won't have it yet:
if ("modelContext" in navigator) {
// register tools
}
That if
is the whole risk profile. If WebMCP ships everywhere, you're ready. If WebKit holds the line and it stalls, you've lost nothing — you added a feature-detected enhancement over handlers that already existed for your human users. This is just progressive enhancement.
The agentic-web tooling has already moved past "is this real" — Google's Lighthouse now ships an Agentic Browsing audit category, and scanners will increasingly grade whether your site exposes tools. The standards politics will take a year to settle. Your move in the meantime isn't to bet the company on a spec; it's to keep one source of truth and put a typed, feature-detected front door on the handlers you already ship.
Disclosure: I work on Latch, an open-source (MIT) one-line script that exposes a site's existing search/cart/forms as WebMCP tools — built around exactly this "reuse your existing handlers, feature-detect, lose nothing if the spec stalls" posture. If you'd rather understand the standard than adopt any tool, the WebMCP guide is vendor-neutral. Happy to talk design trade-offs in the comments.