Is your web app ready for WebMCP? Run a baseline audit first
Start with the workflows, semantics, and verification signals your application already exposes before deciding which actions deserve tools.
The short version: The strongest WebMCP candidates are bounded, valuable workflows with explicit inputs, permission checks, and observable postconditions.
1. Start with a representative user goal
Do not begin by counting buttons or wrapping every endpoint. Write down one job a real user wants to finish: compare two products under a budget, reschedule an appointment, reconcile an invoice, or update a project status. A useful audit follows that goal from its initial state to a verifiable result.
Choose a workflow that happens often enough to matter and is narrow enough to test repeatedly. Open-ended research and highly subjective decisions can still involve tools, but they are poor first candidates for measuring whether WebMCP improved the application.
2. Define the starting state and postcondition
Record what must already be true: signed-in role, selected account, cart contents, draft version, or required consent. Then define a postcondition that can be observed independently of the tool response. A new stable record ID, a changed status returned by the backend, and a matching visible UI are stronger evidence than a string that says success.
- Initial identity and permission state
- Required inputs and allowed ranges
- Expected mutation or read result
- Confirmation or human-review boundary
- Visible and server-side verification signals
3. Inventory the human action surface
Walk the workflow with the keyboard and an accessibility inspector before adding agent tools. Record forms, labels, validation messages, loading states, and error recovery. If the human path is ambiguous, an agent-facing wrapper often preserves that ambiguity instead of fixing it.
Source actionability is not a score for visual beauty. It asks whether captured HTML exposes understandable controls and state transitions. A complete accessible UI also supplies graceful degradation when WebMCP is unavailable.
4. Rank bounded actions, not pages
A page may contain several actions with very different value and risk. Score each candidate on frequency, user effort, input clarity, side-effect severity, authorization complexity, and ease of verification. Start with the best combination of value, clarity, and reversibility.
- High value: repeated multi-step work with stable rules
- High feasibility: narrow inputs and one clear outcome
- Higher risk: irreversible effects, broad free text, or hidden permission changes
- Lower evidence quality: success cannot be checked outside the handler response
5. Write the measurement plan before implementation
Define equivalent UI-only and WebMCP-enabled journeys against the same fixture, starting state, and success criteria. Track outcome, committed actions or tool calls, retries, elapsed time, human intervention, and verified assertions. If either path fails, report the failure instead of letting an efficiency percentage hide it.
Avoid universal token or cost claims. Page structure, agent behavior, task complexity, and implementation quality all change the result. Measure your workflow, publish the counting rule, and keep raw event evidence available.
Evidence note. Quick Scan analyzes public source only. It cannot execute target JavaScript or certify runtime conformance.
Primary references
Read the sources
Put it to work
Use the guide on a real product surface.