Skip to main content
Glama
Sign In
pironjulien

nexus-browser

by pironjulien
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

browser_batch

Destructive

Execute multi-step browser automation workflows in a single call. Chain sequence tools to handle filling forms, clicking buttons, and navigating pages automatically.

Instructions

Runs several NexusBrowser tools in order in ONE call (fewer round trips), and stops at the first error.

steps: [{"tool": "browser_fill", "args": {"locator": {"label": "Email"}, "value": "a@b.c"}}, {"tool": "browser_click", "args": {"locator": {"role": "button", "name": "Next"}}}, {"tool": "browser_wait_for", "args": {"text": "Welcome"}}] tab_id (optional) applies to every step that does not give its own. At most 30 steps; browser_batch cannot be nested. Each step goes through its own tool's checks: an outward gesture without the user's accord stops the batch with its accord_required refusal; after the user's yes, resend that step (with confirm and accord) and the rest. Response: one result per step run (tool, status, result), stopped_at (index of the failing step) if any; the images of capture steps (inline=True) are attached after it, in step order.

Input Schema

NameRequiredDescriptionDefault
stepsYes
tab_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

It provides critical operational details like the error-stopping mechanism, the specific handling of `tab_id` scoping, and the precise output structure (per-step results, `stopped_at`, and image attachments), none of which are covered by the annotations.

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?

While long due to the tool's inherent complexity, the definition is extremely well-structured. It follows a logical flow from high-level summary to specific constraints and execution details.

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?

Given the complexity of batch execution, the description is highly complete. It covers limits (max 30 steps), constraints (no nesting), operational quirks (accord), and the exact nature of the resulting output.

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

Parameters5/5

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

Given the highly generic schema (`additionalProperties: true`), the description is vital. It provides concrete examples of step arguments (e.g., defining 'locator' structures) and defines the functional scoping of the optional 'tab_id' parameter across all steps.

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?

The description clearly defines the tool's purpose: to execute several NexusBrowser tools sequentially within a single API call, distinctly setting it apart from sibling tools that execute single actions.

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

Usage Guidelines5/5

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

The description provides explicit workflow guidance, detailing that the batch stops at the first error and outlines complex usage scenarios like handling 'accord_required' refusals and re-sending steps.

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