Skip to main content
Glama
Sign In
zen-browser

zen-browser

by grapedjuice
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

computer

Perform mouse and keyboard actions in a browser tab: click coordinates or element refs, type text, press keys, scroll, wait, take screenshots, and zoom regions for detailed inspection.

Instructions

Mouse and keyboard actions in a tab. Click actions take either a coordinate (from the latest screenshot) or a ref. Actions: left_click, right_click, double_click, triple_click, hover, type (text into the focused element), key (space-separated keys like "Enter", "ctrl+a", "Backspace Backspace"), scroll, scroll_to (ref), wait, screenshot, zoom (region of the screenshot at higher detail).

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": {
      "action": "<action>"
    },
    "name": "computer"
  }
}

Input Schema

NameRequiredDescriptionDefault
refNoElement reference from read_page/find, e.g. "ref_12".
textNoText for type, or keys for key.
tabIdNoTab to act on. Defaults to the active tab of the focused Zen window.
actionYes
regionNo[x0, y0, x1, y1] for zoom, in screenshot pixels.
durationNoSeconds to wait (wait action).
coordinateNo[x, y] in screenshot pixels.
scroll_amountNoScroll ticks (default 3).
scroll_directionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It does disclose the targeting model (latest screenshot coordinates or refs) and the key-string format, but says nothing about whether clicks commit irreversible actions, focus requirements, the tabId default's effect on the Zen window, or what each action returns.

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

Conciseness3/5

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

Front-loaded with the core purpose, which is good, but it is a single long sentence whose action list largely restates the enum in the schema. The parentheticals for type, key, and zoom are the parts that earn their place; the bare enum repetition does not.

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 9-parameter, multi-mode interaction tool with no annotations and no output schema, the description covers input targeting but not outcomes. An agent still cannot tell whether screenshot returns an image, whether wait blocks, or how failures on a missing ref surface.

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 coverage is 78%, so the schema already documents most parameters. The description adds real value for text/key syntax and for the coordinate-vs-ref choice, but leaves duration, scroll_amount, scroll_direction, and region semantics entirely to the schema.

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 concrete verb set (mouse and keyboard actions) and resource scope (in a tab), then enumerates all twelve supported actions, which lets an agent recognize it apart from navigate, read_page, and get_page_text. It does not distinguish 'type' from the sibling form_input, which is the one overlapping boundary.

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

Usage Guidelines3/5

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

Gives useful preconditions rather than exclusions: clicks need a coordinate from the latest screenshot or a ref from read_page/find, and key uses space-separated key syntax. However, it never says when to prefer this tool over form_input for text entry, or when to use the built-in screenshot action versus the sibling screenshot tool.

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