analyze_audio_files

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

With no annotations, the description must carry the behavioral burden. It does so by explaining that measurements are taken from source files on disk, hence pre-FX and pre-fader, and that the whole_file parameter changes the analysis scope. It also indicates the return shape (JSON with per-item analysis, warnings, skipped items). This gives an agent a clear sense of what happens when the tool runs, beyond a simple read operation.

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: a one-sentence purpose, a short paragraph clarifying the measurement source, a bulleted Args list, and a Returns line. Every part earns its place, and the most important scoping caveat (pre-FX) is front-loaded. It is detailed without being verbose.

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 moderately complex analysis tool with no output schema, the description covers the purpose, all parameters, and the essential behavioral context. It hints at the return structure but does not specify the exact fields within the per-item analysis (e.g., peak, RMS). This is a minor gap; the description is otherwise sufficient for an agent to call it correctly.

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%, but the description's Args section fully compensates. It explains each parameter: project_path ('Path to .RPP file'), track_filter ('Optional substring to filter track names'), and whole_file ('Analyze entire source files instead of only the region each item actually plays. Off by default.'). This is thorough, clear, and adds semantic meaning the schema lacks.

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 a clear verb-resource combination: 'Analyze audio in a Reaper project for mixing feedback.' This directly distinguishes it from siblings like find_reaper_projects (finding projects), parse_reaper_project (parsing structure), and list_installed_fx (listing FX). The purpose is specific and actionable.

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?

The description provides no explicit when-to-use guidance or alternative routing. It does not mention that for project structure one should use parse_reaper_project, or that for finding projects one should use find_reaper_projects. The pre-FX note implies a constraint but does not state 'use this when you need pre-FX analysis' or list alternatives. This leaves the agent to infer when to select this tool.

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