Latch

7 Aug

Cloudflare shipped a WebMCP developer preview at the edge: one dashboard toggle injects a bridge script into your pages, no code, nothing changed at your origin. When a company that sits in front of a huge slice of the web productizes a standard, the standard is real. One caveat 👇

7 Aug

The preview ships two tool packs: content-credentials (C2PA provenance) and a proxy to an MCP server you already run. Neither one knows your site has a product search, an add-to-cart, a booking flow. Turning your actual actions into callable tools is still yours — and that's the valuable half.

7 Aug

It says nothing about which agents called what, or whether a call returned usable data — exposure isn't invocation. My honest take on what the switch does and doesn't (biased, I build here): https://dev.to/r0bertini/cloudflare-just-put-webmcp-at-the-edge-what-it-does-and-whats-still-on-you-2pgm

6 Aug

9th Circuit just vacated Amazon's injunction against Perplexity's Comet browser — ruling the *user* accesses Amazon, not the agent vendor. The legal cloud over agentic browsing lifts a little. Worth noting what the fight was actually about: an agent acting through your logged-in session. 🧵

6 Aug

That's the scrape-the-user model — the agent drives the human's browser, the site never opted in, access contested enough to litigate. WebMCP is the opposite: the site declares first-party tools an agent may call. Sanctioned by design — the owner sets what's exposed, not a court after.

6 Aug

And it settles "can agents access," not "can they do it reliably." A DOM-scraping agent is brittle and invisible to you; declared tools give a clean contract and let you see what agents do. Access was the legal question — observability is the engineering one. (Biased: I build a WebMCP layer.)

29 July

Sharp piece from Andrea Volpini (WordLift): if Schema.org gave the web standardized *nouns*, WebMCP gives *verbs* — actions agents call, not markup they read. “The new Schema.org moment.” True, and it imports Schema.org’s hardest lesson 👇 wordlift.io/blog/en/webmcp-is-the-new-schema-org

19 July

Nice writeup from WorkOS (Garen Torikian) on wrapping their docs in WebMCP — search_content, list_sections, go_to, get_page_info, registered at runtime via document.modelContext. One detail worth pulling forward 👇 https://workos.com/blog/webmcp-workos-docs

19 July

They cap tool output at 4000 chars — and that cap *is* a return-contract choice. For docs, search_content's payoff isn't that it ran; it's whether results come back ranked + chainable or a blob the agent re-parses. You only tune that by watching what agents call + get back. (I build here, biased.)

17 July

Nice, clear walkthrough from Dave Bitter of Lighthouse's new Agentic Browsing audit — llms.txt, a11y tree, CLS, and WebMCP. Worth a read if you're asking "is my site agent-ready?" One thing I'd add on the WebMCP check 👇 davebitter.com

17 July

It grades whether you *expose* tools (document.modelContext, valid schema). A static snapshot can't see what decides payoff: does the tool work when an agent calls it? Structured returns it can chain on, clean partial failures. Exposure isn't invocation. (I build a WebMCP layer, so biased.)

16 July

Fresh arXiv framework for 'agent-ready' e-commerce (Elnaffar & Rashidi, Jul 13): three dimensions — interpretability, executability, decision reliability. Sharp. But 'executability' stays descriptive — machine readability, semantic clarity, actionability *signals*. arxiv.org/abs/2607.12056

16 July

An agent doesn't execute a signal — it calls something. The concrete primitive for that dimension is a callable tool (document.modelContext.registerTool), not richer markup. And 'decision reliability' only holds if you can see which agent called which tool + what came back. (I build here, biased.)

Google quietly shipped something bigger than another explainer: an official Agent-Ready Toolkit (June 22). "Is my website agent-ready?" just went from a vibes question to a measured, first-party check that ships in the same browser as most of your traffic. 🧵

The thing a static audit can't tell you: whether a real agent ever CALLED one. Exposure is a property of your code. Invocation is a property of the world — "Gemini-in-Chrome called searchProducts() at 14:03, and it threw." No audit running in your own browser knows that yet.

So pass the audit to prove you exposed tools — then instrument every call so the first real agent visit isn't invisible. I wrote up the gap + a tiny logging snippet (disclosure: I build Latch, a one-line WebMCP layer): dev.to writeup

What it grades (Lighthouse's new "Agentic browsing" category, from M150): did you register WebMCP tools, are there forms that should be exposed but aren't, are your input/output schemas valid. Good checks — and all about one thing: EXPOSURE. Did you OFFER the tools?

Shopify's UCP makes your catalog agent-buyable — discover, cart, checkout, standardized, shipping now. Real and worth doing. But be precise about what it *doesn't* cover: the parts of your storefront that make it yours. 🧵

Headless/non-Hydrogen or not on Shopify at all? You don't inherit /api/mcp for free — WebMCP is the lighter path for the whole interactive surface. Caveat: no mainstream agent calls navigator.modelContext yet (June '26), so instrument it and treat it as a cheap option.

Full write-up — where UCP ends and WebMCP begins, with code (I work on Latch, disclosed): https://dev.to/r0bertini/shopifys-ucp-makes-your-catalog-agent-buyable-the-rest-of-your-storefront-still-isnt-heres-pi9

UCP standardizes the commerce primitives every store shares. It doesn't describe your configurator, fit quiz, 'book a fitting', B2B quote, returns or subscription flows — the bespoke stuff that's often why a customer picked you over a generic listing.

That's the WebMCP-shaped gap. UCP = the shared commerce rails. WebMCP (navigator.modelContext) = the tool surface for everything your store does that isn't a generic commerce primitive. They compose: agent buys via UCP, runs your custom flows via your WebMCP tools.

Honest take before you add WebMCP to your site: as of June 2026 *no* mainstream AI agent calls navigator.modelContext yet — not ChatGPT Agent, not Claude, not Gemini, not Perplexity. They all still scrape the DOM or click pixels. So why ship it today? A short skeptic-friendly case 🧵

3/ The part most "install it now" posts skip: instrument it. Log every tool call from day one so you SEE the first real agent visit the day it happens — not a quarter later from a billing anomaly. Adopt the option AND the meter, or you've adopted neither.

Full write-up (with the one line most implementations forget + an honest disclosure that I work on Latch): https://dev.to/r0bertini/no-agent-calls-webmcp-yet-heres-the-honest-case-for-shipping-it-today-and-how-to-know-the-day-52ld

1/ The cost is near-zero if you do it right. It's feature-detected — a no-op in every browser that doesn't ship the API (almost all today). And a tool should be a thin typed wrapper over a function your UI already calls. No second codebase, nothing to undo.

2/ It's a dated option, not a promise. The folks building the browsers and the agents are the same companies pushing the spec. You don't need to know the date it lands — just that holding the option is cheap (it is) and the payoff is high (for anything transactional, it is).

Chrome's Lighthouse now ships an "Agentic Browsing" audit category (since 13.3, May 2026). Run it and you get a pass/fail on whether an AI agent can actually understand and operate your page. Four checks — here's what each tests 🧵

4. WebMCP — does the page register tools (navigator.modelContext, or declarative form annotations) with valid input schemas? It's the only one of the four that's a genuine bet on agentic browsing rather than hygiene you should already be doing.

Full write-up — how to pass each check, with code for the WebMCP one (feature-detect, reuse your existing handlers): https://dev.to/r0bertini/your-site-just-failed-lighthouses-new-agentic-browsing-audit-heres-how-to-fix-each-check-2l77 (disclosure inside)

1. llms.txt — present at the root, has an H1, real links (not empty) 2. Accessibility tree — every interactive element programmatically named, valid roles 3. CLS — the same layout stability from Core Web Vitals; agents driving a browser mis-click on reflow just like people do

18 June

WebKit just marked WebMCP "oppose" on its standards-positions tracker. Before you write off building for AI agents: most of the objection is good engineering feedback. The strongest one — "this duplicates the accessibility tree" — is correct, and it tells you exactly how to build. 🧵

18 June

The fix isn't picking a side, it's implementation. Your agent tool's handler should call the SAME function your "Add to cart" button already calls. One code path = one source of truth, so the tool registry can't desync from the page. Feature-detect it and you lose nothing if the spec stalls.

18 June

Wrote up the full take — what WebKit actually objected to, why the a11y tree alone is lossy for multi-step actions, and the design that survives the critique: https://dev.to/r0bertini/webkit-opposes-webmcp-heres-what-to-actually-build-today-18dn

Most AI agents still "use" websites by screenshotting the page and guessing where to click. It's slow and breaks constantly. WebMCP (navigator.modelContext) flips it: your site hands the agent a list of callable tools — search, add-to-cart, submit-form — each with a schema. 🧵

The honest catch: wiring registerTool() for every search box, cart action and form — plus schemas and a polyfill for browsers that don't have it yet — is real work. I work on Latch (open-source, MIT): one <script> tag introspects your site and registers the tools for you.

If you want to see where the spec stands and add a couple of tools yourself (no library required): Guide: https://latch.tools/webmcp Source: https://github.com/r0bertini/latch Happy to answer WebMCP questions in the replies.