Glippy WebMCP

Make a website usable by browser agents — with tools wired to the code you already have, not to the shape of your pages.

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. This repository is a coding-agent plugin that audits what your site could expose, writes those tools against real seams in your codebase, proves each one works in a real browser, and publishes the manifests that let agents find them.

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

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.

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

A write is proved somewhere, by someone

An irreversible action is never fired to verify it. What gets proved is the prepare half, that the confirm half refuses a bad or expired token, and that the handoff lands on the right page — recorded as a pass for the parts proven, and explicit that the terminal action was not fired.

A plain write is different: it has to be executed to be verified, and executing it changes data belonging to somebody. So the run records which origin it ran against and whether the session was the account you designated for verification, and the publish gate checks both. A write proved against the live site, or on whoever happened to be logged in, does not ship.

The identity is declared as a probe, never a credential — you flag one account inside your own backend, and the document only says how to ask whether the current session is on it. Every other account, a real admin included, answers no. A flow document is public by construction, so it can carry no secret and name no person.

An unchecked session blocks, because a run that did not ask is not a run that found out.

Packages

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. Code written against it silently finds nothing.

Tool names are 1–128 characters of [A-Za-z0-9_.-] — that is normative, and violating it throws InvalidStateError. The ~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.

Development

pnpm install
pnpm test        # packages + the plugin hook
pnpm typecheck
pnpm lint

License

MIT.