manage_window

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

With no annotations, the description carries the behavioral burden and mostly succeeds: it explains the read behavior of get_rect, the mutating behavior of set_rect with the all-four-required constraint, and the state changes for maximize/minimize. It stops short of a 5 because it does not address side effects such as persistence or reversibility of window state changes.

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 cleanly organized into an opening sentence, a compact Args list, and a short Notes block. Each line contributes necessary information, and the action list is scannable without unnecessary prose.

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?

With an output schema present and all parameter semantics explained in the description, nothing critical is missing for invocation. The description also resolves the main contextual ambiguity by directing tab operations to manage_tabs.

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 description coverage is 0%, but the description fully compensates by defining every parameter: the four action enum values with their effects, and x, y, width, and height scoped to set_rect with the required-parameter warning. This adds all the meaning the schema lacks.

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 opens with 'Get or change browser window geometry or state' – a specific verb and resource – then enumerates each action. It also distinguishes itself from manage_tabs by noting that manage_tabs handles tab switching, so an agent can select this tool confidently.

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 Notes section explicitly states when to use this tool ('Use this tool for browser-window geometry and state') and names the sibling alternative ('Use manage_tabs for switching between browser tabs'). This is direct routing guidance rather than implied usage.

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