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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds real behavioral value beyond them: it discloses what a successful response contains and what 'wait: true' actually does (~50 s block). It does not describe failure/timeout behavior or the possible status values, which keeps it short of a 5.

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 dense sentences plus an endpoint reference, with the return contents and the wait behavior front-loaded. Slightly clipped grammar ('A song or edit job: its status...') costs a point but nothing is redundant.

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?

With no output schema, the description carries the return-value burden and does so reasonably: status, clips, ids, titles, lyrics and m4a/wav links. Missing only edge cases such as timeout behavior, error shapes, and the enumerable status values.

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 100%, so both parameters already have descriptions. The description essentially restates the 'wait' semantics from the schema ('waits up to ~50 s for it to finish') and adds nothing about the jobid format. Baseline 3 applies when the schema does the heavy lifting.

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 names the resource (a song or edit job) and what is returned (status, and once completed, clips with ids, titles, lyrics, and audio links), plus the endpoint GET /jobs/{jobid}. That is enough to separate it from flowmusic_list_jobs and flowmusic_cancel_job, though the phrasing is telegraphic rather than a clean verb+object sentence.

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?

Usage is only implied: you call this to poll a job's status once you have a jobid. There is no explicit guidance on when to use it instead of flowmusic_list_jobs, no polling cadence advice, and no statement of what to do if the job has not finished after the ~50 s wait.

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