View image or screenshot

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

The description discloses a key behavioral trait: 'These operations return pixels without interacting with the visible UI', which is useful beyond the annotations. However, it claims capture of 'one window, monitor, or region' while the input schema for take_screenshot only exposes keep and directory parameters, leaving a behavioral promise the schema does not support. Annotations are all false and provide no additional coverage.

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?

Two sentences, front-loaded with the key selection criterion ('when the result must be pixels'), and zero filler. The alternative and exclusion are stated efficiently in the second sentence.

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?

The discriminated-union schema and output schema provide good structural coverage, and the description supplies overall context. However, the description overpromises window/monitor/region capture that is not reflected in the schema, creating a serious mismatch an agent must resolve before calling the tool correctly. This gap makes the definition not fully complete for its complexity.

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 100%, so the baseline should be 3cars, but the description actively adds misleading meaning by mentioning 'one window, monitor, or region' capture when no schema parameter supports selecting those targets. It does not clarify how the operation discriminates between read_image and take_screenshot beyond the fixed operation enum, and the unsupported target claims could cause an agent to pass invalid parameters.

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 states a specific purpose: 'Use this when the result must be pixels from this computer', and enumerates the exact operations (read an existing image or capture desktop/window/monitor/region). It distinguishes itself from siblings by emphasizing pixels and the alternative control_computer for semantic structure or actions.

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 gives explicit when-to-use guidance ('when the result must be pixels') and names the clear alternative ('Use control_computer when semantic structure or an action is enough'). It also adds context that these operations do not interact with the visible UI, helping an agent choose correctly.

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