Skip to main content
Glama
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

TableJSON 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