get_image

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

With no annotations, the description fully carries behavioral disclosure. It states what is returned (image plus caption/description/page metadata), explicitly warns that non-image refs produce an error record, and explains the fallback behavior with `available_images` and closest-first ordering. This is rich edge-case disclosure for a simple tool.

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-load the core action and then pack in return metadata, the image-segment constraint, and error behavior without fluff. Every clause earns its place, and the structure is easy for an agent to parse.

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 single-parameter tool with no output schema and no annotations, this description is unusually complete: it covers input provenance, valid input type, return contents, and invalid-input behavior. There is no missing information that an agent needs to invoke it correctly.

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%, and the schema already documents that `refs` are opaque tokens from search/lookup/get_segments of image segments and that non-image segments return an error record. The description largely restates this, adding no meaningful parameter-level meaning beyond the schema.

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 and resource: 'Fetch datasheet figure images (PNG/JPEG)' for opaque `ref` tokens. It clearly distinguishes this from siblings by scoping it to image segments and by naming the source tools (search/lookup/get_segments) rather than describing general segment retrieval.

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?

It states that refs must come from search/lookup/get_segments and that only `type='image'` segments have image data, giving an explicit when-to-use boundary. It does not name an alternative tool for non-image segments, but the error behavior makes the intended use clear.

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