{"slug": "webkit-opposes-webmcp-here-s-what-to-actually-build-today", "title": "WebKit opposes WebMCP. Here's what to actually build today", "summary": "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.", "body_md": "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**.\n\nIt'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.\n\nWebKit'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**.\n\nThe argument is clean:\n\nThe accessibility tree already exposes a machine-readable action space — labels, roles, states, expected inputs, validation errors, relationships. It's\n\nderived from the DOM, so it can't desync. A separately-maintained JavaScript tool registrycan and willdiverge from the page over time.\n\nThis 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.\n\nHere'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.\n\nConsider \"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 }`\n\n) and a single handler collapses that guesswork into one verified call.\n\nSo both things are true at once:\n\nThe resolution isn't \"pick a side.\" It's **how you implement the tools**.\n\nThe redundancy objection only bites if your tool definitions are a *second implementation*. So don't make them one.\n\nThe right posture, in order:\n\n`add_to_cart`\n\ntool 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.\n\nThe imperative API is just a typed wrapper over a function you already have:\n\n```\nnavigator.modelContext.registerTool({\n  name: \"add_to_cart\",\n  description: \"Add a product to the cart by id and quantity\",\n  inputSchema: {\n    type: \"object\",\n    properties: {\n      productId: { type: \"string\" },\n      quantity: { type: \"number\", default: 1 },\n    },\n    required: [\"productId\"],\n  },\n  // same handler your \"Add to cart\" button calls — no second implementation\n  async execute({ productId, quantity = 1 }) {\n    await cart.add(productId, quantity);\n    return { content: [{ type: \"text\", text: `Added ${quantity} x ${productId}` }] };\n  },\n});\n```\n\nAnd feature-detect, because most browsers won't have it yet:\n\n```\nif (\"modelContext\" in navigator) {\n  // register tools\n}\n```\n\nThat `if`\n\nis 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.\n\nThe 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.\n\n*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.*", "url": "https://wpnews.pro/news/webkit-opposes-webmcp-here-s-what-to-actually-build-today", "canonical_source": "https://dev.to/r0bertini/webkit-opposes-webmcp-heres-what-to-actually-build-today-18dn", "published_at": "2026-06-18 01:05:42+00:00", "updated_at": "2026-06-18 01:51:55.127491+00:00", "lang": "en", "topics": ["large-language-models", "ai-agents", "ai-safety", "ai-policy", "developer-tools"], "entities": ["WebKit", "Chrome", "WebMCP", "Google", "Lighthouse", "Apple"], "alternates": {"html": "https://wpnews.pro/news/webkit-opposes-webmcp-here-s-what-to-actually-build-today", "markdown": "https://wpnews.pro/news/webkit-opposes-webmcp-here-s-what-to-actually-build-today.md", "text": "https://wpnews.pro/news/webkit-opposes-webmcp-here-s-what-to-actually-build-today.txt", "jsonld": "https://wpnews.pro/news/webkit-opposes-webmcp-here-s-what-to-actually-build-today.jsonld"}}