Skip to main content
Glama
Sign In
zen-browser

zen-browser

by grapedjuice
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

form_input

Set the value of browser form fields—including inputs, textareas, selects, checkboxes, radios, and contenteditable elements—by element reference to fill or update page forms.

Instructions

Set the value of an input, textarea, select, checkbox/radio or contenteditable element by ref.

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": {
      "ref": "<ref>",
      "value": "<value>"
    },
    "name": "form_input"
  }
}

Input Schema

NameRequiredDescriptionDefault
refYesElement reference from read_page/find, e.g. "ref_12".
tabIdNoTab to act on. Defaults to the active tab of the focused Zen window.
valueYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are supplied, so the description carries the entire behavioral burden, and it discloses very little. It does not say whether existing content is replaced or appended, whether input/change/blur events are dispatched (critical for React-controlled fields), what happens if the ref is stale or the element is not fillable, or whether the tab is focused first. For a mutation tool with zero annotation coverage this is a substantial gap.

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?

One sentence, front-loaded with the action and enumerating the element types compactly. There is no filler or redundant restatement of the tool name.

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

Completeness2/5

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

With no annotations and no output schema, an agent gets no signal about success/failure reporting, focus requirements, or event dispatch semantics for a write operation. The element-type enumeration covers breadth but leaves the behavioral contract of the call undefined, which is inadequate for a 3-parameter mutation tool.

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 67%, with `ref` and `tabId` documented in-schema and `value` (string | number | boolean) left undocumented. The description's "by ref" only restates the schema and the element-type list hints that value shape depends on the target (boolean for checkbox, option value for select), but it never makes that mapping explicit, so it adds little beyond the structured fields.

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?

The description gives a specific verb ("Set the value") plus the full set of supported element types (input, textarea, select, checkbox/radio, contenteditable) and the addressing mechanism ("by ref"). That is enough to distinguish it from read-only siblings like read_page, find, and get_page_text, though it never names an alternative explicitly.

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?

Usage is only implied: "by ref" hints the element must first be located via read_page/find, and the schema spells that out rather than the description. There is no statement about when to prefer this over the `computer` tool for typing/clicking, and no note on preconditions such as the element being visible, enabled, or in the focused tab.

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