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

With no annotations, the description carries the full burden and mostly doesn't: read-only-ness is only implied by "check," and there is no mention of polling cadence, what statuses are returned, whether results disappear after completion, or what happens with an invalid or expired task_id. The one useful disclosure is that the response auto-includes detected tracks, MIDI, and chords.

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 short sentences, front-loaded with the action and followed by the one operational hint. Nothing is padded, though the brevity comes at the cost of the missing details noted above.

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?

There is no output schema and no annotations, so the description should explain return shape and status semantics; it only gestures at the contents (tracks, MIDI, chords). For an async status-polling tool with an undocumented kwargs parameter, this leaves an agent without enough to call it confidently.

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% for two required parameters, so the description must compensate and doesn't. task_id gets only "just pass task_id" with no format or origin, and the required "kwargs" string parameter is not mentioned at all, leaving an agent guessing what to supply.

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 verb and resource ("Check the status of a task") and adds scope by naming what the result covers: generated tracks, MIDI, and chords. It is clear enough to act on, but "task" is never tied to the audio-generation jobs implied by the sibling list, so an agent must infer the domain.

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?

"Just pass task_id" hints at polling an async job but gives no explicit when-to-use guidance, no prerequisite (that a job must have been submitted first), and no terminal-state behavior. It also fails to distinguish itself from the sibling check_service_status, which is the most likely source of confusion.

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