WebKit resolved its WebMCP position as 'oppose' in June 2026. What the objection says, what fragmentation means in practice, and why ship agent tools anyway.
WebKit, the engine behind Safari, has formally opposed WebMCP. A WebKit engineer posted the position on June 3, 2026, and the standards-positions issue was resolved as "position: oppose" on June 11. If you have been weighing a WebMCP integration for your store or booking flow, the obvious question is whether this kills the plan. Short answer: no, and the reasons why are worth understanding precisely, because they tell you which parts of your agent strategy depend on browser politics and which parts never did.
The position lives in WebKit standards-positions issue #670, filed on May 28, 2026 by a WebMCP editor at Google asking WebKit to review the proposal. The resolution carries eight concern labels: API design, duplication, internationalization, portability, privacy, security, unclear use cases, and venue. The written objection is more interesting than the labels, and it is not a reflexive "no AI in the browser." It makes a handful of specific arguments.
The semantic-gap argument. WebKit agrees that browser agents struggle to operate interfaces built for humans. Its position is that when a site's actions are hard for an agent to use, that is a gap in the page's own semantics, and the fix belongs in HTML and ARIA, the platform's shared layers, where the user, assistive technology, and agents all benefit at once. Describing the same actions a second time as JavaScript tools, WebKit argues, just relocates the brittleness: the agent still picks a tool from a natural-language name and description, which the spec itself concedes are ambiguous and unverifiable.
The parity argument. This is the deepest one. WebKit treats an agent acting on a user's behalf as assistive technology, which should operate a site the way the user would. WebMCP makes "an agent is driving" a separately addressable fact, and once a site can address agents directly, nothing keeps the agent-facing and human-facing surfaces in parity. A site could grant agents capabilities it withholds from its human UI, or block agents the way some sites effectively block screen readers. WebKit calls this "the screen-reader-blocking problem, but applied to AI agents."
Security and privacy. The objection flags WebMCP as a new cross-origin invocation path whose interaction with the browser isolation model is unexamined, notes that the consent hook for consequential actions is still a TODO in the spec, and quotes the spec's own warning about a "personalization-to-fingerprinting" pipeline, where over-parameterized tools coax an agent into filling in personal data the user never gave that site.
Scope and venue. WebKit points out that despite the name, the spec does not actually require the Model Context Protocol as the exposure format, making it a general mechanism for registering callable functions, which the platform already has in postMessage and friends. And it argues the W3C Web Machine Learning Community Group is the wrong venue, since the gaps WebMCP addresses live in HTML and accessibility semantics governed elsewhere.
Worth absorbing before reacting: most of this critique is about where the work should happen, not whether sites should be operable by agents. WebKit explicitly wants agent operability. It wants it delivered through the accessibility layer you should be investing in anyway.
If you need the full primer, read our WebMCP explainer; here is the one-paragraph refresher. WebMCP is a draft API, edited by Google and Microsoft engineers, that lets a page register typed tools (search, add-to-cart, book-appointment) through navigator.modelContext. The proposal targets two callers: native browser agents like a Gemini sidebar in Chrome or Copilot in Edge, and in-page JavaScript agents, including ones running in cross-origin iframes. Chromium exposes the API behind a flag or origin trial today. Nothing ships it default-on, and Chrome's auto-browse feature drives the page visually rather than calling WebMCP tools.
That last detail reframes the whole fragmentation question.
Here is the trap in the headline: "Safari won't support WebMCP" sounds like losing a fifth of your audience. But browser-engine support was never the thing driving WebMCP invocations, even in Chromium. The agents calling registered tools in mid-2026 are an opt-in set: Perplexity Comet, browser extensions that ship their own in-page agent, and custom buying agents built on LLM SDKs. Those are software your visitors (or their employers) chose to run. None of them arrive via Safari's rendering engine, and none of them disappear because WebKit said no.
Meanwhile the highest-volume agent of the moment, Chrome auto-browse rolling out across Android, doesn't invoke WebMCP either. It operates your real DOM the way a person does. So the practical agent landscape splits cleanly: a large population of bots and visual agents that need a clean, accessible page, and a small but growing population of tool-calling agents that need registered tools. WebKit's opposition changes neither population this year.
There is also a sense in which WebKit's position validates half your roadmap. Its prescribed fix, richer HTML and ARIA semantics, is exactly the work that makes auto-browse, screen readers, and every future Safari agent able to drive your checkout. If you were already treating accessibility as your foundation and tools as a layer on top, the oppose label confirms the ordering rather than upending it.
The honest cost of fragmentation is longer-term: without WebKit, WebMCP will not become a universal, every-engine web standard on any near timeline. If your plan assumed "wait for universal support, then integrate," that plan just got pushed out indefinitely. The plan that still works is the one that never depended on universality.
The implementation pattern that survives standards uncertainty has three properties.
It feature-detects. A snippet that checks for navigator.modelContext before registering registers tools where the API exists and silently does nothing where it doesn't. Safari users get your normal page. Comet users get your tools. No code path breaks in either case, which means WebKit's decision costs you nothing to hedge against.
It centralizes the moving parts. The spec is a draft with open pull requests and unresolved questions; WebKit's objection may push changes to consent handling, exposedTo, or even the venue. If you hand-rolled raw API calls, every spec change is your maintenance problem. A hosted snippet absorbs those changes upstream. This is the approach our Shopify WebMCP install guide walks through: one tag, platform APIs wired automatically, updates handled for you.
It keeps the DOM as the floor. Tools are an efficiency layer for agents that can call them. The accessibility layer is what every other agent uses, and it is the layer WebKit itself endorses. Fix unlabeled inputs, div-buttons, and JavaScript-only flows first; register tools second. WebKit's parity warning is also worth taking seriously as a design constraint: keep your tools and your human UI offering the same capabilities, both because it is the right call for users and because it future-proofs you against whatever consent and parity requirements a revised spec adopts. The security questions WebKit raised are real design inputs too, and we cover how to scope tools defensively in our WebMCP security guide.
Run the same order we recommend everywhere: detect which agents already hit your site, serve them an operable page, then sell through tools. The standards fight only touches step three, and only the protocol half of it.
Written by Crawlytics Team. Crawlytics tracks AI bots, generates llms.txt, and powers WebMCP commerce, all from one snippet on any stack. See how it works →
There is no indication Safari will support WebMCP in its current form, and no WebKit implementation exists or is planned. That said, an oppose position targets this design, not the goal: WebKit's objection explicitly favors solving agent operability through HTML and ARIA. If the proposal were substantially redesigned around those concerns (consent, cross-origin isolation, agent-versus-human parity) or reborn in a different venue, WebKit could take a fresh position. Plan as if Safari support is years away or never, and let a feature-detecting snippet make that assumption free to hold.
No. Google and Microsoft engineers edit the spec and continue developing it in the W3C Web Machine Learning Community Group, and Chromium ships the API behind a flag. The web has a long history of capabilities that shipped in Chromium-based browsers for years despite WebKit opposition, Web Bluetooth and WebUSB among them. What the opposition does kill is the near-term prospect of WebMCP as a universal cross-engine standard. For site owners the distinction barely matters: the agents that invoke WebMCP today are opt-in agent browsers, extensions, and custom agents, and that population keeps growing or shrinking on its own merits, not on Safari's roadmap.
It degrades safely rather than working: on a browser without navigator.modelContext, the registration call no-ops and your page renders exactly as before, so there is no error state and no downside. The tools simply are not invocable in that browser. Where the visiting agent does support tool invocation (Comet, agent extensions, custom agents on Chromium builds with the API enabled), the same snippet makes your search, cart, or booking actions callable. That asymmetry, zero cost where unsupported and real capability where supported, is what makes shipping now rational despite the standards fight.
This page is part of Crawlytics.app. View all pages: llms.txt · llms-full.txt