see_image

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

With no annotations, the description takes on the full burden. It transparently discloses accepted input formats (local paths, URLs, base64 strings), explicitly states the return type ('The vision model's answer as plain text'), and gives concrete examples. It does not discuss rate limits, authentication, or error behavior, but for a read-only vision tool this level of disclosure is reasonably informative.

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 well-structured with a one-sentence summary, a usage guideline, clearly labeled Args and Returns sections, and three illustrative examples. Every section earns its place without redundancy or filler. It is concisely written while still providing rich detail.

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?

For a two-parameter tool with an output schema, the description is nearly complete: it covers input formats, default values, return type, and examples. It does not discuss potential limitations (e.g., file size limits, unsupported image types) or offer specific guidance for choosing among sibling vision tools, which would round it out. Given the tool's simplicity, this is a minor omission, hence a 4.

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?

Despite the schema's low coverage (0%), the description substantially enriches both parameters. For 'image' it specifies three accepted formats (file path, URL, base64 with or without data-URI prefix) and for 'question' it clarifies semantics and provides a default. This goes far beyond the schema's bare 'string' type, fully compensating for the coverage gap.

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 a specific verb-resource pair ('Look at an image and answer a question about it') and immediately positions it as the 'core vision tool' for understanding, describing, or reasoning about visual content. This clearly distinguishes it from sibling tools like extract_text (text extraction) and analyze_chart (chart analysis), even though it does not name them explicitly.

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 offers clear context: 'Use it whenever you need to understand, describe, or reason about visual content that you cannot see.' This tells the agent when to invoke the tool, but it does not provide explicit when-not-to-use scenarios or mention alternative tools by name. Thus it misses the 'explicit exclusions/alternatives' bar for a 5 but is strong enough for a 4.

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