Skip to main content
A compiled IR does nothing on its own. The runtime bundle registers it on the page as WebMCP tools, and sightkick call invokes them.

​
The short version

sightkick browser persists the injection, so the tools re-register on SPA route changes and on full page loads. After editing the corpus or the tool layer, re-run it with --no-start to refresh the IR on the running session.

​
Two execution paths

sightkick call takes --via, which decides how a tool’s steps actually run. They exercise different things and fail in different ways.

--via cli

Translates each step into sightmap browser commands, which act through real browser input events.

--via webmcp (default)

Asks the page’s own registered tool to run itself, which is the contract a real WebMCP client uses.

​
When to use --via cli

  • Portal-rendered targets. The runtime clicks by dispatching synthetic events, which do not reach elements rendered outside the app’s own DOM subtree, such as dropdown menu items and modal buttons. The same element takes a real click fine, so a tool that silently no-ops under --via webmcp often works here.
  • Any page you do not control. A third-party app has no Sightkick runtime on it, so there is nothing for --via webmcp to call.
  • Tools that navigate. A goto step needs to run from wherever you are. --via cli works from any URL.
It needs no runtime at all; a plain sightmap browser start is enough.

​
When to use --via webmcp

  • Testing the real contract. This is the path a WebMCP client takes, so it exercises registration, the input schema, and the result envelope end to end.
  • Confirming a tool is offered. A tool only registers on a page whose route matches its ensure_view. If it is not there, --via webmcp says so rather than quietly doing the work anyway.
On a page no view matches, sightmap browser mcp list reporting no tools is correct. Navigate to a matching route and they re-register on their own.

​
The native surface

On Chrome for Testing 152 or later, document.modelContext is the browser’s own WebMCP surface and Sightkick’s tools register on it directly, rather than on a polyfill. sightmap browser mcp list labels which one it found:
To drive the tools with Gemini through the bundled WebMCP inspector, start with the blink flags on:
Then open the inspector from Chrome’s side panel. It enumerates document.modelContext.getTools(), which now includes yours, and calls them through the native surface.
Do not script document.modelContext.executeTool yourself. Its call shape differs by surface: the polyfill takes a bare {name}, while a native document.modelContext is stricter and returns a stringified envelope. sightkick call handles both.

​
Reading a result

A failing tool names the step that failed:
If a wait_for times out on a component you can see on the page, the query is probably matching many nodes rather than none. Narrow it to 'FareCard#0'. See the warning in Tool layer.

​
Injecting it yourself

sightkick browser is a convenience. To put the tools on a page you serve, emit the two artifacts and load them:
load(ir) registers the tools whose view route matches the current URL, and re-registers on route changes.