Webmcpify

# webmcpify — make any web app agent-ready, verifiably

You are running the webmcpify pipeline. It takes an existing web application and

exposes its user-facing functionality as [WebMCP](https://webmachinelearning.github.io/webmcp/)

tools (`document.modelContext` — a proposed web standard incubated in the W3C Web

Machine Learning Community Group, currently a Chrome origin trial), so browser AI

agents can operate the app through structured tool calls instead of guessing at the DOM.

DETECT ──▶ INVENTORY ──▶ [HUMAN GATE: manifest approval] ──▶ INTEGRATE ──▶ VERIFY ──▶ HEAL ──▶ AUDIT
              ▲  loop            per-area batches on big apps    ▲  loop      ▲ loop    ▲ loop
              └── per area                                       └── per manifest entry ──┘

Everything you need ships inside this skill directory: phase guides in

`references/`, and vendorable code in `templates/` (runtime, ambient types,

JS variant, React JSX typings, verification spec). Never assume files exist

outside the skill dir.

**Out of scope** (stop and say so): backend-only MCP servers (that's classic MCP,

not WebMCP), automating third-party sites you don't control, and generic SEO work.

Invocation modes

The user may pass an argument (`/webmcpify <mode>` or plain words):

| Argument | Run | Stop at |

|---|---|---|

| *(none)* or `full` | all phases, resuming from current manifest state | done |

| `inventory` / `map` | DETECT + INVENTORY loops only — **zero code changes** | present the manifest table for review |

| `integrate` | INTEGRATE loop only (requires approved tools in the manifest) | integrated + built |

| `verify` | VERIFY + HEAL loops on integrated/verified tools | green/skipped report |

| `status` | read `.webmcpify/manifest.json` — **read-only** | report phase, per-status tool counts, and the recommended next command |

Any other text is scoping guidance (e.g. "only the checkout area", "read-only tools only").

Ground rules (non-negotiable, enforce in every phase)

1. **Zero unrelated changes.** Every diff hunk you produce must trace to a manifest

entry or the recorded one-time setup. Never refactor, reformat, rename, or

"improve" anything else — note problems in the report instead. Files that were

already dirty at baseline (recorded in the manifest) are **untouchable**: never

modify or revert them.

2. **Read-only tools first.** Mutations are tri-state: `mutating: false`,

`"client"` (browser-local only: prefs, localStorage), or `"server"` (data

leaves the browser). Server-mutating tools require explicit **per-tool** human

approval recorded in the manifest; client-mutating tools may be approved as a

batch at the gate. Never expose destructive, irreversible, or payment actions

in a first integration.

3. **The server is the only trust boundary.** A tool's `execute()` may only call code

paths the UI already uses (same endpoints, same validation, same auth). Never

create new endpoints, never bypass existing checks, never put secrets in tools.

4. **Spec-shaped and dependency-free.** Register via `document.modelContext.registerTool()`

with AbortSignal lifecycle (feature-detect the deprecated `navigator.modelContext`

fallback). No third-party WebMCP runtime dependencies. Everything feature-detected:

the app behaves identically in browsers without WebMCP.

5. **Never `toolautosubmit` on state-changing forms** — neither `mutating: "client"`

nor `"server"`. Only on pure read forms (search, filter, availability).

6. **State lives in files, not in your context.** Read/write `.webmcpify/` constantly;

assume your context can be wiped between any two steps. Write the manifest

atomically (write `manifest.json.tmp`, then rename over `manifest.json`).

7. **Commits are opt-in.** Never commit unless the human chose a commit policy at

the gate (see below). Without git or without permission, leave changes in the

working tree and record progress in the manifest only.

Fresh, authoritat