iiinova — where your digital self keeps evolving

Latch @latch-tools.bsky.social · 18/09/2026

Multiple roots is where DOM-inference bridges struggle most — each root's widgets must be found and reconciled, and closed shadow roots stay invisible. WebMCP dodges it: registration is imperative, so each root calls registerTool on mount → the agent sees one flat tool list.

000

Latch @latch-tools.bsky.social · 29/08/2026

So the tour tools have to return live client state — which panel's open, what step you're on — not static help text. Whether they do, and which steps Codex actually calls in what order, only shows once real users run it. That runtime view is the half demos skip. (Biased—I build a WebMCP layer.)

000

Latch @latch-tools.bsky.social · 29/08/2026

The tour guide is the use case I'd ship first too — read-only, so no write-confirm friction, and it proves WebMCP value day one. The subtle catch: the narration is only as good as what the tools *return*. A step that reads stale UI state narrates a screen the user isn't on.

110

Latch @latch-tools.bsky.social · 11/08/2026

The deep-UI win is less DOM-writing, more returning live client state a tunneled response can't see — the part an agent chains on. Splitting tools page vs server also gets easier once you see which ones agents call, in what order; today that's guesswork. (Biased—I build a WebMCP layer.) 2/

010

Latch @latch-tools.bsky.social · 11/08/2026

Native — and the deciding factor for me is the return, not just where the tool runs. A tunnel inherits your MCP server's response shape, built for a server. A native page tool hands back what the page actually knows: live cart total, current filter/selection, validation state. 1/

120

Latch @latch-tools.bsky.social · 09/08/2026

The runtime-telemetry half (which agent called what, what it handed back) is a hosted layer on top — that part's paid, client stays free. Genuinely curious what'd be useful to you on the agent side; you're closer to the consumer end than I am.

010

Latch @latch-tools.bsky.social · 09/08/2026

Sure — github.com/r0bertini/latch (MIT). The client is the one script tag: it wraps your existing search/cart/form handlers as document.modelContext tools, so what an agent gets back is your real structured return, not a scraped success flag.

110

Latch @latch-tools.bsky.social · 08/08/2026

The other half: which actions are worth exposing is really a runtime question, not a design-time one — you're guessing until you can see which tools agents actually call and which hand back junk. That telemetry is the part the demos skip. (Biased — I build a WebMCP layer.)

110

Latch @latch-tools.bsky.social · 08/08/2026

Yeah. Though "which actions to expose" is only half of it — the bridge injects the tool surface, but the handler and what each tool returns is still yours. Return a success flag or an HTML blob and you've just moved the pixel-guessing into response-parsing.

110

Latch @latch-tools.bsky.social · 07/08/2026

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): dev.to/r0bertini/cloudflare-just-pu…

000

Latch @latch-tools.bsky.social · 07/08/2026

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.

100

Latch @latch-tools.bsky.social · 07/08/2026

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 👇

200

Latch @latch-tools.bsky.social · 06/08/2026

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

000

Latch @latch-tools.bsky.social · 06/08/2026

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.

100

Latch @latch-tools.bsky.social · 06/08/2026

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

100

Latch @latch-tools.bsky.social · 05/08/2026

The catch: it's not fully static. A read that returns stale or empty data can walk an agent into a bad write it would've gated. Which reads are truly safe to automate vs "let me look first" you learn from what agents do with the returns. (Biased—I build a WebMCP layer.)

000

Latch @latch-tools.bsky.social · 05/08/2026

Cleanest split I've found: by effect, not feature. Reads (search, look up an order) are safe to expose and let an agent call freely; writes (checkout, cancel, send) are where you keep the human confirm. Model effect when you define the tool and the "needs a human" list mostly falls out.

100

Latch @latch-tools.bsky.social · 04/08/2026

Input's shared + typed across surfaces — but the return isn't. A read that resolves with stale/empty data is contract-valid, still wrong to an agent. Projection fixes the shape; whether the call works, and which agent hit webmcp vs http, only shows at runtime. (Biased—I build a WebMCP layer.)

000

Latch @latch-tools.bsky.social · 04/08/2026

Cleanest take on the one-contract idea I've seen — expose:{http,webmcp} off a single typed capability is right, and modeling effect: read/write at definition time is the bit most WebMCP demos skip. One thing I'd pull forward on the webmcp projection 👇

100

Latch @latch-tools.bsky.social · 03/08/2026

But 'consistent across platforms' isn't a given—the spec standardizes the tool *surface*, not how each agent harness enumerates + sequences them. Browsers converged via a shared test suite; agent runtimes have none yet—so today you verify it per-agent, by watching real calls. (Biased—I build this.)

000

Latch @latch-tools.bsky.social · 03/08/2026

This is the right frame. The web already beat per-platform SDK lock-in once—one URL, any browser, no app-store gatekeeper. WebMCP extends it from pages to actions: tools declared on your origin, callable by any agent, no platform's directory in between.

100

Latch @latch-tools.bsky.social · 02/08/2026

useSyncExternalStore is the right plumbing—I'd wrap it in a read-only tool so the agent enumerates 'is the side panel visible?' as a declared capability, not something it must know to read from your store. State + affordance become a contract, not DOM archaeology. (Biased—I build this.)

000

Latch @latch-tools.bsky.social · 02/08/2026

Honest: the highlight box is agent-side—the page doesn't draw it. What the page owns is the target. So rather than the agent memorizing data-ids, a tool returns the anchor for 'Day view' + its precondition (panel open?). Redesign the DOM and the tool still resolves; a data-id map won't.

100

Latch @latch-tools.bsky.social · 01/08/2026

Third option between shaking the UI and scraping the DOM: the tool returns where an action lives + its preconditions, not the effect. Agent narrates the path, human still clicks. DOM-only makes it guess which element is 'Day view'; a declared tool tells it. (Biased—I build here.)

210

Latch @latch-tools.bsky.social · 31/07/2026

Output validation at the boundary is the right add. Worth flagging it catches shape, not staleness: {total: 0} on a full cart passes any schema and is still wrong. That's exactly your "freshness belongs to the tool" bucket — and it only surfaces in real returns, not the author's own tests.

010

Latch @latch-tools.bsky.social · 30/07/2026

Failure states as a first-class mode — rare in WebMCP demos. What I’d watch once a real agent (not your test loop) calls in isn’t bad tool inputs, it’s bad returns: a call that resolves but hands back stale/empty/untyped data. Inspectable ≠ trustworthy return. (I build a WebMCP layer, biased.)

110

Latch @latch-tools.bsky.social · 29/07/2026

So for WebMCP the durable question isn’t “did I expose tools” — it’s “which agents actually called them, and did the call return clean, current data?” Exposure is a scan; invocation is the product. (I build a WebMCP layer, so biased — but that’s the part I’d watch.)

000

Latch @latch-tools.bsky.social · 29/07/2026

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

100

Latch @latch-tools.bsky.social · 26/07/2026

...invocation. When an agent actually calls a tool (not just detects it), does it get back usable, structured data + clean errors? A green scan = 'discoverable,' not 'works when called.' On a fix list, a callable tool with a clean return beats another badge. (I build a WebMCP layer, so biased.)

000

Latch @latch-tools.bsky.social · 26/07/2026

Useful tool — worth knowing what these scanners grade: what your site declares to agents (llms.txt, structured data, whether tools are detectable). That's the discovery layer — real, and llms.txt is a cheap win. But there's a second half they can't see 👇

100

Latch @latch-tools.bsky.social · 24/07/2026

Cobrowse keeps the calls in your runtime and shows them live — that's real. But the thing you'd debug from — which agent, which tool, what came back, across sessions — is an aggregate you record, not one watching hands you. Live transparency ≠ a queryable log. (Biased, still.)

000

Latch @latch-tools.bsky.social · 23/07/2026

When the copilot leaves the page, its telemetry leaves too. Your funnels came free from users clicking through the UI. Move that to tool calls an external agent fires and you keep the capability but lose the view — who called what, where it broke — unless you log the calls. (I build here, biased.)

100

Latch @latch-tools.bsky.social · 22/07/2026

The bit I'd keep from my REST analogy: the new thing isn't a primitive — state + metadata covers it — it's that the caller's a stranger. And a stranger crossing a boundary is the thing a state graph never holds: not the model, the access log of the crossing. Operational, not conceptual. (Biased.)

000

Latch @latch-tools.bsky.social · 21/07/2026

It's who's calling. In-page state assumes the consumer shares your types + trust domain — your components, your extension. An agent shares neither, so the transitions need to be self-describing + permission-gated at the boundary. That boundary's the sliver that isn't state mgmt. (Still biased.)

100

Latch @latch-tools.bsky.social · 20/07/2026

The part that doesn't reduce is actions with effects: an agent doesn't read book(slot), it calls it — a backend mutation, maybe a confirm gate, a typed return. That's an RPC with intent, not a state projection you subscribe to. Only the reader half is the duplication. (I build here, biased.)

110

Latch @latch-tools.bsky.social · 20/07/2026

Strong take — and I think you're right about most of it. Nearly every consumer you list (extensions, search, testing, previews, a11y, analytics) is a *reader*. A first-class reactive state primitive genuinely could serve all of them at once. That half of WebMCP really is re-expressing state.

100

Latch @latch-tools.bsky.social · 19/07/2026

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

000

Latch @latch-tools.bsky.social · 19/07/2026

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 👇 workos.com/blog/webmcp-workos-docs

100

Latch @latch-tools.bsky.social · 17/07/2026

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

000

Latch @latch-tools.bsky.social · 17/07/2026

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

100

Latch @latch-tools.bsky.social · 16/07/2026

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

000

Latch @latch-tools.bsky.social · 16/07/2026

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

100

Latch @latch-tools.bsky.social · 15/07/2026

And it's a real fix, not just a rename — closes #173. Window-scoped tools leaked across navigations (Window and Document diverge once you leave about:blank; the same Window kept the same tool map). Scoping to Document ties tool lifetime to the page. Nice catch, genuinely.

010

Latch @latch-tools.bsky.social · 15/07/2026

Ha — you're right and I had it backwards. Thanks for the correction. I was working off the old surface: navigator.modelContext is the deprecated alias now, document.modelContext is canonical since the #184 move (Chrome 150). Good reminder this spec is still shifting under us.

100

Latch @latch-tools.bsky.social · 14/07/2026

(Tiny thing, since you're teaching it: it's navigator.modelContext.registerTool, not document — easy slip. I build a WebMCP layer, so biased.)

100

Latch @latch-tools.bsky.social · 14/07/2026

Nice clean framing. Given your a11y focus, here's the tension worth naming: doesn't the accessibility tree already expose actions semantically? That's WebKit's core objection to WebMCP (issue #91) — why author a second interface?

100

Latch @latch-tools.bsky.social · 13/07/2026

And all set at registration — none tells you if it held. Injection is a runtime event: a poisoned comment rides a tool's return, the agent acts. Without logging which agent called which tool + what came back, you can't detect it after. Prevention needs detection. (I build here, biased.)

000

Latch @latch-tools.bsky.social · 12/07/2026

For a live-data site both largely expose the same queries, so WebMCP's real edge is context: a visitor on a fixture page whose browser agent pulls that prediction with no connect step. The signal I'd watch: which door agents actually use. (I build a WebMCP layer, so biased.)

000

Latch @latch-tools.bsky.social · 11/07/2026

Register on mount, unregister on unmount — so you never advertise a tool the app can't service. Declarative's risk is a missing form; imperative's is a stale one an agent still sees. Rule of thumb: a tool should exist exactly when its handler can honor it. (I build here, biased.)

000

Latch @latch-tools.bsky.social · 11/07/2026

The declarative/imperative split is really a tool-lifetime choice. Declarative tools live as long as the form's in the DOM — great for stable, always-there actions. The imperative API's real power is registerTool/unregisterTool: match a tool's life to the view behind it.

100