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

No annotations are provided, so the description carries the full burden. It discloses the required X-Mako-Key header, the optional-id behavior, the return contents (status and deliverable id), and the asynchronous 'once finished' nuance. It does not mention pagination, limits, or side effects, but for a status-check tool the key behaviors are covered.

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 sentences, each earning its place: purpose and behavior, return value plus downstream handoff, and authentication requirement. The key information is front-loaded and there is no filler.

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 no output schema and no annotations, the description is quite complete: it covers the two modes of use, the return value, the downstream tool, and an auth requirement. It could be more explicit about what 'most recent of both' returns structurally, but the essential call-and-response logic is present.

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%, so the baseline is 3. The description adds context that the id corresponds to either a report order or a May run, but the schema already says this. The client_account_id parameter's meaning is fully covered by the schema and adds nothing beyond it in the description.

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 action ('Check') with a clear resource ('one report order or one May run by its id'), and distinguishes the omitting-id listing behavior. It also explicitly routes the returned deliverable id to get_download_url, setting it apart from siblings like list_deliverables and get_download_url.

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 gives clear conditions for use: provide an id for a single status check, or omit it to list the most recent items. It also indicates the follow-up tool (get_download_url). It does not explicitly discuss when not to use the tool versus list_deliverables or other siblings, but the main usage context is clear.

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