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

With no annotations, the description carries the full burden. It discloses that findings are suggestions, not directives, and emphasizes subjectivity and artistic intent. This adds important context beyond the raw operation, though it doesn't mention return format or whether it modifies anything (which is likely read-only but not stated).

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 three sentences, each earning its place: purpose, invocation constraint, and interpretational guidance. It is front-loaded and free of repetition or fluff.

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 zero-parameter tool with no output schema, the description is complete. It explains what the tool does, when to invoke it, how to frame results, and the subjective nature of mix quality, fully covering the behavioral and usage context.

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 tool has zero parameters, so the baseline is 4. The description adds no parameter-specific details, but none are needed since the schema is empty and fully covers the parameter set.

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 clearly states the tool runs rule-based heuristic analysis for specific mix issues (frequency buildup, dynamics problems, routing inefficiencies, headroom), using a specific verb and resource. It effectively distinguishes its purpose as a comprehensive mix analyzer rather than a single-purpose spectral tool.

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?

Explicit when-to-use guidance is provided: 'Only call when the user explicitly asks for mix feedback or describes a specific problem — do NOT call proactively.' However, it does not name alternative tools or explicitly differentiate from siblings like get_spectral_snapshot, so it misses the 'alternatives' part of a 5.

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

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

With no annotations, the description carries the burden of disclosure. It makes the mutation explicit ('Creates') and adds a human-approval requirement. However, it does not disclose whether existing tracks are moved or copied, what happens to their original placement, or whether the operation is reversible.

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 two concise sentences. It front-loads the core purpose and then adds the key workflow requirement. Every word earns its place with no repetition of schema content.

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 simple two-parameter creation tool, the description adequately covers the purpose and the critical approval step. It lacks details on edge cases or return values, but no output schema exists and the operation is straightforward enough that this is not a major gap.

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 100% and both parameters (group_name, track_names) are already described in the schema. The description does not add parameter-level details beyond what the schema provides, so it meets the baseline but adds no extra semantic value.

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 uses a specific verb ('Creates') and resource ('a new group track'), clearly stating the input tracks are contained in it. This differentiates it from sibling tools like set_track_routing, which route but do not create group tracks.

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 implies use when a group track needs to be created, and adds a mandatory workflow guideline ('Always confirm with the producer first'). However, it does not explicitly state when not to use it or mention alternatives, so the guidance is present but not comprehensive.

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

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

No annotations are provided, but the description's explicit 'Returns' wording clearly signals a read-only operation. It lists the specific output fields, giving insight into what the tool does, though it doesn't explicitly state that no state is modified or mention any prerequisites or failure conditions.

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 compact, consisting of two sentences: the first precisely enumerates the returned metrics, and the second states the intended use. Every phrase adds value, and it avoids repeating schema information.

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 its simplicity (no params, no output schema), the description fully explains what the tool returns and why to use it. It names specific metrics and a diagnostic purpose, which is sufficient for an agent to select and invoke the tool.

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 tool has zero parameters and the schema has no properties, so the baseline is 4. The description correctly focuses on the output and use case, and no parameter explanation is needed.

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 uses the active verb 'Returns' and specifies the resource 'performance metrics from the M4L bridge device,' listing concrete metrics such as poll execution time, WebSocket message size, LiveAPI cache size, and track count. This clearly distinguishes it from sibling tools like get_track_details and get_session_context, which focus on different domains.

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?

It explicitly states 'Use to diagnose performance issues or confirm the device is running efficiently,' providing a clear usage context. However, it doesn't mention when not to use it or name alternatives, though this is not critical for a read-only health check with no parameters.

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

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

No annotations are provided, so the description must carry the burden of behavioral disclosure. It states the operation is a read ('Returns all') and specifies scope (system, AU/VST3), but does not go beyond that to mention potential performance implications, filtering behavior, or output format. For a simple read-only listing, this is adequate but not exceptionally transparent.

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 two sentences long, front-loads the core action, and every word adds value. It includes the plugin formats and the use case, with no fluff or repetition of schema details.

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 the tool's simplicity (one optional parameter, no output schema), the description is nearly complete. It explains the primary function and usage context. Minor gap: it doesn't mention that filtering is possible, but that is covered by the schema, so the description still gives sufficient context for an agent to select and invoke the tool 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?

The input schema is fully self-descriptive (100% coverage): the only parameter 'filter' has a description explaining it filters by plugin name. The tool description adds no additional meaning, but the schema clearly handles parameter semantics, so the baseline score of 3 applies.

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 clearly identifies the tool's function: 'Returns all audio plugins (AU, VST3) installed on this system.' It uses a specific verb and resource, and the additional phrase 'Use to know what tools the producer has available' reinforces its purpose while distinguishing it from sibling tools like get_track_details or analyze_mix.

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 clear context for when to use the tool: 'Use to know what tools the producer has available.' It implies this is for discovering available plugins, but does not explicitly state when not to use it or cite alternatives, so it misses the highest bar for exclusionary guidance.

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

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

With no annotations provided, the description carries the full burden. It clearly implies a read-only operation ('Returns a snapshot') and details the contents, plus the behavioral recommendation to call once due to assumed session state stability. It does not disclose potential size or performance implications, but these are minor for a snapshot 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?

Two sentences: the first is front-loaded with the primary purpose and a concise list of contents, the second gives crisp usage guidance. Every word earns its place with no fluff or repetition.

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?

The description provides a solid overview of what is returned and when to use it, which is sufficient for a no-parameter, no-output-schema tool. It could be even richer by describing the output format or limitations, but it is complete enough for confident invocation.

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 tool has zero parameters, so schema coverage is trivially 100%. The baseline for 0 params is 4, and the description adds no unnecessary parameter details. It appropriately focuses on behavior and contents instead.

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 clearly states the tool 'Returns a snapshot of the current Ableton session' and enumerates the specific contents (tracks, volumes, panning, mutes, sends, device chains, return tracks, master track, routing). This specific verb+resource combination distinguishes it from siblings like get_track_details, which focuses on a single track, or get_spectral_snapshot, which covers spectral data.

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?

Explicitly states when to use ('Call once at the start of a conversation to orient yourself') and when not to ('No need to call again unless the user says the session has changed'). It does not explicitly name alternative tools, but the timing and frequency guidance is strong.

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

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

No annotations provided, so description carries full burden. It discloses the capture duration (~2 seconds), the requirement for transport to be playing, and the point-in-time nature, setting accurate expectations. No contradictions with annotations (none present).

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?

Description is concise, three sentences, each serving a distinct purpose: core functionality, necessary condition, and usage context. No redundant information.

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?

The description covers operation, requirements, and alternatives, which is good for a simple single-parameter tool. However, it doesn't specify the exact response format or frequency band breakdown, which would be helpful since there is no output schema. Otherwise, it's quite complete.

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 100% (source: 'master' for master bus, or a track name). The description adds no additional parameter semantics beyond the schema, so baseline 3 is appropriate.

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 clearly states the verb 'captures' and specifies the resource (live audio from master bus) and output (peak/RMS levels across frequency bands). It also distinguishes itself from get_track_details, making it unique.

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?

Explicitly states when to use: as a secondary check to verify device parameter analysis or detect issues like masking, phase, resonances. Also provides when-not-to-use: for most frequency questions, get_track_details is more informative. Includes prerequisite that transport must be playing.

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

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

With no annotations provided, the description carries the full burden. It reveals the return payload includes all devices, every parameter, and per-device observations, adding concrete behavioral detail. It does not mention error handling or read-only nature, but the verb 'Returns' implies a safe 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 a single, compact sentence that includes all necessary detail without redundancy. It front-loads the purpose and provides concrete examples of what is returned.

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?

With one parameter and no output schema, the description provides a solid overview of what will be returned. It could be more explicit about return structure, but the given specifics (devices, parameters, observations) are sufficient for the agent to understand the tool's scope.

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 already covers the single parameter (track_name) with a clear description. The tool description adds no additional semantic meaning beyond calling it a 'specific track', so the baseline of 3 applies.

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 clearly states the tool returns full detail for a specific track, listing the included content (all devices, parameters in human-readable units, per-device observations). This specific verb+resource phrasing distinguishes it from sibling tools like get_session_context or get_spectral_snapshot.

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 implies usage whenever a specific track's complete details are needed. It does not explicitly mention alternatives or exclusions, but the context is clear enough to guide the agent. Sibling names exist, but no when-not guidance is provided.

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

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

With no annotations, the description carries the full burden. It clearly discloses the critical approval workflow: present current → proposed, wait for a clear yes, and re-confirm if modified. This is significant behavioral context, though it omits side effects, return values, and error handling.

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 front-loaded with the core action and stays brief overall. The approval instructions are repeated across multiple sentences, creating minor redundancy, but the length is justified for a safety-critical mutation tool.

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?

The approval workflow is well specified, but the lack of an output schema means the description should clarify what happens after execution (e.g., success/failure, persistence). It also doesn't mention how to obtain current values, leaving the 'current → proposed' step underspecified.

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 description adds useful meaning by specifying that values are in human-readable units and listing them (dB, ms, Hz, ratio, percent), which applies to the value/unit pair. However, track_name, device_name, and parameter_name are left to inference, and with 0% schema coverage, more compensation would be expected.

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 clearly that it sets a device parameter to a new value, using a specific verb and resource. However, it does not explicitly distinguish from sibling tools like toggle_device_bypass, leaving some scope ambiguity.

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?

Provides a strong procedural guideline requiring explicit user approval, but gives no context on when to use this tool versus alternatives. The intended usage is implied by the tool's function rather than explicitly stated.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does warn about the need to confirm with the producer, which is a useful behavioral trait, but it omits details about side effects, reversibility, permission requirements, or what happens to the previous routing. This is a significant gap for a mutation 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?

The description is extremely concise: two short sentences with no filler. It is front-loaded with the primary action ('Changes a track's output routing') followed by a critical warning. Every word earns its place.

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 simple two-parameter mutation tool with no output schema and no annotations, the description provides the core action and a key precaution, but it is incomplete in terms of behavioral transparency and usage guidelines. It does not explain what happens after routing changes, potential errors, or how it fits with sibling tools.

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 already documents output_target as 'Name of the target track/group/bus', and the description's phrase 'output routing' adds little beyond that. track_name remains completely undocumented, and the description does not clarify its format or expected values. With only 50% schema description coverage, the description fails to compensate.

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 uses a specific verb+resource structure: 'Changes a track's output routing.' This clearly distinguishes it from sibling tools like set_device_parameter and toggle_device_bypass, which target different aspects of the track.

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 implies the tool should be used when changing a track's output routing, and adds an important prerequisite: 'Always confirm with the producer first.' However, it does not explicitly mention alternatives or conditions for when not to use this tool, leaving the usage guidance largely implied.

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

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

No annotations are provided, so the description must carry the transparency burden. It clearly states the action and includes a user-confirmation requirement, but omits potential side effects, reversibility, or error behavior. This is adequate but not rich.

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 three short sentences, front-loaded with the core action, followed by a use case and a safety reminder. Every sentence earns its place with zero 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?

For a simple 3-parameter tool with no output schema and no annotations, the description gives the essential purpose and a usage scenario. However, it lacks prerequisite information (e.g., how to reference tracks/devices) and behavior on failure, leaving some gaps for an agent to infer.

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 only 33%, and the description does not compensate. It says 'device on a track' but provides no details about track_name or device_name format requirements. Only 'active' is described in the schema, and the description adds no extra meaning to any parameter.

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 uses a specific verb-resource pair ('Enables or bypasses a device on a track') that clearly states the tool's function. It also adds context ('Useful for A/B comparison') and is distinct from sibling tools like set_device_parameter, which targets parameter changes rather than bypass state.

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 clear context ('Useful for A/B comparison') and a strong operational guideline ('Always confirm with the user before toggling'). However, it does not explicitly mention alternatives or when not to use the tool, lacking exclusion criteria.

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