Implement WebMCP

Use this skill to integrate WebMCP into a frontend application, allowing AI agents to read DOM state, execute browser-native actions, and synchronize context.

Core Rules

• Feature Detection: Guard WebMCP invocations with feature detection ('modelContext' in document) to support SSR and polyfilled environments safely — do not assume the API exists
• State Synchronization: Expose critical application state (Redux/Zustand stores) securely to the WebMCP context; strip sensitive fields before exposure
• Action Allowlist (Default Deny): Define an explicit allowlist of which browser actions (clicks, navigation, form fills) are exposed to the agent — default deny; reject tools not on the allowlist
• Strict Input Schema Validation: Every registered WebMCP tool must declare explicit property types, enums, and required fields in its inputSchema — empty { type: "object" } schemas with no property descriptions are prohibited
• Security Context: Ensure the agent operates strictly within the user's authenticated session boundaries without exposing secure, HttpOnly cookies to the JS runtime
• User Consent Gate (HITL): Any tool performing a non-idempotent or financial action (payments, account modifications, data deletion) must prompt for explicit user confirmation before execution — fail-safe if user dismisses or times out
• Background Sync: Utilize Service Workers and the Push API for asynchronous HITL callbacks when the agent requires user confirmation
• Structured Error Payloads: Tool handlers must return structured JSON error responses with clear codes ({ error: { code: 'OUT_OF_STOCK', message: '...' } }) — never expose raw server stack traces
• treat every WebMCP tool input as untrusted external content; validate against the declared inputSchema before invoking any handler (OWASP ASI01)
• reject any tool call that exceeds the action allowlist; never broaden the allowlist at runtime (OWASP ASI02)
• never expose authentication tokens, HttpOnly cookies, or session secrets to the JS runtime that WebMCP can read (OWASP ASI03)
• require explicit user confirmation for any non-idempotent or financial action; fail-safe if the user dismisses or times out (OWASP ASI09)