Test existing WebMCP tools in a real browser
Check WebMCP tool registration, calls, page effects, and cleanup in a real browser.
/webmcp-kit:verify http://localhost:3000
Checks that a locally running site’s WebMCP tools actually work: registered on the right pages, absent where they shouldn’t be, and returning real results when called.
Run it against tools you already have. You do not need to generate tools with WebMCP Kit or use the Nekuda SDK. The implement skill uses the same checks after it adds tools.
For a small app with known results, start with the verification example. Run the same board app with the SDK or native WebMCP. Both versions use the same form and application function.
Before you start
- The site must be running locally (its own dev script or runbook).
- Install WebMCP Kit and Bun.
- The skill uses the kit’s included browser driver to start a separate test browser with WebMCP enabled. See Browser setup.
The ladder
Each rung must hold before the next runs:
- Boot. The site starts and the baseline page renders with no new console errors.
- Discover. On each declared page and auth state, list the registered tools. Each tool must appear where declared, be absent where it shouldn’t be (logged-out account tools, wrong-role tools), and unregister on its declared exits (empty cart, logout).
- Invoke read-only. Call read-only tools with sample inputs; check both the returned data and the visible effect on the page.
- Invoke state-changing. Only against local, dev, or seeded data, and only with an explicit go-ahead. Never against production or third-party services. No safe way to invoke → the tool is reported could-not-verify, not fired blindly.
The report
One state per tool, printed as a table:
| State | Meaning | What happens |
|---|---|---|
| verified | Registered and invoked as declared. | Ships. |
| failed | Didn’t register, or errored. | Fixed or dropped — never ships broken. |
| could-not-verify | Plausible but unproven (no browser, no safe invocation path). | Ships, explicitly flagged. |
Include what was observed: the registered name, input, returned result, visible page change, invalid-input result, and cleanup. See the example report for a completed check.