Skip to main content
Glama
Sign In
pironjulien

nexus-browser

by pironjulien
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

browser_fill_form

Destructive

Fill multiple form fields in one ordered call with trusted input, then read back every field to verify values; stops at the first unconfirmed field and never submits.

Instructions

Fills several fields in ONE call, in order, with the same gestures as browser_fill, browser_select_option and browser_check (trusted typing), then READS BACK the whole form without any gesture. Each field: "mark" (number from browser_interactive_map, call it first) and one value: "value" (text), "option" (visible text of a option) or "checked" (true/false). E.g. [{"mark": 1, "value": "Marie"}, {"mark": 4, "option": "Lille"}, {"mark": 6, "checked": false}]. Everything is validated before the first gesture. Stops at the first unconfirmed field (error, dialog open, value refused or reset by the page): the following ones are not touched. After the last gesture, each field (the same element, by its mark) is read back: all_verified=true only if ALL still hold the wanted value. Never submits the form: the submit button stays a browser_click.

Input Schema

NameRequiredDescriptionDefault
fieldsYes
tab_idYesYour tab's id (from browser_new_tab, or a tab adopted with browser_adopt_tab).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.31.6
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "browser_fill_formOutput",
-  "type": "object"
-}New value: +null
  2. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the annotations (destructive/non-idempotent/openWorld) by disclosing pre-validation of everything before the first gesture, fail-fast semantics at the first unconfirmed field, and a post-gesture read-back whose all_verified flag is true only if all values persist. That partial-failure and verification behavior is exactly what an agent needs and annotations cannot express.

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?

Front-loaded with the action, then mechanics, then failure behavior, then the submit exclusion — and the inline example earns its place by clarifying the field object shape. No filler sentences.

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?

With no output schema, the description still communicates that verification results come back per field and exposes the all_verified signal, but it doesn't sketch the actual response shape (per-field statuses, error fields). Sufficient to call correctly, slightly thin on what to expect back.

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?

The schema leaves 'fields' as an undescribed array of free-form objects, so the description carries the load: it defines the per-field 'mark' key and the mutually exclusive value forms 'value'/'option'/'checked', plus a concrete three-element example. This is a real compensation for the 50% schema coverage.

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 ('Fills several fields in ONE call, in order') and explicitly frames it as the batch equivalent of browser_fill, browser_select_option and browser_check, so an agent can distinguish it from those siblings immediately.

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?

Guidance is clear: multiple fields in one call, requires marks from browser_interactive_map ('call it first'), and the exclusion 'Never submits the form: the submit button stays a browser_click' routes the agent correctly. It doesn't explicitly say when to fall back to the single-field siblings, which keeps it from a 5.

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