Skip to main content
Glama
navig-run

NAVIG

Official
by navig-run
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Dock act

dock_act
Destructive

Run up to 12 browser actions in one call per tab and return per-step results plus a page outline. Pass the snapshot doc to reject clicks if the page changed first.

Instructions

Act in a tab with trusted input — up to 12 steps in ONE call. Returns per-step results and (observe=true, the default) the page outline afterwards, so you rarely need a separate dock_snapshot. Pass doc from the snapshot you read so a page that changed under you is refused instead of clicked blindly.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
docNoThe doc id from the snapshot the refs came from.
tab_idYesTab id from dock_tabs or dock_open.
actionsYesOrdered steps, run one after another; the first failure stops the batch and later steps are skipped (results say which ran). Each step is {"action": verb, …}. TARGET = ref (a [ref_N] from dock_snapshot) OR a locator: role (+ name), testid, css, has_text or xpath (+ nth, 1-based) — a locator matching several elements fails as ambiguous, never guesses. Verbs: click {TARGET | x,y, button?, clicks?} · type {text, TARGET?, clear?, submit?} · fill {TARGET, value} (sets a field / checkbox / dropdown directly — fastest) · key {keys e.g. "Control+a"} · scroll {direction up|down, amount? | TARGET} · hover {TARGET | x,y} · select {TARGET, value} · navigate {url | back | forward | reload} · wait {ms ≤ 5000} · wait_for {locator | url_contains, gone?, timeout_ms ≤ 15000} (event driven) · extract {TARGET, attr?, max?} (text / links of matching elements) · get_text {} · upload {TARGET (a file input), files: [absolute paths on this computer]} (the user confirms on the page). click / type / key / navigate take dialog: accept|dismiss for an alert/confirm/prompt the step opens (default dismiss; prompt_text answers a prompt). Typing into a password or card field asks the user first.
observeNotrue: the page outline after the steps (default); "diff": only what changed; false: nothing.
deadline_msNoMilliseconds to wait for the action to complete

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.2

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Far exceeds what the annotations convey. It discloses that the batch caps at 12 steps, that the first failure aborts remaining steps, that per-step results are returned, the observe/diff/none return modes, the doc-guard that refuses a stale page, and that typing into password/card fields prompts the user.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the primary capability, then the return behavior, then the safety contract. No filler; each sentence carries distinct information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex batch tool with no output schema, the description still explains the return shape (per-step results plus page outline) and the key behavioral constraints. Combined with a fully-documented schema, nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: the 12-step cap on `actions`, the rationale for passing `doc` (a changed page is refused rather than clicked blindly), and the default for `observe`.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (batch actions in a tab, up to 12 steps in one call) and names the sibling it substitutes for: 'you rarely need a separate dock_snapshot.' The core 'act' verb is a bit broad on its own, but the batch framing and sibling reference make the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear usage context: this is the multi-step execution path, and it explains the workflow ('pass doc from the snapshot you read') plus the payoff of not needing a separate snapshot. It stops short of explicit when-not-to-use guidance or naming atomic alternatives like cdp_click.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools