Skip to main content
Glama
Sign In
zen-browser

zen-browser

by grapedjuice
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

javascript

Run scripts in a browser tab and return the last expression as JSON-able output for debugging and inspecting pages, with DOM access and window.wrappedJSObject for page globals.

Instructions

Run JavaScript in the tab and return the value of the last expression (top-level await works). Runs in the extension's isolated world with full DOM access; reach page globals via window.wrappedJSObject. Return JSON-able values. For debugging and inspection, not for faking user input.

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": {
      "code": "<code>"
    },
    "name": "javascript"
  }
}

Input Schema

NameRequiredDescriptionDefault
codeYes
tabIdNoTab to act on. Defaults to the active tab of the focused Zen window.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description shoulders the full burden and does real work: execution happens in the extension's isolated world with full DOM access, page globals require window.wrappedJSObject, top-level await is supported, and returns must be JSON-able. It does not mention timeouts, error/exception behavior, or that arbitrary code execution can mutate page state.

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 tight clauses: what it does, the execution context caveats, and the usage restriction. The primary action is front-loaded, and every sentence adds distinct information with no filler.

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

Completeness4/5

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

No output schema exists, so the description correctly explains the return value; execution-context and usage boundaries are also covered. For an arbitrary-code-execution tool the remaining gap is error surface and side-effect/permission disclosure, which an agent would benefit from knowing.

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 only 50%: tabId is documented in the schema, but 'code' has no schema description. The description compensates by explaining that code is an expression whose final value is returned, that top-level await works, and that results must be JSON-able — meaningful semantics the schema alone would not supply.

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 ('Run JavaScript in the tab') plus an explicit return contract ('return the value of the last expression'). The closing clause distinguishes it from siblings like computer/form_input by ruling out input simulation, so an agent can place it without reading other schemas.

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 a clear use case ('debugging and inspection') and an explicit exclusion ('not for faking user input'), which steers toward computer/form_input. It stops short of naming the alternative tools outright or describing when page-text/console-reading siblings are preferable.

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