Body-MCP

hands_batch

Executes a declared sequence of browser actions in one request, verifies each step, stops on first failure, and resumes from checkpoints.

Instructions

Execute a declared sequence of browser actions in ONE request.

Actions: goto, click, fill, press, scroll, wait_for, verify_text, verify_url, screenshot. Validate-then-execute; stop on first failure (or on_failure='continue' for SAFE steps only); per-step and total timeouts; consequential clicks still require fresh approval per step; no JavaScript/Python/shell escape hatches; duplicate consequential submissions refused.

Verification outcomes (in result): completed | failed | blocked | needs_user | retry_scheduled. Never reports success without verification evidence.

resume_from=<checkpoint_id>: re-inspect the page and resume from the last verified step — never blindly replays; redacted steps need fresh explicit text. task_id=: run as the SAME task (use the task_id from a previous needs_user result when re-running after approval — scoped approvals are bound to it).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "actions": "<actions>"
    },
    "name": "hands_batch"
  }
}

Input Schema

Name	Required	Default
`actions`	Yes
`task_id`	No
`on_failure`	No	stop
`deadline_ms`	No
`resume_from`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.0Nov 13, 2026

TDQS

A4.2/5.0

Behavior5/5

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

No annotations exist, so the description carries the whole burden and does so thoroughly: approval requirements for consequential clicks, duplicate-submission refusal, absence of JS/Python/shell escape hatches, per-step and total timeouts, stop-on-first-failure semantics, and an explicit statement of verification outcomes (completed | failed | blocked | needs_user | retry_scheduled) with the guarantee that success is never reported without verification evidence. This is behavior an agent could not infer from the empty annotation set.

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

Conciseness4/5

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

Front-loads the core statement in the first sentence, then organizes the rest into labeled blocks (Actions, the execution-policy semicolon run, Verification outcomes, resume_from, task_id) with zero filler. The semicolon-dense policy paragraph is efficient but slightly hard to scan, which keeps it just below the top mark.

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

Completeness3/5

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

For a complex, high-stakes orchestration tool with no output schema and 0% schema coverage, the description covers execution policy, failure modes, approvals, and resume semantics well, but leaves a material hole: the shape of each action object in the required 'actions' array. An agent still has to guess per-step fields for click/fill/wait_for, which is the exact information needed to form a valid call.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must compensate, and it does partially: on_failure's 'continue' value is scoped to SAFE steps only, resume_from is defined as a checkpoint_id with re-inspection semantics, task_id is tied to prior needs_user results, and 'total timeouts' implicitly explains deadline_ms. However, the sole required parameter 'actions' is an untyped free-form object array with additionalProperties=true, and neither the schema nor the description says what fields each step needs (selector, text, URL, per-step timeout), leaving the primary parameter's structure undocumented.

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

Purpose5/5

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

States a specific verb and resource ('Execute a declared sequence of browser actions') plus a scope qualifier ('in ONE request') that cleanly separates it from the single-action siblings (hands_click, hands_type, hands_scroll). The enumerated action list (goto, click, fill, press, scroll, wait_for, verify_text, verify_url, screenshot) maps directly onto those siblings, so an agent can tell this is the batch/compound form without opening the schema.

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 explicit operational conditions: validate-then-execute, stop on first failure unless on_failure='continue' which is restricted to SAFE steps, and a precise rule for resume_from (re-inspect, never blindly replay, redacted steps need fresh text) and task_id (reuse the id from a prior needs_user result because scoped approvals bind to it). It never explicitly contrasts itself with calling hands_click/hands_type individually, which is the one missing alternative-selection cue.

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

Deploy Server