logic_export

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

With no annotations, the description carries the full burden. It usefully discloses that bounce/stems write audio to disk and get verified, that options changes nothing, and that dismiss is a safe dialog closer. It does not cover overwrite behavior, where files land (directory/filename), long-run timeout behavior, or failure modes for a file-writing tool.

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?

Front-loaded summary sentence, then a compact per-action list with no filler. The list blends usage guidance with parameter syntax, which slightly muddies scanning, but nothing is wasted.

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 12-parameter, no-annotation, no-output-schema tool, the description covers action semantics and the most common render settings, but omits filename, directory, include_tail, and timeout, and gives no sense of what is returned beyond the implied on-disk verification.

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 0%, so the description must compensate, and it does for over half the parameters: formats with an example, start_bar/end_bar range limiting, plus concrete formats for sample_rate ('44.1 kHz'), bit_depth ('24-bit'), normalize ('Off'), and mode ('Offline'). It leaves timeout, filename, directory, and include_tail unexplained.

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 concrete verb+resource ('Render audio out of Logic and verify it landed on disk') and then enumerates the four actions, each with a distinct meaning (bounce, stems, options, dismiss). An agent can tell exactly what capability this covers versus the other logic_* siblings.

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?

Each action gets a use case: bounce for one-pass multi-format renders, stems for per-track files and explicitly 'the input for level analysis' (routing to logic_level), options as a read-only settings check, dismiss as an escape hatch. No explicit when-not-to-use or alternatives, but the context is clear.

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