preview_image_task

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description usefully adds that nothing is fetched from the backend, no credits are spent, and that host UI support is mandatory with original links required. However it does not explain what the preview card returns or the load/error/retry state semantics of those controls. With annotations carrying the safety profile, this is solid added context but not exhaustive behavioral disclosure.

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?

Purpose and card contents are front-loaded in the first sentence, with sequencing and exclusions following. Every clause carries information, though the dense packing of four separate behavioral claims into the second sentence slightly reduces readability.

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 one-parameter, read-only presentation tool with no output schema, the description covers the trigger, the exclusions, the host UI requirement and the need to provide original result links. An agent has everything it needs to decide to call it and to set expectations for the caller.

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?

There is a single parameter (request_id) with 100% schema description coverage, so the schema already documents its purpose, pattern and retry reuse semantics. The description adds nothing about the parameter, which is acceptable under the high-coverage baseline but earns no extra credit.

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?

States a specific verb and resource ('Show already generated images ... in a read-only preview card') and immediately scopes it against the obvious alternative by declaring it does not query the backend. An agent can distinguish it from get_image_task, preview_audio_task and preview_video_task without opening any schema.

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?

'Call after get_image_task returns images' gives an explicit precondition and ordering relative to the retrieval sibling. It also lists when-not conditions (no backend query, no media download, no generation submission, no credit spend) and a host-environment prerequisite plus the obligation to supply original links.

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