nodriver-mcp-server

Overview Schema Source Related Servers Discussions Admin

Fill input

fill

Replace input, textarea, select, or contenteditable content with a new value, triggering input events for React/Vue. Verifies the value landed, returning an error if not.

Instructions

Set the value of an input, textarea, select or contenteditable element.

Selects whatever is already in the field and types over it, character by character, so input events fire and React/Vue-style controlled components register the change. It deliberately does not blank the field first: that makes such components re-render, the focus follows the replaced node, and the keystrokes end up nowhere. For , the option is chosen by value and a change event is dispatched.

The value is read back afterwards. If it did not land you get an error, not a success you cannot trust — a field can be read-only, disabled, covered by an overlay, or rewrite what you type, and silently reporting success would send you looking for the problem several steps later.

Use type_text instead when you want to append to a focused field rather than replace its contents. For several fields at once, fill_form does it in one round trip.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`uid`	Yes	Element uid from the most recent take_snapshot, e.g. "4_12". uids are invalidated whenever the page changes — if you get "unknown uid", take a fresh snapshot and retry with the new uid.
`value`	Yes	The text to enter. For a <select> element this must match the option's value attribute, not its visible label.
`browser`	No	Which browser to act on. Each name is an independent Chrome, created on first use. Omit for the shared default; parallel agents each need their own name.	default
`include_snapshot`	No	Append a fresh page snapshot to the response. Worth it when this action changes the page and take_snapshot would be your next call anyway — it saves a round trip, at the cost of a much larger response.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv2.5.0Sep 25, 2026

addedInput schema / properties / browser

Added value: +{
+  "default": "default",
+  "description": "Which browser to act on. Each name is an independent Chrome, created on first use. Omit for the shared default; parallel agents each need their own name.",
+  "type": "string"
+}

First observedv1.7.2Aug 7, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the annotations, the description reveals the type-over mechanism, input-event firing for controlled components, the deliberate avoidance of blanking the field first, select change dispatch, and a post-condition read-back that errors on failure. It also explains external complications like overlays or read-only fields. No contradiction with the annotations.

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 detailed but every sentence earns its place: mechanics, rationale, failure behavior, and routing to alternatives are all distinct and purposeful. It is front-loaded with the core action and structured logically.

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

Completeness5/5

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

Given the output schema and fully described parameters, the description covers use cases, failure modes, parameter caveats, and sibling routing. An agent has everything needed to invoke fill correctly and interpret unexpected outcomes.

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 all parameters at 100%, so the baseline is 3. The description adds useful behavioral meaning around how the value is entered and verified, and reinforces the select value-vs-label nuance, elevating it slightly beyond the schema alone.

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 opens with a specific verb and resource: 'Set the value of an input, textarea, select or contenteditable element.' It clearly differentiates itself from siblings by stating it replaces the field contents, and explicitly contrasts itself with type_text and fill_form.

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

Usage Guidelines5/5

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

The description explicitly says when to use type_text instead (append to a focused field) and when to use fill_form (several fields at once). It also provides context about uid freshness and failure modes, giving the agent actionable guidance on when this tool is appropriate.

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

Deploy Server