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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that it returns processing state and creative_asset_id, but it does not clarify whether this is a read-only poll, how long uploads may remain in processing, what error conditions might occur, or whether the returned creative_asset_id is always present only after processing completes. This is a meaningful gap for an async status 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 with no filler. The first sentence states the action and resource, and the second sentence states the return value. This is appropriately sized and front-loaded.

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?

This is a simple one-parameter polling tool, but with no output schema and no annotations, the description is thin. It lacks guidance on when the status is 'complete', how to interpret states, how to obtain job_id, and whether the creative_asset_id is production-ready. A minimal viable description for an async poller should include at least the status values or a pointer to the upload tool.

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 0%, so the description must compensate. It names no parameter details beyond the schema's job_id definition. Since there is only one parameter, a UUID, the schema already conveys the basic meaning. The description adds the context that job_id refers to an async upload job, but it does not explain how to obtain the job_id or how it relates to sibling upload tools.

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 uses a specific verb ('Check') with a clear resource ('status of an async video upload') and distinguishes this status-check operation from other status tools by naming the async video upload context and the returned 'creative_asset_id'. It clearly tells an agent what this tool does.

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 implies the tool should be used after initiating an async video upload, by mentioning 'async video upload' and 'Returns processing state'. However, it does not provide explicit when-to-use guidance or name alternatives like adsap_get_import_status or adsap_get_ad_review_status, so the agent must infer the exact workflow context.

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