Skip to main content
Glama
Sign In
Silbercue

Public Browser

by Silbercue
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

fill_form

Fill entire web forms in one call: text, select, checkbox, radio fields. Each field reports its own status; on errors, view the page and retry only failed fields.

Instructions

Fill a whole form in one call: text inputs, (by value or visible label), checkboxes (boolean) and radio buttons. One round-trip; partial errors do not abort and each field reports its own status. On per-field errors call view_page and retry the failing fields.

Input Schema

NameRequiredDescriptionDefault
fieldsYesEach needs ref or selector plus value

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv2.10.5
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedInput schema / properties / fields / description
      Previous value: -"Array of fields to fill. Each field needs ref or selector plus value."New value: +"Each needs ref or selector plus value"
    • removedInput schema / properties / fields / items / additionalProperties
      Removed value: -false
    • changedInput schema / properties / fields / items / properties / ref / description
      Previous value: -"A11y-Tree element ref (e.g. 'e5') — preferred over selector"New value: +"Element ref (preferred)"
    • changedInput schema / properties / fields / items / properties / selector / description
      Previous value: -"CSS selector (e.g. '#email') — fallback when ref is not available"New value: +"CSS selector (fallback)"
    • changedInput schema / properties / fields / items / properties / value / description
      Previous value: -"Value to set: string for text/select, boolean for checkbox/radio, number coerced to string"New value: +"string for text/select, boolean for checkbox/radio; number → string"
  2. First observedv2.7.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 carries the full burden, and it delivers meaningful behavioral details: one round-trip, partial errors do not abort, each field reports its own status, and select values can be supplied by value or visible label. These traits go beyond a generic 'fill form' description, though side effects or clearing behavior are not addressed.

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?

The description is three tight sentences with no filler. The scope and supported input types are front-loaded, followed by behavioral guarantees and the error-retry instruction. Every clause earns its place.

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?

For a single-parameter tool with no annotations and no output schema, the description gives enough to invoke the tool correctly and recover from failures. It covers supported element types, value semantics, non-aborting partial failures, and a retry path. The only notable gap is the exact shape of per-field status reporting.

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?

The schema already covers parameter structure with 100% description coverage, so the baseline is 3. The description adds value by explaining type-to-control mapping: booleans for checkboxes/radio buttons, string for text/select, and select matching by value or visible label. This clarifies semantics beyond the raw schema.

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 states a specific action ('Fill a whole form in one call') and enumerates the supported input types: text inputs, select, checkboxes, and radio buttons. It distinguishes fill_form from siblings like click and type by emphasizing the batch, one-round-trip behavior.

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?

The description conveys when to use the tool: for filling an entire form in one call rather than field-by-field typing/clicking. It also gives an explicit recovery path for per-field errors: call view_page and retry failing fields. It stops short of listing scenarios where fill_form should not be used, but the guidance is still actionable.

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