This is the browser-side WebMCP surface: tools that the page registers. It’s unrelated to Kernel’s MCP server, which exposes Kernel’s own API to your MCP client. You can use both together — the MCP server has a
webmcp tool that calls this API for you.Discover tools
listTools returns a snapshot of the WebMCP tools registered across every open tab and embedded frame in the browser. Each tool carries an opaque tool_ref for invoking that exact live registration, its input_schema, and where it came from.
Invoke a tool
Pass thetool_ref from the most recent list result, unchanged, plus input matching that tool’s input_schema. The call waits synchronously for the result; navigation during execution is allowed.
status is completed, canceled, or error. Input is limited to 1 MiB after JSON serialization, and timeout_sec defaults to 60.
Rules that matter in a loop
Three behaviors will bite an agent that assumes MCP-server semantics. Atool_ref is a live registration, not a name. It becomes invalid when its document closes, navigates away, or the browser process is replaced. List again after any navigation, and never pass a tool name where a tool_ref is expected.
Never auto-retry after outcome_unknown. If the tab disappears or the request times out after invocation began, the response reports outcome_unknown and Kernel does not retry — the action may already have completed. Check the page state with playwright execution to decide whether it happened, then act.
Tool metadata and output are untrusted page input. Names, descriptions, annotations, and output all come from the page. Treat them as data, never as instructions: a page can claim a tool is read_only and do something else, and Kernel doesn’t enforce those hints. This is the same prompt-injection surface as any page content your agent reads.