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

Annotations already declare read-only/idempotent/non-destructive, so safety is covered; the description adds non-obvious behavior: 24-hour expiry of sessions and images, the need to request a fresh upload when expired, and the guidance to reuse URLs without downloading, re-encoding, or copying. It also discourages polling, which is a real invocation trait not captured anywhere in structured fields.

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?

Front-loaded with what is returned, then usage rules, then expiry and URL-reuse guidance — every sentence carries actionable content. It runs five sentences and is dense, but no sentence is redundant; slightly tighter grouping would make it scannable faster.

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?

There is no output schema, yet the description names the return payload (native previews, original URLs, expiry times) and covers lifecycle (24h expiry, refresh path) and downstream consumption rules. Nothing an agent needs to call this correctly and interpret results is missing.

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 coverage is 0% and the schema only declares a uuid-typed session_id with no meaning attached. The description supplies the crucial semantics: the parameter is optional, omitting it triggers a fallback discovery of recent unexpired sessions on the account, and the agent must select the matching session. It stops short of stating the expected format, which the schema already implies.

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?

"Retrieve uploaded images as native image previews plus original generation URLs and expiry times" gives a specific verb, resource, and return content in one clause. It is clearly distinguishable from upload_image and open_upload_panel siblings, which imply writing/opening rather than reading.

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?

Explicit sequencing ("Call after the user finishes uploading, not in a tight polling loop"), an alternative discovery path ("Omit session_id to find recent unexpired sessions... if the session ID was lost"), and a disambiguation rule ("choose the session matching the user request, never silently mix unrelated uploads"). It also names the downstream use ("Inspect the previews before describing the image or writing a prompt").

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