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

Annotations only cover the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=false). The description goes well beyond them: it discloses the return shape (draft_hash, release_rules), that unfinished drafts still save, that too-soon release dates come back in `warnings`, and that submission will refuse the release until changed. Missing auth/connection prerequisites beyond what the schema states, but the mutation-behavior story is unusually well told.

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?

Four sentences, front-loaded with the core action and the DRAFT qualifier before the return values and edge cases. Slightly prose-heavy ('goes nowhere until the artist says so', the parenthetical field list), but each sentence carries distinct information and nothing is pure 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?

There is no output schema, so the description correctly carries the burden of describing returns (draft_hash, release_rules, warnings) and the draft/submit lifecycle. For a 4-param tool with a nested `release` object, that is close to sufficient; the only real gap is that it doesn't restate which connection/artist context is required, which the schema covers.

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 75%, so the baseline is 3; the description adds only loose context for the `release` object ('release details', referencing the fields stores require) and does not explain the get_requirements field names, the 'send only what you are setting' semantics, or the draft_hash linkage. It neither compensates substantially for the gap nor misleads.

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 — 'Write the release details for a track or album as a DRAFT' — so the agent immediately knows this persists release metadata rather than submitting it. It is distinguishable from update_track/update_album by the DRAFT framing, but it never explicitly contrasts itself with those siblings (or with check_readiness/get_requirements, whose output it partially overlaps), so differentiation is implied rather than stated.

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?

'A draft costs nothing, can be changed and goes nowhere until the artist says so' implies the workflow context (use this before submission to stage metadata), and it notes the draft saves even when unfinished. However, it never says when to choose this over update_track, update_album, or get_requirements, and gives no exclusion conditions. Usage is inferable but not prescribed.

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