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.

What WebKit actually objected to

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 registry can and will diverge 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.

Why the accessibility tree alone isn't enough either

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:

1. A parallel, hand-maintained agent API is a liability.
2. The a11y tree is lossy for multi-step actions.

The resolution isn't "pick a side." It's how you implement the tools.

The design that survives the critique

The redundancy objection only bites if your tool definitions are a second implementation. So don't make them one.

The right posture, in order:

1. Build for humans first. Semantic HTML, real form elements, a clean accessibility tree. This is non-negotiable and it's what everyone — users, assistive tech, search, and agents — benefits from.
2. Expose the actions, not a new app. Where you register an agent tool, have its handler call the exact same function your UI already calls. Your "Add to cart" button and your add_to_cart tool should bottom out in one code path.
3. Keep tools thin. A tool is a typed entry point to existing behavior, not a place for new business logic. If a tool does something your UI can't, that's the divergence WebKit warned about — fix the UI instead.

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.

Concretely

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.

Where this leaves you

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.