implement

WebMCP Kit — implement

Mission

• WebMCP hands a browser agent typed tools (via the @nekuda/webmcp-sdk SDK) so it answers from the site's own content and acts through the site's own logic. User and agent share the visible page — every tool produces a visible effect.
• Tools answer "what will a visitor ask, and ask for, here?" — journeys, never REST-endpoint wrappers.
• In every human-facing run, the plan you present in Phase D is approved by the developer before any file is written. That gate is the product, not a formality.

Hard rules

• Source analysis and code stay local. Never send customer code, routes, or schemas to an external service or to an unauthenticated tool/API. The tool-selection rubric is this skill's text — there is no hosted scanner. The optional post-build Connect flow sends only the CLI's structured project/account request described in references/connect.md; it is separate from the SDK's documented default-on anonymous observations, which are independent of Connect.
• Client-reachable wiring only. execute may use the app's own client data layer, same-origin routes, or client-safe actions — never server-only imports, secrets, third-party endpoints, or DOM-scraping when a data path exists.
• Flag, don't fake. A journey with no safe client path is listed as needs developer wiring — never invented data or a dead call. A guidance-only stub does not "cover" a must-have.
• Irreversible/cost-bearing writes need a boundary. A payment, cancellation, or delete must not complete in one agent call. The generated tool stops at a reversible handoff — creates the repo-native pending state (checkout session, pending order, prepared cancellation) and hands the final step to the app's own payment/confirm UI, or uses a prepare→confirm two-call shape. A consequence sentence in the description is not a boundary.
• Authorization is the server's job. Registration gating on auth/role is UX, not security. Only wrap a privileged mutation whose route independently enforces authn/authz server-side; an endpoint that trusts a hidden client button is needs developer wiring, not a tool.
• No changes or Connect before approval. No branch, file, dependency, or Connect attempt until the developer approves the plan, except the tool-generation workflow in explicit --non-interactive mode; that exception permits the branch, files, and dependencies needed for generation but never Connect, which non-interactive mode skips. This skill reads with Read/Grep/Glob during A–C — plus one read-only exception: the Phase-F baseline capture (the repo's own typecheck/build, references/verify.md) may run as a background task before approval, because it writes nothing to the tree; after approval it requests the write, package-manager, and browser permissions it needs through the normal permission prompts — no mutation is pre-authorized. Interactive Connect is a separate, optional post-build decision (references/connect.md).
• SDK only. Generated code imports defineTool / registerTools from the SDK under its resolved name (the installed package's declared name — references/sdk.md); never the raw modelContext surface, never a bundled polyfill/shadow. The SDK pins the spec, resolves whichever surface the browser exposes, and no-ops when unsupported.