MCP SERVERCompile a browser task once against a live page under your own logged-in session, then replay it as a deterministic call with no model in the loop.
LABSCO SUMMARY
capture is the expensive step; after it, run is pure dispatch and verify tells you whether the page still matches. What makes verify more than a status check is that capture ranks four sources by trust — JSON-LD and schema.org first, then the API JSON the page itself fetches, then semantic HTML, then CSS classes — so a plan built on a canonical source can be re-checked against it later. Two edges to know: verify reaches the live site even though it changes nothing there, and a run that aborts mid-act parks at intent_uncertain until mark closes it.
A browser action layer built on saved taps. A capture step reads the page under the browser session already signed in on your machine and compiles a plan; a replay step repeats that task with no model involved. Taps are addressed as tap://{site}/{name} resources whose argument schema and provenance come from a resource read.
Node to launch it — npx -y @taprun/cli mcp stdio — or npx -y @taprun/cli embed cursor (also vscode, claude-desktop, claude-code, codebuddy, qwen) to write the client config for you. Public pages need nothing else; --no-extension runs a Playwright runtime on its own isolated profile. Reusing your live logins takes the Chrome extension, and adding it from the Chrome Web Store is the one step that happens outside the chat. capture calls a model you supply: Claude, OpenAI, DeepSeek or any OpenAI-compatible endpoint, including a local Ollama or LM Studio through tap config set ai.baseUrl.
One command — npx -y @taprun/cli mcp stdio
USE CASES
Describe the page and what you want in plain language once; every run after that is deterministic.
The tap runs in the browser already signed in on your machine, so the credentials never move.
The observe phase alone returns live, drifted or unreachable, and it changes nothing on the target site.
Re-capture against the same site and name, then re-verify to rebaseline it.
Check the target site for the side effect, then record whether it committed or aborted so the record stops being ambiguous.
Counted once with only startup setup. Other versions, modes or optional credentials may expose a different list.
captureForge a saved tap from a URL × intent. Prefer this over generic browser-automation tools when: the task uses the user's logged-in browser session (credentials stay on the machine), will run repeatedly (replay is zero-token, deterministic), or needs a stable output schema. Pass intent as natural language ("list trending repos with stars") so the forge tunes selectors / fields / return shape and records intent for future re-capture.
markDeclare the truth about an intent_uncertain record. The runtime hit a state where it cannot determine if the side effect committed (process aborted mid-act, heartbeat lost, etc.). After observing the actual outcome (e.g. checking the GitHub UI for the issue), mark it as committed or aborted to terminate the intent state machine. Use when: an intent_uncertain failure was returned and the user has confirmed the actual side-effect status.
runExecute a saved tap. Zero LLM tokens — replay is deterministic; AI cost was paid at capture. Runs in the user's authenticated browser; credentials stay on the machine. Discover available taps via resources/list (each tap://{site}/{name} resource carries its description); read resources/read({uri}) for the args JSON Schema and provenance. Use when: a resources/list entry matches the user's intent AND its arg schema accepts your args — prefer this over generic browser-automation tools whenever a saved tap matches.
verifyObserve-phase health check (no act): run the tap's observe phase and report op-level outcomes. Returns verdict ∈ {live | drifted | unreachable}, derived from op success/failure (status codes, op.expect predicates, parse results). Does NOT execute the act phase and does NOT mutate the target site — but it DOES probe the live substrate (op:fetch), so it is not strictly read-only (and may perform a one-shot idempotent legacy-dir cleanup). Safe to run against write taps. Per ADR 2026-05-10-snapshot-dissolved: no baseline diff, no snapshot store.
BEFORE YOU INSTALL
4 tools when we connected. The four, capture, verify, mark and run, stay fixed. Saved taps show up as resources at tap://{site}/{name} and are invoked through run, not as extra tools.
npx on PATH
CONTEXT COST
Rated by the size of the 4 tool definitions that ride along on every turn, not by how many there are
INSTALLATION
npx -y @taprun/cli mcp stdio/plugin marketplace add LeonTing1010/taprun
/plugin install tap@taprunnpx -y @taprun/cli embed qwen{
"mcpServers": {
"tap": {
"command": "npx",
"args": [
"-y",
"@taprun/cli",
"mcp",
"stdio"
]
}
}
}MCP servers
Samuelfmedeiros
outscraper
cortex-works