Browser screenshot

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

Annotations already mark this as non-readable, destructive, non-idempotent, and not open-world. The description adds useful behavioral context beyond those flags: output is written to files and the operation is 'opt-in' and 'prompts,' meaning user approval may be required. It does not describe overwrite behavior, but the destructive annotation already covers that risk.

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 extremely short and front-loaded: the core action comes first, followed by two important constraints. Every word earns its place and there is no redundant phrasing or restating of the tool name.

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?

Given the output schema exists and annotations cover safety, the description is minimally viable: it states purpose, output type, writable-path constraint, and prompting behavior. However, with four parameters and zero schema descriptions, an agent still lacks details about URL handling, dest path rules, width, and timeout behavior, so completeness is only average.

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%, and the description does not compensate. It only hints that dest must be in writable roots; it gives no guidance on URL format, dest naming/extension, width semantics, or timeout_seconds behavior. Without parameter descriptions, an agent must rely on titles and defaults alone, which is insufficient for confident invocation.

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?

Clearly states a specific action and result: 'Screenshot page to PNG.' It also adds a unique constraint, 'in writable roots,' which helps distinguish it from browsing/fetching siblings like browser_fetch or fetch_text. The verb+resource+output format removes ambiguity about what the tool does.

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 description conveys when to use this tool: whenever a visual PNG screenshot of a page is needed, with the constraint that output must go to writable roots. It does not explicitly name alternatives or say when not to use it, but it provides enough context for an agent to route correctly against fetch-type siblings.

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