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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior. The description adds meaningful context beyond that: the response is signed URLs with a one-hour validity window, and the caller is restricted to a specific calendar widget. It does not discuss failure modes or rate limits, but the key behavioral traits are disclosed.

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?

Three short sentences, front-loaded with the core capability and validity window, followed by the caller restriction and a related tool. Every sentence earns its place, including the unusual 'Agents never call it' warning.

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 tool has a simple single-parameter schema, full schema description coverage, an output schema, and full annotation coverage. The description adds the one-hour signed URL behavior and caller restriction, so an agent has everything needed to know it should not be used. Nothing material 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?

There is one required parameter, assetIds, and schema description coverage is 100%, so the schema already defines the array of image asset ids. The description mentions image assets generally but adds no syntax, limits, or interpretation beyond what the schema provides. Baseline 3 applies because the schema carries the parameter documentation.

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 resource (image assets) and return type (signed URLs valid one hour), and explicitly distinguishes this tool from nearby tools like get_asset and get_calendar by saying only Mark's calendar widget calls it and agents never call it. An agent can immediately tell what it does and that it is not the general asset-fetch tool.

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 gives explicit when-to-use guidance: only Mark's calendar widget calls this to draw thumbnails, and 'Agents never call it.' It also names a related tool, get_calendar, which helps route the agent elsewhere. The exclusion is unusually direct.

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