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

With no annotations provided, the description carries the full disclosure burden and does explain the rendering algorithm (scans all note/audio regions, finds the latest ending point, renders from beat 0 plus a configurable tail) and the return payload (WAV path, duration, peak, has_audio). It stops short of disclosing operational traits like whether the output file overwrites existing files or whether the audio engine must be running.

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?

The description is well-structured and front-loaded: lead purpose statement, algorithm detail, pipeline context, parameter list, return list, and two compact examples. There is slight redundancy between 'auto-detects song length from all regions' and the following sentence that re-describes the scanning, but nothing is wasted or off-topic.

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?

Given that all parameters are optional, an output schema exists, and this is a simple render operation, the description covers everything needed for correct invocation: purpose, algorithm, parameters, returns, and a pipeline example. Its main gap is not explicitly distinguishing the closely named siblings render_full and render_full_format, which could cause selection confusion among the large sibling set.

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 0% description coverage, so the inline parameter documentation is essential and fully compensates: filename (specified without .wav extension), sample_rate (export rate, default 48000), and tail_beats (extra beats for reverb/delay tails, default 4 = 1 bar). The two examples further demonstrate parameter usage, making all three parameters clear despite the bare schema.

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 opens with 'Render the entire project — auto-detects song length from all regions,' which states a specific verb (render), resource (entire project), and a distinguishing scope (auto-detection across all regions). This clearly differentiates it from nearby siblings like render_range and export_mix, which target specific ranges or export formats rather than full-project rendering.

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 context is explicit: 'after create_song_with_variations (or any arrangement tool), call render_full_song to get the final WAV,' and the phrase 'No manual beat counting needed' implies an advantage over range-based alternatives. However, it never names direct alternatives (render_range, render_full, export_stems) or states when NOT to use this tool, so exclusion conditions are absent.

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