Use WebMCP Tool
TLDR Dev
There's now a React hook that lets AI agents call functions on your webpage instead of screen-scraping it. Chrome maintains it, and it politely does nothing on browsers that don't support the spec yet.
WebMCP is one of those ideas that sounds obvious once you see it: instead of an AI agent squinting at your DOM, parsing accessibility trees, or taking screenshots to figure out how to click an 'Add to cart' button, the page just tells the agent what it can do. Chrome's experimental API does this through document.modelContext.registerTool, letting a site expose named functions with schemas and descriptions that any agent — built into the browser, sitting in an iframe, or running as an extension — can discover and call directly.
The raw API is imperative and a little clunky for anyone used to React's declarative style: you spin up an AbortController, register a tool object, and remember to call abort() when you're done. That's exactly the gap use-webmcp-tool fills. It's a hook, published this week, that wraps the whole registration lifecycle inside a component's own mount and unmount cycle. Drop a useWebMCP call into a TodoTools component, and the 'add-todo' tool appears when that component renders and vanishes the moment it unmounts — no manual cleanup, no stale tools left dangling after a user navigates away.
What's notable is how seriously the package treats the boring parts. Because WebMCP is still experimental and only lives on document.modelContext where supported, the hook feature-detects and quietly no-ops everywhere else, so it won't crash sites on Firefox or Safari. It also normalizes whatever a tool's execute function returns: strings become text content, thrown errors (even non-Error throws like a bare string or object) get flagged with isError so an agent can't mistake a failure for success, and arbitrary objects get JSON-serialized automatically. There's also logic to avoid re-registering a tool needlessly — changing an execute function's closure doesn't trigger churn, but renaming the tool does.
It ships small: ESM only, TypeScript types included, zero runtime dependencies, React 18 as the only peer requirement. The author backed it with 21 vitest tests covering StrictMode double-mounting, late API injection, and the entire error-normalization matrix, which suggests this isn't a weekend proof-of-concept so much as an attempt to make a shaky, still-forming browser spec feel production-ready inside the framework most web developers already reach for.
My take
This is a smart, narrow bet on a spec that barely exists yet, and I like that the author hedged it correctly — feature-detect, no-op, don't break sites — rather than pretending WebMCP is stable. Chrome owning the spec should worry the open-web crowd a little, since 'browser-maintained agent API' has a way of becoming 'whatever Chrome ships first, everyone else copies.' Still, tying tool lifecycle to component lifecycle is the right call, and it's the kind of unglamorous plumbing that makes agentic browsing plausible instead of theoretical.
Read more about this at: TLDR Dev