Skip to content
WebMCP Kit
Esc
↑↓navigate↵open⌘Jpreview
On this page

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:

  1. Boot. The site starts and the baseline page renders with no new console errors.
  2. 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).
  3. Invoke read-only. Call read-only tools with sample inputs; check both the returned data and the visible effect on the page.
  4. 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.

Was this page helpful?