Glippy WebMCP: make your site usable by browser agents

Why this exists

WebMCP lets a page hand a browser agent typed tools through document.modelContext, so the agent acts through your own logic instead of guessing at your DOM. That is the easy part to describe and the hard part to ship. Writing the tools by hand means deciding which user intents are worth exposing, finding a place in your code stable enough to attach them to, checking they actually run in a browser, and then making sure an agent can discover them at all.

Glippy WebMCP is that whole arc, run by the coding agent you already use. You point it at your project and ask it to audit the site's agent readiness. What comes back is a coverage table, not a pile of generated code.

Install

Claude Code

/plugin marketplace add glippy-dev/glippy-webmcp
/plugin install glippy-webmcp@glippy-dev

Codex

codex plugin marketplace add glippy-dev/glippy-webmcp
codex plugin add glippy-webmcp

Then, in your own project, ask your agent to audit the site's agent readiness.

What it does: four skills, one arc

The audit runs demand-first

Inventory a codebase first and you get forty candidate tools, on a page where Chrome's own guidance says an agent starts choosing worse above about twenty. Supply-first auditing is how a site ends up keyword-stuffed with tools nobody calls.

So the audit establishes what people actually try to do on the site, then inventories the seams, and matches only at the end. The row it exists to be able to print is SKIP - no demand.

Tools attach to seams, not to pages

Each tool takes the highest rung available, because the rung decides whether it still works after the next redesign:

1. An exported client function: already typed and exercised by your UI.
2. An HTTP route the client already calls: stable across restyles, and if the route validates its body, your input schema was written by someone who knew the answer.
3. A form, including the declarative target, marked experimental because the spec section describing it says, verbatim, “This section is entirely a TODO.”
4. Recorded DOM steps: works on anything, breaks on the next redesign.

Writes are gated, because the platform does not gate them

WebMCP has no consent primitive. requestUserInteraction() does not exist in the spec repository at HEAD, despite Chrome's documentation referring to it. So nothing in the platform stops a browser agent from calling a tool that charges a card.

Glippy WebMCP enforces it instead, as an error rather than a convention: an irreversible action must be gated by a confirmation in handoff mode, or end at a terminal navigation that returns control to your own UI. A warning sentence in a tool description is not a gate.

Actions are classified by effect, not by HTTP verb. A GET that starts a checkout session is a write, and readOnlyHint is derived from the step graph rather than trusted from the author, so a tool that writes cannot describe itself as safe.

What is in the repository

The expression resolver is a path walker, not an evaluator: no eval, no new Function. A flow document is fetched over the network and inlined into your page, so anything that could execute arbitrary text would be a remote-execution primitive aimed at your visitors. It also means the runtime works under script-src 'self' with no unsafe-eval.

Platform notes

• The surface is document.modelContext, a partial interface Document. The string navigator appears zero times in the specification at HEAD. navigator.modelContext is a 2025 alias that survives only as a deprecated fallback in polyfills, and code written against it silently finds nothing.
• Tool names are 1 to 128 characters of [A-Za-z0-9_.-]. That is normative, and violating it throws InvalidStateError. The roughly 30-character figure that circulates is Chrome ergonomics guidance, so this repository treats it as a warning and never as an error.
• For local development: chrome://flags/#enable-webmcp-testing.

How it fits with the rest of Glippy

The Glippy WebMCP checker in the Chrome extension, the desktop app and the MCP server tells you whether a page already exposes WebMCP tools and the wider agent-discovery surfaces: MCP server cards, A2A agent cards, Agent Skills, NLWeb, schemamap and Web Bot Auth. That is the measurement side.

Glippy WebMCP is the build side. The checker says a page has nothing for agents to call. This plugin is how you fix that, in your codebase, with your own logic behind it. The two are independent: you can run the plugin without ever installing Glippy, and the plugin is MIT licensed with no account required.

Questions people ask

Is it really free?

Yes. MIT end to end. There is no vendor SDK and no telemetry, and the runtime makes no network request other than the ones your own tools declare. A test fails the build if that stops being true.

Do I need to rewrite my site?

No. The point of attaching tools to seams is that the tools sit on top of code you already ship. If your UI already calls a typed client function or an HTTP route, that is the tool.

Which coding agents are supported?

Claude Code and Codex, through their plugin marketplaces. The skills themselves are plain files, so any agent that can read a repository of skills can follow the same arc.

Is WebMCP stable enough to adopt?

It is still an emerging standard, which is why Glippy scores it as a bonus rather than a penalty. Adopting it now is cheap if the tools attach to seams you already maintain, and expensive if they are recorded DOM steps that break on the next redesign. That ranking is built into the plugin for exactly this reason.