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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds user-facing behavior: inline player, real Download button, and live status for running jobs. It doesn't describe auth requirements or the returned object to the agent, but for a read-only display tool the added behavioral context is solid.

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 paragraphs, each earning its place: purpose, main usage condition, and the sibling for the alternative case. Front-loaded with the core description; 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 tool with one required parameter and no output schema, the description covers the key decisions: what it does, when to use it, and how it differs from the sibling. The only notable gap is the absence of details about the MCP response format, but given the tool's display purpose and read-only annotations, it is sufficient.

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?

The schema has zero description coverage for job_id, so the description must compensate. It does by explaining that the job is a video_gen/image_gen/voice job and that it can be running or done, giving a clear semantic anchor. It doesn't specify the format of job_id or how to obtain it, leaving some ambiguity, but the contextual mention of job types is meaningful.

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 action ('Display') and resource ('ONE finished generation') as a playable/downloadable card, and explicitly distinguishes from the sibling arsaze_show_generated_results. The description clarifies scope (one vs several) and even handles running jobs, so an agent can tell exactly what this tool does without opening the 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?

Gives an explicit 'use this instead of pasting a URL' rule for completed video_gen/image_gen/voice jobs, and explicitly names the alternative arsaze_show_generated_results for multiple results. Also clarifies behavior for running jobs. This is direct when/when-not guidance.

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