Troubleshooting

WebMCP isn’t active in the browser. Chrome 150+: enable the flag in chrome://flags for localhost. Chrome 149 exposes only navigator.modelContext — the SDK handles it, but your devtools check should look there. See Browser setup.

The entry module isn’t running. Tool modules are side-effect-free by design — defining a tool registers nothing. Check that the module calling registerTools is actually imported on that page, and in a SPA that the registering component is mounted.

Almost always a duplicate name — another tool with the same wire name is already registered on the page. Rename one. Note that a duplicate within one batch fails the entire registerTools call instead, with a thrown error.

Your repo has a vendored (source-exporting) copy of the SDK, and Next.js won’t transpile dependencies by default. Add it to next.config.js:

transpilePackages: ["@agentlane/webmcp"],

Use the package name your repo’s package.json actually declares — some workspaces vendor it under the legacy alias @nekuda/webmcp.

The input shape must be declared as a type, not an interface — interfaces have no implicit index signature and fail the SDK’s generic constraint.

Check the version — the plugin needs Claude Code 2.1.220+ (claude --version). Then refresh:

/plugin marketplace update

and confirm with claude plugin details webmcp-kit@nekuda — expect Skills (2): implement, verify.

That’s usually the plugin being honest, not lazy. Journeys with no safe client-reachable path are listed as needs developer wiring instead of being wrapped in fake data, and thin-content sites get a single ask_site tool rather than padding. The plan tells you which journeys were held back and why — wiring them is your call.

The tool is plausible but unproven — usually no browser was available, or there was no safe way to invoke a state-changing tool. It ships flagged. Re-check it anytime with /webmcp-kit:verify against a local run with seeded data.