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

> Source: <https://dev.to/r0bertini/webkit-opposes-webmcp-heres-what-to-actually-build-today-18dn>
> Published: 2026-06-18 01:05:42+00:00

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.*