browser_type_text

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

With no annotations provided, the description carries full burden and excels at disclosing behavioral mechanics: it focuses elements, optionally clears content, sets values, and specifically notes dispatching of 'input and change events' to trigger listeners. Missing error behavior (e.g., selector not found) or return value details prevents a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with the critical '[Disabled]' status front-loaded. The single sentence that follows packs multiple behavioral clauses (focus, clear, set value, dispatch events) with zero redundancy. Every phrase earns its place.

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

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

While the disabled status and input mechanics are well-documented, the description lacks information about return values, error handling (e.g., invalid selectors, closed tabs), or timeout behavior—gaps that are significant given this is a browser automation tool with no output schema provided.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, establishing a baseline of 3. The description adds value by contextualizing the selector parameter (must match input/textarea), explaining the clear parameter's effect ('optionally clears existing content'), and clarifying that text is 'entered into the element' (value setting vs key simulation).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool types text into 'input field or textarea' (specific resource) using a CSS selector, and distinguishes itself from siblings like browser_press_key (key events) or browser_select_option (dropdowns) by emphasizing value-setting and event dispatching. The '[Disabled]' prefix immediately signals availability status.

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

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

The '[Disabled]' prefix provides critical usage constraints (do not invoke). It implicitly guides usage by restricting to 'input field or textarea' element types. However, it does not explicitly name alternatives like browser_press_key for character-by-character input or clarify when to use clear=true vs false.

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