DEV Community: Robert

Google just shipped an official "agent-ready" toolkit. Here's the one thing it can't measure.

Robert — Mon, 29 Jun 2026 01:07:27 +0000

For most of 2026, "is my website agent-ready?" was a question you answered with vibes and a blog post. As of last week, Chrome answers it with a toolkit.

On June 22, the Chrome team shipped the Agent-Ready Toolkit — a first-party set of tools for checking and fixing how your site behaves when an AI agent, not a human, is driving. It bundles:

a new Agentic browsing category in Lighthouse (available starting from M150, currently "informational and unbenchmarked"),
Chrome DevTools for Agents,
Modern Web Guidance (including a webmcp skill), and
WebMCP itself as the mechanism for exposing your site's actions to agents.

The quiet significance isn't any single tool. It's that "agent-ready" just stopped being a think-piece and became a measured, first-party concern that ships in the same browser as most of your traffic. When the platform vendor builds the ruler, the thing being measured becomes a real engineering line item.

If you've read my earlier walkthrough of the Lighthouse Agentic Browsing checks, the remediation advice still holds. I don't want to re-run it here. I want to talk about the one thing this toolkit — by design — cannot tell you.

What the toolkit measures

The WebMCP portion of the audit, per the blog, "checks for the availability of registered WebMCP tools, forms missing declarative WebMCP, and schema validity." In plain terms it asks three questions:

Did your page register any tools via navigator.modelContext (or declarative form annotations)?
Are there forms that should be exposed as tools but aren't?
Are the input/output schemas valid?

That's a genuinely useful static check. It tells you whether you've done the work of exposing your site's logic. Pass it and an agent that shows up has a clean, structured way to call your search, your cart, your booking form — instead of screenshotting the page and guessing where to click.

The thing it can't measure

Here's the gap. Every check in that toolkit is about exposure: have you offered the tools? None of them — and none of them can, because they run at audit time in your own browser — tell you whether a real agent, in production, ever called one.

Exposure and invocation are two different facts:

Exposure is a property of your code. Static. Auditable. Pass/fail. The toolkit nails it.
Invocation is a property of the world. It's "on Tuesday at 14:03, something calling itself Gemini-in-Chrome invoked searchProducts({query:'waterproof'}) and got 8 results back." No static audit can know that, because it hasn't happened yet when the audit runs.

For most of this year the honest knock on WebMCP was "no mainstream agent calls navigator.modelContext anyway." That's changing — Google has named the first consumer: "Gemini in Chrome will soon support WebMCP APIs." Which means the interesting question is shifting from "did I expose tools?" (the toolkit now answers this for you) to "is anything actually using them, and what is it trying to do?"

That second question is where the value is. The first agent call to your site is a signal: it tells you which intent agents reach for first, whether your schema matched what they expected, and whether the call succeeded or threw. If you can't see it, you find out months later in an aggregate analytics wobble — long after you could have fixed the schema that made every agent call fail.

How to close the gap (honestly)

You don't need anything fancy. The move is to instrument every tool call the day you register the tool, so the first real invocation isn't invisible:

function instrument(name, handler) {
  return async (args) => {
    const t0 = performance.now();
    try {
      const result = await handler(args);
      report({ tool: name, ok: true, ms: performance.now() - t0 });
      return result;
    } catch (err) {
      report({ tool: name, ok: false, ms: performance.now() - t0, error: String(err) });
      throw err;
    }
  };
}

// register the *wrapped* handler with navigator.modelContext
navigator.modelContext?.registerTool({
  name: "searchProducts",
  // ...inputSchema...
  execute: instrument("searchProducts", searchProducts),
});

report() can be a fetch to your own endpoint, a log line, whatever. The point is: pass the Lighthouse audit to prove you exposed the tools, and add invocation logging to learn whether agents use them — because the toolkit only does the first half.

Disclosure

I work on Latch, a one-line script that does both halves: it exposes your existing search/cart/forms as WebMCP tools (so you pass the new audit), and its hosted tier records which agents call which tools and whether the calls succeed — the invocation layer a static audit can't see. The free, MIT client is on GitHub; you can wire up the same logging by hand with the snippet above if you'd rather.

Either way, the takeaway stands on its own: Chrome now grades you on whether you offer tools to agents. Whether agents actually take them is a separate fact — and right now, almost nobody is watching it. The day Gemini-in-Chrome makes its first call to your site is worth seeing happen. Make sure you can.

Gemini in Chrome is about to call WebMCP. The "no agent uses it yet" excuse just got an expiry date.

Robert — Fri, 26 Jun 2026 01:05:22 +0000

For most of 2026 the honest objection to WebMCP went like this: "Cool API. But no mainstream agent actually calls navigator.modelContext, so why ship it?"

I've made that argument myself in writing — it was true, and it was the right question to ask before spending a sprint on it.

Google just changed the answer. In its Google I/O 2026 round-up, the Chrome team wrote, plainly:

"Gemini in Chrome will soon support WebMCP APIs."

And as one developer who shipped WebMCP on their own site put it: "The sole agent consuming those tools today is Gemini in Chrome." So the picture for mid-2026 is: one named, mainstream, hundreds-of-millions-of-installs agent is the first real consumer — and it's coming from inside the browser most of your users already run.

That doesn't make WebMCP "done." But it does turn the objection from "no agent will ever call this" into "there's now a named agent and a soon." That's a very different bet.

What actually changed

Nothing about the spec. WebMCP is still an origin trial (Chrome 149–156), still experimental, still opposed by WebKit, still un-called by most agents today. If you were waiting for the standard to "settle," it hasn't.

What changed is the shape of the risk. Before: you instrument your site for an audience of zero, indefinitely. Now: you instrument it for a consumer that Google has publicly committed to shipping, riding in the default browser on most of your traffic. The expected value of being ready moved.

Why being early is cheap (and why late is expensive)

Here's the asymmetry that makes this an easy call once the consumer is named:

The cost to expose a tool is tiny. WebMCP tools are thin wrappers over handlers you already have — your site search, your cart, your booking form. You're not building new functionality; you're describing existing functionality in a way an agent can call.
The cost of feature-detecting is zero. If navigator.modelContext isn't present, your code does nothing. No agent in the browser, no behavior change, no risk.
The cost of being late is real. When Gemini in Chrome starts driving task completion on agent-ready sites, the sites that already exposed their search/checkout/booking flows are the ones that get completed instead of abandoned. You don't want to discover that gap from a competitor's conversion numbers.

The whole interaction replaces dozens of screenshot-capture-interpret-click cycles with one structured tool call. That's the entire pitch: reliability and speed for the agent, and for you, a flow that an agent can finish instead of fumble.

What to ship today (the honest version)

Don't rebuild anything. Wrap what you have, feature-detect, and lose nothing if the spec stalls:

if (navigator.modelContext) {
  navigator.modelContext.registerTool({
    name: "search_products",
    description: "Search the catalog and return matching products.",
    inputSchema: {
      type: "object",
      properties: { query: { type: "string" } },
      required: ["query"],
    },
    async execute({ query }) {
      // call the SAME search you already expose to humans
      const results = await fetch(`/api/search?q=${encodeURIComponent(query)}`)
        .then((r) => r.json());
      return { content: [{ type: "text", text: JSON.stringify(results) }] };
    },
  });
}

Pick the two or three actions that are your business — search, add-to-cart, "book a call," "get a quote," "check availability" — and expose those first. One source of truth: the tool calls the same handler your buttons do.

The part nobody tells you to do: instrument it

Here's the move that turns "soon" into something you can actually manage. Once your tools are registered, log every agent call: which tool, what arguments, did it succeed. Because the day Gemini in Chrome (or any agent) first invokes one of your tools, you want to see it — not infer it three months later from a weird analytics blip.

That signal is genuinely useful:

It tells you which of your flows agents reach for first (so you instrument the next ones).
It tells you where tool calls fail (bad schema, ambiguous descriptions, missing params) — agent UX debugging you can't do blind.
It's the earliest possible read on agent-driven traffic to your site, before it's big enough to show up anywhere else.

You can wire this yourself with a few fetch beacons. Full disclosure: I work on Latch — a one-line open-source script that exposes your existing search/cart/forms as WebMCP tools, and whose paid tier records exactly this (which agent called what, and whether it worked). I'm biased, so take the plug with salt — but instrument it somehow, with us or with a logging endpoint of your own. The teams that can answer "when did the first agent call our site, and what did it try?" are going to make much better decisions in the next six months than the ones guessing.

The honest caveats, kept honest

It's "will soon," not "today." Don't promise your PM agent traffic next week.
It's an origin trial. APIs can change; register for the trial rather than assuming stability.
WebKit still formally opposes WebMCP. Multi-engine ubiquity is not guaranteed. That's exactly why feature-detection (lose nothing if it stalls) is the right posture.

But the core thing has changed, and it's worth saying clearly: the strongest reason to not ship WebMCP — "no agent will ever call it" — now has a name attached to its expiry. The cheap, reversible, feature-detected version costs you an afternoon. I'd take that bet.

Building agent-ready sites? The vendor-neutral writeup is at latch.tools/webmcp, and the open-source client is on GitHub (MIT).

Shopify's UCP makes your catalog agent-buyable. The rest of your storefront still isn't — here's where WebMCP fits.

Robert — Mon, 22 Jun 2026 01:05:29 +0000

If you run a store, the agentic-commerce wave probably arrived in your inbox this spring as a Shopify changelog, not a strategy memo. Shopify's Spring '26 release shipped Agentic Storefronts and, with Google, the Universal Commerce Protocol (UCP) — an open standard (backed by Amazon, Meta, Microsoft, Salesforce, Stripe, Etsy, Target, Wayfair) that lets an AI agent discover products, build a cart, and complete checkout on a shopper's behalf. If you're on Hydrogen, every storefront now exposes an MCP endpoint at /api/mcp with proxyStandardRoutes on by default. The old Storefront Catalog MCP folded into UCP, with the legacy endpoints maintained only through June 15.

That's a genuinely big deal, and if you sell on Shopify you should make sure your catalog is flowing through it. But it's worth being precise about what UCP actually makes agent-operable, because the headline ("your store is now an AI agent endpoint") quietly oversells it.

What UCP covers — and where it stops

UCP standardizes commerce primitives: search the catalog, build a cart, create a checkout, hand off the buyer, track the order, settle payment (via AP2). Those are the operations every store shares, so it makes sense to standardize them once and let every agent speak them.

The flip side of "standardized" is "only the standardized parts." UCP makes the commodity surface of your store agent-operable — the parts that look the same on every Shopify store. It does not cover the parts that make your storefront yours:

a bundle builder or product configurator ("build your own 6-pack", "spec this bike")
a gift-finder or fit quiz that narrows the catalog by answering questions
"book a fitting / a consultation / a demo" scheduling
subscription management, reorder, or a B2B quote / net-terms request
store locator, warranty registration, returns initiation, loyalty redemption
account self-service that isn't a checkout

None of those are "search the catalog and check out." They're bespoke interactive flows you built on top of (or beside) the catalog — and they're frequently the reason a customer chose you over a generic listing. An agent driving your store through UCP can buy a SKU it already knows it wants. It cannot reliably run the quiz that helps it figure out which SKU, or start the warranty claim, or request the B2B quote — because UCP doesn't describe those, and nothing else tells the agent they exist.

And that's the Shopify-on-Hydrogen case, where you inherit /api/mcp for free. Two large groups don't:

Custom / non-Hydrogen headless storefronts. "Truly headless on your own front end" means you don't get the standard routes for free — you're rebuilding the agent surface yourself.
Everyone not on Shopify. Most of the web sells, books, or onboards without Shopify's data graph underneath it at all.

For all three — the custom flows on a Shopify store, headless front ends, and non-Shopify sites — the question isn't "is my catalog in UCP." It's "can an agent operate the interactive parts of my site the same way a person can?"

That's the WebMCP-shaped gap

WebMCP (the navigator.modelContext API, in a Chrome 149 origin trial as of June 2026) is the complement, not the competitor, to UCP. Where UCP standardizes commerce operations across stores, WebMCP lets a single site declare its own tools — whatever they are — so an agent in the browser can call them directly instead of guessing at your DOM.

The mental model that's held up for me:

UCP is the shared commerce rails. WebMCP is the tool surface for everything your storefront does that isn't a generic commerce primitive.

They compose cleanly. The agent uses UCP to buy the thing; it uses your WebMCP tools to do the bespoke work that decides what to buy and what happens around the purchase. A configurator becomes a configure_bundle tool. The fit quiz becomes recommend_size. The B2B flow becomes request_quote. Each is a thin, typed front door to a function your UI already calls:

if ("modelContext" in navigator) {
  navigator.modelContext.registerTool({
    name: "recommend_size",
    description: "Recommend a size from height, weight, and fit preference",
    inputSchema: {
      type: "object",
      properties: {
        heightCm: { type: "number" },
        weightKg: { type: "number" },
        fit: { type: "string", enum: ["slim", "regular", "relaxed"] },
      },
      required: ["heightCm", "weightKg"],
    },
    async execute(args) {
      const size = await sizeEngine(args); // the same fn your quiz UI calls
      return { content: [{ type: "text", text: `Recommended size: ${size}` }] };
    },
  });
}

Two things make this cheap and safe, and they're the same two that make UCP adoption sane:

Feature-detected. The whole surface sits behind if ("modelContext" in navigator). In every browser without the API — which today is nearly all of them — it's a no-op. Nothing breaks.
Reuse, don't rebuild. A WebMCP tool should call the exact function your existing UI calls (sizeEngine, productSearch, startReturn). If you're writing new business logic for the agent, you've taken on the expensive version that drifts out of sync. Don't.

The honest caveat (same as for UCP)

As of June 2026, no mainstream agent calls navigator.modelContext on your page yet — not ChatGPT Agent, not Claude, not Gemini. (UCP is further along on the commerce side, because the agent and the protocol are being built by the same companies, but the general browser tool-call path isn't wired up in shipping agents either.) So this isn't "do it today or lose sales tomorrow." It's: the agentic-commerce buildout is clearly happening top-down from the platforms, the cost of exposing your custom flows as feature-detected tools is an afternoon, and the payoff lands exactly when you can't predict the date.

The one thing I'd add: instrument it. Log every tool invocation — which tool, sanitized args, success, latency — from day one. Whether an agent arrives via UCP checkout or a direct WebMCP call, you want to find out from a dashboard, not from a billing anomaly six months later. "Are agents operating my store yet, and which flows do they use?" is the only question that turns this from a guess into a managed bet.

Bottom line

If you sell on Shopify, get your catalog into UCP — that's the commerce rails, and they're real now. But don't mistake "my catalog is agent-buyable" for "my store is agent-operable." The flows that differentiate your storefront — the configurators, quizzes, bookings, B2B, post-purchase — live outside UCP's standardized primitives, and on custom/non-Shopify sites so does everything else. That's the WebMCP-shaped half of the problem. Expose those flows as typed tools, reuse your own handlers so they can't drift, and meter them so you see the first agent that walks in.

Disclosure: I work on Latch, an open-source (MIT) one-line script that does the WebMCP half of the above — it exposes your site's existing search, cart, forms, and custom flows as feature-detected navigator.modelContext tools (valid schemas, reusing your own handlers), and the optional hosted tier is the meter: it shows which agents call your tools and what they do. If you just want the standard, the WebMCP guide is vendor-neutral and the code is on GitHub. It complements UCP rather than replacing it — happy to compare notes in the comments, especially with anyone running a headless or non-Shopify storefront.

No agent calls WebMCP yet. Here's the honest case for shipping it today — and how to know the day that changes.

Robert — Sat, 20 Jun 2026 01:05:39 +0000

There's an uncomfortable fact under all the WebMCP excitement, and the skeptics are right to keep raising it:

As of June 2026, none of the mainstream AI agents actually call navigator.modelContext on your site. Not ChatGPT Agent, not Claude, not Gemini, not Perplexity. They all still read your page by DOM-scraping or by taking screenshots and clicking pixels. Patrick Brosset's updates and studiomeyer's "Reality Check" both lay this out plainly, and it's worth repeating because the hype usually skips it: WebMCP is a W3C Community Group draft, not a standard, shipping behind a flag in Chrome and a Chrome 149 origin trial — and the agents that would consume it haven't wired it up.

So why would you add WebMCP tools to your site right now?

I think there's an honest answer, and it isn't "because it's the future, trust me." Let me make the actual case — including the part most "install it now" posts skip, which is what to do so the install doesn't quietly rot.

The cost side is genuinely near-zero

The reason "wait and see" feels safe is an assumption that adopting early is expensive. For WebMCP specifically, it mostly isn't — if you do it right:

It's feature-detected, so it can't break anything. The entire surface lives behind if ("modelContext" in navigator). In every browser that doesn't ship the API — which today is almost all of them — your code is a no-op. Zero runtime cost, zero risk to existing users.
It shouldn't add a second codebase. A WebMCP tool should be a thin, typed front door to a function your UI already calls. Your search_products tool calls the same productSearch() your search box calls. If you find yourself writing new business logic to satisfy an agent, stop — that's the expensive version, and it's the version that drifts out of sync.
There's no migration to undo. Because it's additive and detected, "we were too early" has no cleanup cost. You delete a script tag.

Done this way, the real cost of shipping WebMCP today is an afternoon, not a bet-the-roadmap commitment.

The benefit side is a dated option, not a promise

What you're actually buying with that afternoon is an option that's worth the most precisely when it's least certain.

When agents do start calling typed tools — and the people building both the browsers (Google, Microsoft) and the agents are the same companies pushing this spec — the sites that already expose tools win the first wave of agent traffic with no scramble. The gap you're closing isn't "agent can read my page" (DOM scraping already half-works); it's "agent can complete the thing I sell on my page reliably, in one call instead of ten guessed clicks."

You don't have to believe that's six months away or eighteen. The point of an option is that you don't need to know the date. You need the cost of holding it to be low (it is) and the payoff if it hits to be high (for anything transactional, it is).

The part the "install now" posts skip: you won't notice when it starts mattering

Here's the failure mode of "ship it and forget it." You add the tools, they sit behind a feature flag in browsers nobody's agent uses yet, and then... nothing tells you when that changes. Six months later an agent does start calling search_products — and you find out from a billing anomaly, or a support ticket, or never.

If WebMCP is an option, you want to know the moment it goes in the money. That means instrumenting your tools from day one. At minimum, log every invocation yourself:

if ("modelContext" in navigator) {
  navigator.modelContext.registerTool({
    name: "search_products",
    description: "Search the product catalog",
    inputSchema: {
      type: "object",
      properties: { query: { type: "string" }, maxPrice: { type: "number" } },
      required: ["query"],
    },
    async execute(args) {
      // 👇 the line most implementations forget
      beacon("webmcp_tool_call", { tool: "search_products", args, ts: Date.now() });
      const results = await productSearch(args); // same fn your UI calls
      return { content: [{ type: "text", text: formatResults(results) }] };
    },
  });
}

That beacon() is the difference between "we have WebMCP somewhere" and "an agent called our search tool 240 times last Tuesday and 12 of those turned into carts." The second sentence is the one that gets WebMCP a line in next quarter's budget. The first one gets it quietly deleted in a cleanup PR.

Things worth capturing per call: which tool, the arguments (sanitize PII), whether execute succeeded, latency, and any user-agent / client hints you can get. You're building the dashboard that answers "are agents here yet, and what do they do when they arrive?" — which is the only honest way to manage an option instead of a guess.

Bottom line

The skeptics and the boosters are both right, and they're not actually in conflict:

Skeptics: no agent calls WebMCP today. True. Don't let anyone tell you the robots are already shopping your store. They aren't yet.
Boosters: ship it anyway. Also true — because it's cheap, feature-detected, and additive, and because the payoff lands exactly when you can't predict the date.

The synthesis is: ship it early, reuse your own handlers so it can't drift, and instrument it so you see the first real agent call the day it happens — not a quarter later. Adopt the option and the meter, or you've adopted neither.

Disclosure: I work on Latch, an open-source (MIT) one-line script that does the boring half of the above for you — it exposes your site's existing search/cart/forms as WebMCP tools (feature-detected, reusing your own handlers, valid schemas), and the optional hosted tier is exactly the "meter": it shows which agents call your tools and what they do, so you see the first agent visit instead of finding out from a billing anomaly. If you'd rather just understand the standard, the WebMCP guide is vendor-neutral, and the code is on GitHub. Happy to argue the trade-offs in the comments.

Your site just failed Lighthouse's new Agentic Browsing audit — here's how to fix each check

Robert — Fri, 19 Jun 2026 01:04:45 +0000

If you've opened Chrome DevTools lately and run Lighthouse, you may have noticed a new category sitting under Performance, Accessibility, SEO and the rest: Agentic Browsing.

It shipped in Lighthouse 13.3 (May 2026). It's still marked experimental, so it doesn't give you a 0–100 score — just a pass/fail per check. But "experimental" in Lighthouse has a way of becoming "default, and now your client is asking why it's red." So it's worth understanding now, while it's cheap.

The category answers one question: can an AI agent actually understand and operate this page? It does that with four checks. Here's what each one tests and exactly how to make it pass.

1. llms.txt

What it checks: whether your domain root serves an /llms.txt, and — this is the part people miss — whether that file is actually useful: it flags the file if it's missing an H1, is too short, or contains no links.

How to pass: add a plain-text (well, Markdown) file at https://yourdomain.com/llms.txt. Minimum viable version:

# Acme Tools

> Acme sells precision hand tools. This file helps AI agents find the right pages.

## Core pages
- [Product catalog](https://acme.example/products): browse and filter all tools
- [Search](https://acme.example/search): full-text product search
- [Support](https://acme.example/support): returns, warranty, contact

One H1, a one-line summary, real links to the pages that matter. That's the whole check. Don't dump your sitemap into it — curate the handful of entry points an agent should know about.

2. Accessibility tree

What it checks: every interactive element has a programmatic name, roles and parent/child relationships are valid, and nothing is hidden from the a11y tree while still being interactive.

How to pass: this is just accessibility hygiene, and it's the most important check of the four — because the accessibility tree is the primary way an agent reads your page. Use real <button>, <a>, <label>/<input> pairs instead of click-handlered <div>s. Give icon-only buttons an aria-label. Make sure a <div role="button"> you couldn't avoid is focusable and named.

If you've been putting off your a11y backlog, the agentic era just gave you a second, harder-to-ignore reason to do it: the same fixes that help screen-reader users help every agent that visits.

3. Cumulative Layout Shift (CLS)

What it checks: the same CLS you already know from Core Web Vitals.

How to pass: nothing agent-specific here — reserve space for images and embeds (width/height or aspect-ratio), avoid injecting content above existing content, preload fonts. Why does an agentic category care about visual stability? Because agents that drive a real browser click coordinates and read snapshots; a page that reflows under them mis-clicks exactly like a human would. Stable layout = reliable automation.

4. WebMCP

This is the new one, and the only check that's genuinely about the agentic web rather than hygiene you should already be doing.

What it checks: Lighthouse surfaces every WebMCP tool registered on the page — whether via the declarative HTML API or imperatively through navigator.modelContext.registerTool() — and validates that any declared inputSchema is syntactically and semantically valid. For annotated forms, it checks that the annotations match the expected schema.

How to pass: you need to actually expose tools, and their schemas have to be valid. The imperative version:

if ("modelContext" in navigator) {
  navigator.modelContext.registerTool({
    name: "search_products",
    description: "Search the product catalog",
    inputSchema: {
      type: "object",
      properties: {
        query: { type: "string" },
        maxPrice: { type: "number" },
      },
      required: ["query"],
    },
    // call the SAME function your search box already calls
    async execute({ query, maxPrice }) {
      const results = await productSearch({ query, maxPrice });
      return { content: [{ type: "text", text: formatResults(results) }] };
    },
  });
}

Two things worth saying out loud, because they're where teams get this wrong:

Feature-detect. Most browsers don't ship navigator.modelContext yet (it's in a Chrome 149 origin trial; WebKit has formally opposed it). The if ("modelContext" in navigator) guard means you lose nothing if the spec stalls — it's progressive enhancement.
Reuse your existing handlers. Your search_products tool should bottom out in the exact function your search UI already calls. If a tool does something your UI can't, you've created a second source of truth that will drift — which is precisely the redundancy critique WebKit raised. Keep tools as thin, typed front doors to behavior you already ship.

The honest prioritization

Three of these four checks — llms.txt, accessibility, CLS — are things you should be doing regardless of whether you believe in the agentic web. Do them first; they pay off for users and search today.

The fourth, WebMCP, is the real bet on where browsing is going. It's also the one with the most leverage if you sell anything: the gap between "an agent can read my page" and "an agent can complete a purchase on my page" is exactly the gap WebMCP tools fill.

Disclosure: I work on Latch, an open-source (MIT) one-line script that does the WebMCP check (#4) for you — it exposes your site's existing search/cart/forms as WebMCP tools with valid schemas, feature-detected, reusing your own handlers. If you'd rather understand the standard than adopt any tool, the WebMCP guide is vendor-neutral. Happy to talk trade-offs in the comments.

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

Robert — Thu, 18 Jun 2026 01:05:42 +0000

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:

A parallel, hand-maintained agent API is a liability.
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:

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

Make any website agent-ready in one line (WebMCP, navigator.modelContext)

Robert — Wed, 17 Jun 2026 01:04:56 +0000

In mid-2026 a quiet fact about the "agentic web" still holds: none of the big agents call navigator.modelContext tools directly in production yet. ChatGPT Agent, Gemini, Perplexity, Claude — they still mostly DOM-scrape or take screenshots and guess where to click. That's slow, brittle, and burns tokens.

WebMCP fixes the mechanism. Your site declares tools — searchProducts, addToCart, submitLead — each with a name, a JSON schema, and an execute callback. An agent makes one structured call and gets JSON back, instead of clicking through your filter dropdowns. Chrome shipped the early preview in 146 (Feb 2026); Edge 147 ships it natively; Chrome 149 is now in an open origin trial (announced at Google I/O, May 2026), with DevTools support for inspecting registered tools. Benchmarks from Chrome Labs show large token reductions vs. screenshot automation.

The catch: wiring navigator.modelContext.registerTool() for every search box, cart action, and form on a real site — with auth, schemas, and a polyfill so it works in browsers that don't have it yet — is real work.

The one-line version

Latch is an open-source (MIT) script that does the wiring for you:

<script src="https://latch.tools/latch.js" data-key="YOUR_KEY"></script>

It introspects your search, cart, and forms and registers them as WebMCP tools, with a polyfill so today's agent browsers and extensions can call them now. You keep your existing UI; agents get a structured contract.

Why bother before agents "officially" support it

Two reasons. First, agent browsers and extensions that do read navigator.modelContext already exist, and the standard is landing in stable Chrome/Edge fast — being early is cheap insurance. Second, you can't improve what you can't see: when an agent does hit your site, you want to know which one, and what it tried to do. Latch's optional hosted analytics (Latch Pro, EUR 19/mo per project) shows per-agent breakdowns and a full event feed; the OSS client is free.

Try it

Guide: https://latch.tools/webmcp
Source: https://github.com/r0bertini/latch
Check your own site's agent-readiness, add a couple of tools, and watch what the agents do.

The web spent 30 years optimizing for human clicks and search crawlers. The next layer is tools for agents — and it's a one-liner to get on it.

Disclosure: I work on Latch. WebMCP itself is an open W3C Community Group standard — you can implement navigator.modelContext by hand without any library; Latch just automates the wiring.