Skip to main content
Glama

fill

Enter values into input fields, text areas, checkboxes, toggles, and radio buttons to set a page's state for subsequent browser inspections.

Instructions

Type text into an input, text area or select an option from a element.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
uidYesThe uid of an element on the page from the page content snapshot
valueYesThe value to fill in. "true" or "false" for checkboxes and toggles, "true" for radio buttons.
pageIdYesTargets a specific page by ID.
includeSnapshotNoWhether to include a snapshot in the response. Default is false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/5.0
Behavior3/5

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

The description adds some behavioral context by specifying inputs, textareas, and select elements, which goes beyond the bare readOnlyHint=false annotation. However, it does not disclose whether existing content is overwritten, whether keystrokes are simulated, whether events are fired, or how checkbox and radio values are applied.

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 a single focused sentence that begins with the action and names the relevant resources. There is no filler, no repetition of schema details, and every word contributes to understanding the tool.

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

Completeness3/5

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

For a simple four-parameter tool with full schema coverage, an agent can likely invoke it correctly. However, the description lacks sibling differentiation, side-effect details, and behavior around existing values or snapshot responses, leaving some practical ambiguity.

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 description coverage is 100%, with all four parameters clearly described, including value semantics for checkboxes, toggles, and radios. The description itself adds little parameter-level meaning beyond naming the supported element types, so the baseline of 3 is appropriate.

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 states a concrete action ('Type text', 'select an option') and the target resources ('input', 'text area', '<select>'). It is clear about what the tool does, but it does not differentiate it from siblings like type_text or fill_form, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to prefer fill over type_text or fill_form, and no when-not-to-use or alternative tooling is mentioned. The supported element types imply some usage scope, but not enough to choose correctly among overlapping siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.