WebKit opposes WebMCP. Here's what to actually build today

WebKit has formally opposed the WebMCP standard, citing redundancy with the accessibility tree as a key concern. A developer argues that the opposition is constructive engineering feedback and that the right approach is to implement tools as typed wrappers over existing handlers, avoiding a second source of truth. This progressive enhancement strategy works regardless of whether WebMCP ships everywhere or stalls.

If you've been following the agentic-web standards fight, you've seen the headlines: Chrome shipped a WebMCP origin trial in Chrome 149 https://developer.chrome.com/blog/ai-webmcp-origin-trial , 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 https://www.debugbear.com/blog/lighthouse-agentic-browsing , 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.