AbletonMCP

by wstierhout

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.7.3
Disambiguation5/5
Each tool targets a distinct action or parameter in Ableton Live, with detailed descriptions that clearly differentiate even similar-sounding tools (e.g., generate_chord_progression vs generate_bassline). No overlapping purposes exist; even the many set_* tools are for unique settings.
Naming Consistency5/5
Virtually all tool names follow a consistent verb_noun pattern in snake_case (e.g., create_clip, set_tempo, get_session_info). Even generative tools use the same 'generate' prefix. Minor exceptions like describe_capabilities fit the convention.
Tool Count2/5
With 154 tools, the set is far beyond the typical 3–15 range considered well-scoped. While the scope of Ableton Live is large, this count is overwhelming for an agent and suggests a lack of focus. The server would benefit from grouping or reducing the number of tools.
Completeness5/5
The tool surface is exceptionally comprehensive, covering session management, MIDI/audio clips, device parameters, routing, mixing, automation, generative composition, offline file analysis, and more. No obvious gaps exist for common Ableton workflows.
Average 4.2/5 across 154 of 154 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 commits in the last 12 weeks
- Last stable release on July 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description further clarifies the exact outputs (group state, fold state, parent group name). No contradiction, and the description adds value beyond annotations by specifying the returned information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb 'Report' and efficiently lists all output attributes without any extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations are present, the description adequately covers the tool's purpose and outputs. Minor gaps include no mention of error handling or track index validity, but these are not critical for this simple read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter track_index has no description in the schema (0% coverage), and the tool description does not explain its meaning, valid range, or required input. This leaves the agent with no parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports a track's group state, specifying four distinct attributes (foldable group, inside group, fold state, parent group name). This distinguishes it from siblings like get_track_info or get_clip_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or comparison with other tools such as get_track_info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotation 'destructiveHint: false', the description only states 'load' without disclosing whether it replaces existing devices, appends, or any other side effects. Minimal extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear header and bulleted parameters, no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple load operation with an output schema (unseen), the description covers the basic action but omits error conditions and return values. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description lists parameters and gives a URI example but does not explain the track_index range or how to obtain valid URIs. Partially compensates but lacks depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Load' and identifies the resource as 'instrument or effect onto a track', clearly distinguishing it from sibling tools that load to master or return tracks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for loading onto a track but does not provide explicit guidance on when to use this tool versus alternatives like 'load_device_to_master', nor does it mention prerequisites such as valid track index or URI.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-destructive behavior. Description adds that the tool attaches a groove (swing/timing feel) and that omitting groove_index clears it. It does not disclose edge cases like invalid indices or what happens if no groove pool exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with verb and resource, no wasted words. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool with an output schema present, the description is mostly complete. It covers the primary action and clearing behavior. It could mention that the groove must exist in the Groove Pool, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It only clarifies the groove_index parameter ('Pass no groove_index to clear') but provides no additional meaning for clip_index or track_index beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Attach' and the resource 'clip', specifying that it attaches a Groove Pool groove by index. It distinguishes from sibling tools like set_clip_name or set_clip_color by explicitly mentioning the swing/timing feel effect and the clearing behavior when no groove_index is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., clearing a groove implies using this same tool, but no mention of prerequisites like having a groove pool defined). No explicit when-not or alternative tools like get_grooves are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only destructiveHint: false. Description adds that it modifies a clip's time signature, but lacks details on side effects, required permissions, or impact on playback. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with clear purpose and no extraneous words. Front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (context indicates true), the description omits critical details: parameter ranges, what 'clip's own time signature' means operationally, and how it interacts with existing clip settings. Insufficient for correct invocation in a DAW environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters (numerator, denominator, clip_index, track_index) lack descriptions in the schema (0% coverage). The description does not explain any parameter meanings or constraints, leaving the agent to guess time signature conventions and indexing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Set' and the resource 'a clip's own time signature', with parenthetical context '(polymeter / odd-bar loops)'. This distinguishes it from the sibling tool 'set_time_signature' which likely sets the global signature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance, nor alternatives mentioned. The parenthetical hint implies it's for polymeter/odd-bar loops, but the agent must infer usage context without direct comparison to related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide destructiveHint: false. The description adds value by mapping specific integer values to quantization presets, but lacks details on side effects, range validation, or impact on playing clips.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with a clear purpose followed by a succinct list of examples. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description adequately covers what the tool does and what the parameter means. The presence of an output schema likely covers return values, so no gap there.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single integer parameter has no schema description (0% coverage). The description compensates by explaining the meaning of specific values (0=None, 4=1 bar, etc.), which is helpful for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets the global launch quantization for firing clips/scenes, which distinguishes it from per-clip quantization tools. The verb 'set' and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like quantize_clip or set_clip_groove. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with the annotation (destructiveHint: false) and indicates a toggle behavior, but adds no extra context about side effects (e.g., whether play must be on, or impact on performance).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, perfectly sized for a simple toggle action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one boolean parameter, non-destructive, output schema exists), the description is nearly complete, though mentioning the metronome's state after toggling could add slight clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single boolean parameter 'enabled' is not explained in the description; with 0% schema description coverage, the agent must infer its meaning from the tool name and context, which is acceptable for a boolean but lacks explicit guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Turn on/off') and the resource ('Live's metronome click'), making the tool's purpose unambiguous and distinct from sibling set_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it specify any prerequisites or context for using the metronome toggle.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only repeats the tool's name and parameter, adding no behavioral details beyond what the name implies. The annotations provide destructiveHint: false, but the description does not elaborate on side effects, reversibility, or potential impacts on playback or automation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence and a parameter list. Every element earns its place, and the parameter is clearly labeled with its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool, the description is minimally adequate. However, it lacks information about the expected range of BPM, whether it affects all tracks, or the return value. The presence of an output schema (not shown) may compensate, but the description itself is sparse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds crucial context by specifying that the 'tempo' parameter expects a value in BPM (beats per minute). This clarifies the unit, which is not evident from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the resource ('tempo of the Ableton session'). It distinguishes this tool from siblings like set_track_volume or set_metronome by specifically targeting tempo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any context for its typical use. The agent receives no hints about prerequisites or situations where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=false, and the description adds that the color index is from Live's palette (0-69). It does not mention any immediate visual update or side effects, but the behavior is fairly transparent for a non-destructive visual change.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks necessary detail on parameters and usage. It is front-loaded with purpose but could be improved with more structured information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the minimal description and lack of parameter documentation, the tool is incomplete for an AI agent. It does not explain the color mapping or track index convention, even though an output schema exists but is not provided here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, and the tool description does not define the parameters beyond their names. It only mentions the color_index range, leaving track_index undefined (e.g., zero-based, master track handling).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set', the resource 'track's color', and the method using an index with a specific range (0-69), distinguishing it from siblings like set_clip_color.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, such as set_clip_color or other track modifications. Usage is implied by the name, but lacks context on prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotation (destructiveHint=false). It does not mention side effects, undo behavior, or requirements (e.g., track must exist). With only the annotation providing safety info, the description contributes minimally to transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences and a bullet list. It front-loads the main purpose and then details parameters with no redundancy or filler. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's purpose and parameters, but lacks information about constraints (e.g., valid track index range, track must exist). Since an output schema exists (not shown), return values are not required. The description is minimally viable but has clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% parameter description coverage, but the tool description explains both parameters: 'track_index: The index of the track to rename' and 'name: The new name for the track.' This adds meaning beyond the schema's type and title, effectively compensating for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Set the name of a track.' The verb 'Set' and resource 'name of a track' are specific, and it distinguishes itself from sibling tools like set_track_color, set_track_volume, and set_clip_name, which modify different attributes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, conditions, or cases where the tool should not be used. The description simply states what it does without contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide destructiveHint=false. The description adds no behavioral context beyond the basic action, missing details on side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence plus parameter list with no unnecessary words or repetition. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and existence of output schema, the description is adequate but minimal. It lacks context like valid index ranges or state changes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaningful parameter explanations: 'The index of the track containing the clip' and 'The index of the clip slot containing the clip', which are clear and helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Stop playing a clip' which is a specific verb+resource pair. It distinguishes from sibling tools like fire_clip (start) and stop_all_clips (stop all).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like stop_all_clips. The description does not mention context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint: false, but the description adds no behavioral detail beyond that. It does not mention side effects, default track settings, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence for purpose and one line for parameter. No extraneous information, front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and an output schema, the description covers key aspects. Missing details like default track state are minor given the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'index' is well explained, with the special value -1 meaning end of list. Given 0% schema description coverage, this adds necessary semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool creates a new MIDI track in the Ableton session, distinguishing it from siblings like create_audio_track or create_return_track.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as create_audio_track or create_scene. The description lacks when-not-to-use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, and the description adds the behavioral detail of what is returned (names, values, ranges, display strings). However, it does not disclose potential errors or prerequisites (e.g., device must exist). The description adds some context beyond annotations but is not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action and key output details. Every word contributes meaning, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are partly documented, and the description lists key fields. However, the lack of parameter descriptions and usage context reduces completeness for a tool with 2 required parameters and specific sibling alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not explain the parameters (track_index, device_index). While the names are somewhat self-explanatory, the description should clarify their meaning (e.g., what indices refer to) given the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'parameters of a device on a track', specifying what is returned (names, values, ranges, display strings). It differentiates from sibling tools like get_master_device_parameters and get_return_device_parameters by explicitly referencing a device on a track.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving device parameters but offers no explicit guidance on when to use this tool versus siblings like get_master_device_parameters or get_return_device_parameters. It is clear enough for basic selection but lacks exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits beyond the basic toggle action. Annotations only provide destructiveHint=false, so the description adds little context about network requirements, impact on playback, or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that is concise and front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple toggle tool, the description covers the main purpose. An output schema exists to handle return values. However, it could mention potential prerequisites like network connectivity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single boolean parameter 'enabled' is explained in the tool description (enabling syncs tempo/phase), but the schema has 0% description coverage. The description adds some meaning but could be more explicit about the parameter's effect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (enable/disable), resource (Ableton Link), and its function (syncing tempo/phase with other devices). This distinguishes it from siblings like set_tempo or set_metronome.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for syncing with other Link-enabled devices but offers no explicit guidance on when to use this tool versus alternatives, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide destructiveHint: false, indicating safety. The description adds valid ranges for parameters (e.g., gain 0-1, pitch_coarse -48..48) but does not disclose side effects, error behavior, or permissions. Sufficient for a simple setter but minimal extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One efficient sentence listing properties with ranges. No fluff, but could benefit from structuring as a list for readability. Front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, output schema exists, and the description covers most parameter semantics. However, it does not mention output, error conditions, or parameter interactions (e.g., effect of setting warp_mode when warping is false). Adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the burden. It explains gain range, pitch units, warping boolean, and warp_mode enumeration values. Missing only track_index and clip_index, which are self-explanatory. Adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set audio-clip properties' and enumerates specific audio parameters (gain, pitch, warping, warp_mode), distinguishing it from siblings like set_clip_color or set_clip_name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like set_clip_loop or set_clip_trigger_quantization. The description assumes the agent knows to use it for audio clip settings, but no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide destructiveHint: false. The description adds valuable behavioral info: value clamping to min/max and that parameter accepts both name and index. This goes beyond annotations and helps the agent understand constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the action and key behavior. No extraneous words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers core purpose and clamping but omits descriptions for the other three parameters and does not mention return values (though output schema exists). Sufficient for a simple setter but incomplete for a tool with four required params and no schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description only partially compensates by explaining 'parameter' can be string or integer and value is clamped. It does not describe track_index, device_index, or the meaning of value beyond clamping. Three out of four parameters lack semantic explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set), the resource (device parameter), and that value is clamped to min/max. It distinguishes from sibling tools like set_chain_device_parameter by targeting a general device parameter. Mentions parameter can be by name or index, adding specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like set_chain_device_parameter or set_master_device_parameter. The description only states what the tool does, not when it should or should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only destructiveHint=false. The description adds the range but does not disclose whether the change affects existing clips, is reversible, or requires specific conditions. Minimal behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundant words. The essential information (action, resource, range) is front-loaded and clearly presented.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description covers the main purpose and range. It could mention persistence or effect on existing quantization, but overall it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with no parameter description. The description adds the valid range (0.0 to 1.0) but lacks an explanation of what the amount value represents (e.g., 0=no swing, 1=maximum). The parameter has a clear role, so despite the gap, the description provides partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set'), the resource ('global swing amount'), and the valid range ('0.0 to 1.0'). It distinguishes from siblings like 'set_groove_amount' and 'set_clip_groove' by specifying 'swing' and 'global' scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for quantizing with swing but does not explicitly state when to use this tool versus alternatives like 'set_groove_amount' or 'quantize_clip'. No guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-destructive behavior (destructiveHint: false). The description adds the return value detail but does not disclose other behavioral traits like whether it creates a new lane or modifies existing lanes. It adds marginal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loading the action and purpose. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one integer parameter, output schema for return count), the description is mostly complete. It states the purpose and return value. A mention of what track_index refers to would improve it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the single parameter track_index, leaving its meaning entirely to the schema (which has 0% coverage). Since schema coverage is low, the description should compensate but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a take lane'), the resource (take lane to a track), and the return value ('Returns the new take-lane count'). It distinguishes from sibling creation tools by specifying the unique context of comping takes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for comping multiple recorded takes but does not explicitly state when to use this tool over alternatives or provide exclusion criteria. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations: it explains the generative process (genre grammar transposed into key+scale, then voiced), mentions fuzzy matching for genre, and clarifies that bars correspond to number of chords (grammar loops). The annotation 'destructiveHint: true' is consistent with the explicit 'REPLACES existing notes'. The description also indicates it returns chord symbols. This provides good transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the main action and includes important details like the list of genres and the replacement behavior. It is reasonably concise, though the list of genres could be abbreviated. The structure is clear and every sentence adds value except possibly the lengthy genre list, but it's useful for fuzzy matching.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (12 parameters, destructive behavior, output schema exists but not described), the description covers the core functionality and the destructive warning, but it leaves many parameters unexplained. The return value is mentioned ('chord symbols') but not detailed. For a tool that replaces existing notes, more context about what gets overwritten and how would improve completeness. The description is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 12 parameters with 0% description coverage. The description only explains 'genre' (lists examples, mentions fuzzy matching) and 'bars' (number of chords). Other parameters like 'key', 'scale', 'style', 'voices', 'seed', 'velocity', 'center_pitch', 'beats_per_chord', and required 'track_index'/'clip_index' are not mentioned. Even though some are common, the description fails to add meaning for most, leaving the agent underinformed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds a genre-idiomatic chord progression and writes it as voiced chords, specifying that it replaces existing notes. It lists many genres and distinguishes itself from 'generate_voiced_progression' by noting that tool handles style options. The verb 'Build' and 'write' along with the resource 'chord progression' make the purpose very specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that it replaces existing notes and provides a list of genres, but it does not explicitly state when to use this tool over others like 'generate_chord_progression' or 'generate_voiced_progression'. It refers to 'generate_voiced_progression' for style options but does not clarify when one would choose this tool over that one. Some context is implied but no explicit when-not or alternative usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the destructiveHint annotation by explaining that existing notes are replaced and detailing the effects of parameters like pocket, swing, ghost, and humanize. It would benefit from mentioning undo behavior or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 4 sentences, front-loaded with purpose and destructiveness, followed by parameter explanations. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 9 parameters and 0% schema description coverage, the description covers the core generative parameters but misses scaffolding parameters (bars, seed, track_index, clip_index). The existence of an output schema reduces the burden for return values, but parameter coverage could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description explains 5 of 9 parameters (style, pocket, swing, ghost, humanize) with ranges or examples. However, it omits bars, seed, track_index, and clip_index, leaving gaps for a tool with many parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it writes a pocketed drum groove into a Session clip and replaces existing notes. It mentions specific parameters and the standard Live drum map, which distinguishes it from siblings like generate_drum_pattern or generate_bassline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description warns that the tool REPLACES existing notes, implying destructive use, but does not explicitly state when to use this tool versus alternatives like write_drum_grid or generate_drum_pattern. Usage context is implied rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds algorithmic detail beyond the destructiveHint annotation: root on beat 1, chromatic approach on last beat, ghost notes, and impact of key/scale. This helps the agent understand the tool's behavior. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with two sentences separated by purpose and parameter details. It front-loads the main action and lists key parameters. Minor improvements could structure parameter explanations more systematically, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description omits critical operational details: required parameters track_index and clip_index are not explained, and optional parameters like beats_per_chord and seed lack any context. For a tool with 10 parameters, this leaves significant ambiguity for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains some parameters (progression, key, scale, octave, ghost) with specific formatting and ranges. However, other parameters (seed, velocity, beats_per_chord, track_index, clip_index) remain unexplained, leaving gaps for half the inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Write[s] a quarter-note walking bass line under a progression' and specifies it replaces notes. The term 'walking bass' distinguishes it from sibling tools like generate_bassline which likely produce different styles. The verb-resource pair is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for generating a walking bass line over a chord progression, but it does not explicitly state when to use this tool versus alternatives like generate_bassline. It mentions it replaces notes, hinting it works on existing clips, but lacks clear when-to or when-not-to guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the read-only nature ('List') consistent with the readOnlyHint annotation. No additional behavioral context is provided beyond the annotation and basic output fields. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of 12 words, front-loaded with the verb 'List' and resource. No redundancy or unnecessary details; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and the existence of an output schema, the description covers the essential output fields. However, the lack of parameter guidance slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter descriptions (0% coverage) and the description does not explain the parameters 'track_index' and 'device_index', leaving the agent to infer from names alone. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('List') and resource ('Drum Rack's occupied pads'), and lists the returned attributes (MIDI note, name, mute, solo). This differentiates it from sibling tools like set_drum_pad or write_drum_grid.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading drum pad details but provides no explicit guidance on when to use this tool versus alternatives (e.g., set_drum_pad for modifications). No when-not-to-use or prerequisite information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the destructiveHint annotation by stating it loads onto the master track and gives an example. However, it does not disclose potential side effects (e.g., replacing existing devices, impact on routing) or any prerequisites. The annotation is not contradicted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with an example, making it concise and front-loaded. It wastes no words, but it could be more impactful by including parameter guidance without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (reducing the need to explain return values), the description covers the basic purpose but leaves the critical parameter undocumented. For a simple tool, the description is not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter item_uri is left unexplained in both the schema (0% coverage) and the description. Since the description does not clarify what format or type of URI is expected (e.g., browser path, device ID), the agent cannot infer how to populate this parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'load', the resource 'device/effect from the browser onto the Master/Main track', and provides a concrete example (limiter for mastering). It distinguishes from siblings like load_device_to_return and load_instrument_or_effect by specifying the target track.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case (mastering, e.g., limiter) and implies when to use this tool (when adding a device to the master track). However, it does not explicitly mention when not to use it or point to alternative tools like load_instrument_or_effect for non-master tracks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=false, and the description adds that it replaces existing envelopes. This provides clear behavioral insight beyond the annotation, though no additional side effects or permissions are discussed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences cover purpose, format, and behavior. No unnecessary words, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a compact description, it fails to cover the semantics of 80% of the required parameters. An agent with schema coverage 0% would struggle to understand how to identify the target device and parameter. The description leaves significant gaps for a tool with five required inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the burden falls on the tool description. Only the 'points' parameter is explained with format details. The other four parameters (track_index, clip_index, device_index, parameter) are left undefined, leaving the agent to infer their meaning from context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes clip automation for a device parameter, specifying the points format. It implicitly distinguishes from siblings like 'set_device_parameter' and 'clear_automation' by focusing on automation curves and replacement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that it replaces any existing envelope, giving some context for when to use it, but it does not explicitly state when not to use it or compare with alternatives like 'set_device_parameter' for static values.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only; the description adds that it works without Live and details what information is extracted, providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a follow-up on the parameter, efficiently covering the tool's purpose and key detail without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers input and functionality. It lacks mention of prerequisites or side effects, but for a static analysis tool this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description clarifies that 'path' is a filesystem path to a .als file, adding necessary meaning that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it summarizes a .als file without Live running, listing specific fields. It implies a distinction from tools that require Live, but does not explicitly name alternatives like 'als_details'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context for use (when Live is not running), but does not provide guidance on when not to use it or how it compares to similar tools such as 'als_details' or 'als_list_tracks'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation indicates non-destructive behavior. The description adds that index -1 appends at the end, but does not disclose other behavioral traits such as whether an empty scene is created or what happens with invalid indices. It adds some value beyond annotations but is not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential purpose and key parameter behavior. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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, output schema exists), the description is largely complete. It does not explain side effects or prerequisites, but the non-destructive annotation and output schema mitigate the need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains that the index parameter with -1 appends at the end. This adds meaningful context that the schema alone does not provide, effectively compensating for the lack of parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new scene (row of clip slots). The verb 'create' and resource 'scene' are specific and distinguish it from sibling tools like delete_scene, duplicate_scene, or fire_scene.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like capture_and_insert_scene. The description does not mention prerequisites or when not to use it, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description aligns with a read operation. No additional behavioral traits are disclosed beyond 'list parameters', which is sufficient given annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence contains all essential information with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema is present, and the annotation covers safety. However, the description omits clarification of the parameter and any usage context beyond the name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fails to explain the meaning of 'device_index' (e.g., index in master track's device chain). The parameter is left entirely opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'parameters of a device on the Master track', distinguishing it from siblings like 'get_device_parameters' for regular tracks and 'get_return_device_parameters' for return tracks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's name and description imply it is for master track devices, and the sibling list includes 'get_device_parameters' for regular tracks, providing implicit guidance. However, no explicit when-to-use or alternatives are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=false, indicating no destructive behavior. The description adds action details but doesn't clarify recall's overwrite behavior or side effects. Some behavioral traits remain implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with minimal but complete information, front-loading the core concept. Every word serves a purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists (reducing need to describe return values), the description fails to explain critical parameters like track_index and device_index. The tool has moderate complexity with 4 parameters, and the description covers only half adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'action' and 'index' but omits 'track_index' and 'device_index', which are required. This leaves significant gaps for an agent to correctly invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages 'rack macro snapshots' with three specific actions: store, recall, randomize. This is a specific verb-resource pair that distinguishes it from sibling tools like 'get_rack_chains' or 'set_device_parameter'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists when to use each action (store to save, recall to restore, randomize for exploration). While it doesn't mention exclusions or alternatives, the context is clear for a specialized tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly notes that the response reports the pre-command state, which is behavioral information beyond the annotation (only indicates non-destructive). This helps the agent understand the tool's effect on output. The absence of any contradiction with annotations is noted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with the action clearly stated first. The note is secondary but important. Every word serves a purpose, and it is front-loaded with the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an existing output schema, the description provides the essential behavioral note about the response reporting pre-command state. This completes the picture for the agent, making the tool fully understandable without missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is 100%. The description does not add parameter information because none exist. The baseline of 4 is appropriate since no additional semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool stops playback, using the specific verb 'stop' and resource 'playback'. The note about the response adds clarity. However, it does not differentiate from sibling tools like 'stop_clip' or 'stop_all_clips', which could confuse when to use this versus those.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not mention when not to use it, nor does it reference sibling tools like 'start_playback' or 'stop_clip'. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description reinforces that the tool is offline and non-destructive. It adds specific behavioral details about the checks performed (no master limiter, empty tracks, etc.), which provides useful context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at two sentences, with the purpose and key checks front-loaded. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (one parameter, readOnly annotation, output schema exists), the description is reasonably complete. It explains the tool's purpose, specific checks, and that it returns machine-readable issues. The presence of an output schema reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'path' has no description in the input schema (0% coverage). The tool description does not elaborate on the parameter, such as file format constraints or whether relative paths are acceptable. The meaning is only inferred from the tool name and usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lints a saved .als file for likely-unfinished work, listing specific checks (no master limiter, MIDI track without instrument, etc.). It distinguishes itself from sibling als_ tools by focusing on identifying unfinished work before rendering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage before rendering by mentioning 'returns machine-readable issues so an agent can decide what to fix before rendering.' However, it does not explicitly state when not to use this tool or provide alternatives among the many sibling tools. The guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint: true, but the description adds valuable behavioral context: 'Later scene indices shift down by one.' This goes beyond the annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, no filler, and front-loaded key information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of annotations and output schema, the description is mostly complete. However, it could mention what happens on invalid indices or the return value for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the parameter scene_index is 0%, and the description does not explain its meaning, range, or required format. The agent must infer from the name alone, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'scene (row)', and distinguishes from sibling tools like create_scene or duplicate_scene by specifying the action and consequence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates usage to delete a scene but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention prerequisites or alternatives among siblings like delete_track.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation provides destructiveHint=true. Description adds crucial behavioral note about indices shifting down, which is beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with purpose. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers core behavior for simple deletion with index shift. Output schema exists but description misses permanence or failure conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. Description only indirectly implies track_index meaning via the index shift note. Does not clarify indexing convention or bounds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States 'Delete a track' clearly, specifying verb and resource. Distinguished from sibling deletion tools by focusing on tracks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives (e.g., delete_clip, delete_scene), but name and context imply track-specific deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool replaces existing notes, and explains style behaviors (roots, root_fifth, walking, eighth_pump) and octave ranges. Annotations already provide destructiveHint=true, so description adds meaningful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: it states the action and side effect first, then details parameters. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main behaviors but omits details on 'beats_per_chord' and does not describe the output format (though output schema exists). The tool has 7 parameters with 0% schema coverage, so more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds value by explaining the 'progression' parameter (referencing generate_chord_progression syntax), style options, and octave. However, it does not explain 'velocity', 'clip_index', 'track_index', or 'beats_per_chord', leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Write a bassline following a chord progression.' It explicitly mentions that it replaces existing notes, distinguishing it from other note-generation tools. Among siblings, it is distinct from generate_chord_progression and generate_drum_pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for generating basslines but provides no explicit guidance on when to use this tool versus alternatives. It does not include when-not-to-use scenarios or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate destructiveness (destructiveHint=true). The description adds significant behavioral detail, explaining voice-leading, bias to chord tones, optional chromatic notes, and parameter effects, which goes beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with an initial summary, then a list of parameters with specific values and ranges. It is relatively concise given the number of parameters, though slightly dense. Front-loads key information (replaces notes).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and 13 parameters, the description covers most aspects of behavior and parameter meanings. It lacks information about return values (output schema exists but is not provided) and prerequisites, but otherwise is sufficiently detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining most parameters: progression (dash-/comma-separated), key (examples), scale (list of options), density, phrase_arc, chromatic (range), low/high (MIDI), swing (range). It omits seed and beats_per_chord, but coverage is strong overall.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'write a voice-led melody over a chord progression' and emphasizes it 'REPLACES existing notes.' This distinguishes it from sibling generative tools like generate_bassline or generate_drum_pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it. It simply describes functionality without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint: true. Description adds value by enumerating returned fields (e.g., warp markers for audio clips), enhancing transparency without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with front-loaded purpose ('Full clip state') and specific items listed; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values are documented. The description covers the main content of the state. Minor omission: does not mention that it returns state for the clip identified by the indices, but that is inferred.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage and the description does not explain parameters (track_index, clip_index). While parameter names are somewhat self-explanatory, the description fails to clarify their meaning or usage, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description lists specific resources (loop points, markers, playing position, per-clip time signature, and for audio clips file path, gain display, warp markers) with a clear verb 'get', distinguishing it from siblings like get_clip_notes or get_track_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives guidance. Usage is implied for retrieving full clip state, but no exclusions or comparisons to siblings like get_clip_notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description clarifies that it REPLACES the clip's notes (destructive), and adds that pitches are preserved and times stay non-negative, which is valuable behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main operation, followed by parameter explanations. It avoids redundancy, though the structure could be slightly more organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description covers the main behavior (replacing notes, parameter effects) adequately, though it could mention parameter ranges or typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains timing, velocity, and seed parameters, but does not explain the required track_index and clip_index parameters, leaving them ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a MIDI clip, applies timing and velocity humanization, and writes it back. It uses specific verbs and resources, and distinguishes itself from siblings like quantize_clip by focusing on humanization (jitter) rather than quantization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for humanizing MIDI clips but does not explicitly state when to use it vs alternatives like quantize_clip or edit_notes. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=false; description does not contradict. It adds the quantization behavior and humanization hint, but doesn't disclose any side effects or irreversibility beyond what 'quantize' implies. With minimal annotations, more behavioral context could be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Each sentence delivers essential information: operation and parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, description doesn't need to cover return values. It adequately explains the tool's function and parameters for a simple quantization operation, leaving no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage; description compensates by explaining grid and amount meaning and valid values. Required parameters track_index and clip_index are not elaborated but are self-explanatory. Overall, description adds significant value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Quantize a MIDI clip' with specific verb and resource. It lists grid options and amount meaning, but doesn't differentiate from sibling tools like set_clip_groove or edit_notes, though that's not critical here.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on grid values and amount usage, including the tip to use <1.0 for humanizing. It does not explicitly state when not to use this tool versus 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-destructive, and description adds the value range and send index mapping. However, it does not disclose potential side effects (e.g., affecting audio output) or prerequisite conditions beyond the parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no extraneous information. It front-loads the purpose and key constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool with an output schema, the description is adequate but lacks explanation of the track_index parameter. It does not provide context on valid track indices or return track existence, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; the description clarifies send_index (0=Return A, etc.) and value range (0.0-1.0). It does not explain track_index, but it partially compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set', the resource 'track's send level', and provides the send index mapping (Return A, B, etc.) and value range. It distinguishes this from other set_* tools by specifying send level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to set a send level) but provides no explicit guidance on when not to use or how it differs from sibling tools like set_device_parameter or set_track_volume.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context about the tool's purpose (toggle recording) and its relation to captured knob rides, but does not disclose additional behavioral traits beyond the annotations. With destructiveHint=false already indicating it's not destructive, the description adds moderate value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys purpose and differentiation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has low complexity (one boolean parameter) and an output schema exists. The description provides sufficient context for basic understanding, though it omits return value details. Given the output schema, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate but only implies that 'enabled' controls the toggle. The boolean parameter is inherently simple, but more detail (e.g., what happens when enabled) would be helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Toggle recording of parameter changes') and the resource ('Session clip envelopes'). It also distinguishes itself from the sibling tool 'write_automation' by mentioning it's an alternative for 'captured knob rides'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly labels the tool as an alternative to write_automation for a specific use case ('captured knob rides'), providing clear context for when to use it. However, it does not explicitly state when not to use it or mention other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=false, so the tool is non-destructive. The description adds valuable behavioral details: it records into armed tracks, uses record_length for a fixed-length loop, and auto-switches to playback. This goes beyond the annotation alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose, parameter usage, and behavior. Every word adds value, and it is front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and an output schema (though not shown), the description adequately explains the recording behavior and parameter. It could mention what happens if record_length is null (continuous recording), but the example implies it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description compensates by explaining that record_length is in beats and provides an example (16.0 = 4 bars) for a fixed-length loop. This adds clear meaning beyond the schema type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool starts session recording into armed tracks and explains the record_length parameter for a fixed-length loop. However, it does not explicitly differentiate it from sibling tools like set_record_mode or set_session_record, which could also be related to recording.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when starting a fixed-length recording but does not provide explicit guidance on when to use this tool versus alternatives (e.g., set_record_mode for manual stop). No when-not-to-use or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by clarifying that extraction is from saved files, per clip, and that no Live installation is required. It does not contradict annotations (readOnlyHint: true). However, it omits potential edge cases like file version compatibility or multiple clips.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with critical information front-loaded: the core function in sentence one, a key parameter detail in sentence two. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description covers return format and prerequisite (track_index from als_summary). Minor gaps: no mention of file size limits or encryption state, but adequate for a simple extraction tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains track_index as 'the track's position in the set (see als_summary)', adding context. However, path is left without description beyond its type, missing explanation of expected format (e.g., full file path).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (extract MIDI notes), the source (track in a saved .als file), and the output format (dictionaries per clip). It distinguishes from sibling tools like 'get_clip_notes' (which requires Live) by noting 'No Live required' and by targeting offline .als files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the reference to 'see als_summary' for track_index, but does not explicitly state when to use this tool versus alternatives (e.g., get_clip_notes for live sessions). No exclusion criteria or alternative tool names are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description 'snapshot ... into a new scene' is non-destructive, consistent with destructiveHint: false. It adds context about capturing current playing clips but does not detail edge cases (e.g., no clips playing) or naming conventions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the action and context. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters and an output schema exists, the description provides essential information. It could mention what happens if no clips are playing or how the new scene is named, but overall it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters are present (schema coverage 100%). The description adds meaning by explaining the tool's purpose, which is sufficient since no parameter details are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Snapshot the currently playing Session clips into a new scene'. The phrase 'keep that combination' workflow distinguishes it from siblings like 'create_scene' (which creates an empty scene) and 'fire_scene' (which triggers playback).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via 'keep that combination' workflow, suggesting it is for preserving current clip arrangements. However, it does not explicitly state when to use this over alternatives like 'create_scene' or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, but the description adds value by explicitly stating that indices shift and advising to re-read the chain afterward, which is crucial behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action and immediately providing the critical side effect. Every sentence adds necessary information with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 simple parameters, output schema exists, annotations present), the description covers the operation and its important consequence. Missing maybe a mention of the output type, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that device_index is 0-based, adding meaning to that parameter, but track_index remains unexplained. Partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes a device from a track's chain by position (0-based), which is a specific verb and resource. It distinguishes from siblings like delete_track or delete_clip by specifying 'device' and 'chain'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives provided. The description implies usage for removing devices but doesn't contrast with other delete tools such as delete_track or delete_clip, leaving the agent without guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavioral detail of moving the playhead, which is already implied by the name. Annotations already indicate non-destructive (destructiveHint: false), so extra context is minimal but non-contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no extraneous information, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple one-parameter tool with an output schema, though it could mention error handling for invalid indices. Overall complete for the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the sole parameter 'locator_index' by clarifying it comes from get_locators, which the schema alone does not convey. This compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move the playhead to a locator') and specifies the source of the index ('from get_locators'), distinguishing it from sibling tools like create_locator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests prior use of get_locators to obtain the index, but does not explicitly state when to use this tool or provide alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds that values clamp to the parameter's native range, providing behavioral insight beyond annotations. However, does not disclose other behaviors like permission requirements or undo behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. First sentence states action and context, second adds clamping behavior. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
References get_rack_chains for indices and mentions clamping, but lacks information on error handling, prerequisites, or how to obtain the indices. Output schema exists but description could be more complete for a 6-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Does not explain any parameters beyond the generic context. with 0% schema description coverage, the description should provide details on parameter formats, valid ranges, or how to specify the parameter, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it sets a parameter on a device inside a rack chain, specifying the source of indices (get_rack_chains). This distinguishes it from sibling tools like set_device_parameter which operate on non-chain devices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage context by referencing get_rack_chains for indices, but does not explicitly state when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the core behavior (fold/unfold) and the error condition for non-group tracks. Annotations already indicate non-destructive, and the description aligns with that, adding useful detail without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loaded with the action, and contains no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers the essential action and error case. However, the lack of parameter descriptions slightly reduces completeness, though the tool is straightforward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should add meaning beyond the schema. However, it provides no explanation of the parameters ('folded' and 'track_index'), leaving the agent to infer their purpose from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool folds/collapses or unfolds a group track, using specific verbs and resource. It references sibling tool get_group_info for checking track type, distinguishing it from other track manipulation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the tool is for group tracks only and errors otherwise, advising to check with get_group_info. This provides clear when-to-use context, though it doesn't explicitly state when not to use it beyond the error condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations (destructiveHint=false), explaining that recording targets armed tracks' selected slots and enables MIDI overdub. It does not contradict the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the core function and additional detail without superfluous words. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the presence of an output schema, the description covers the main behavior well. However, it omits prerequisites (e.g., armed tracks must exist) and does not mention the return value, which the output schema likely addresses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description partially compensates by explaining the effect of the parameter (enabled), but it is ambiguous whether 'Toggle' means the boolean directly sets the state or toggles. More explicit mapping would improve clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool toggles Session record, explaining it records into armed tracks' selected slots and enables MIDI overdub. This is a specific verb+resource that distinguishes it from sibling tools like set_record_mode or trigger_session_record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for toggling session recording, but lacks explicit guidance on when to use it versus alternatives such as set_record_mode or trigger_session_record. No exclusions or recommended contexts are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include destructiveHint: false. The description adds the failure condition on unarmable tracks, which is useful. However, it does not disclose the exact behavior on success (e.g., does it return anything, does it affect recording state) or whether it checks prerequisites like track existence. With minimal annotation coverage, more detail would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 17 words, directly stating the purpose and a key limitation. Every word is necessary, and it is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 params, both required) and the presence of an output schema, the description covers the main behavior and failure case. It could mention prerequisites like track existence, but for a simple toggle tool, this is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds some context by linking 'arm or disarm' to the arm parameter and 'track' to track_index. However, it does not explain track_index indexing (e.g., zero-based) or valid ranges, nor does it specify that arm is a boolean setting. The added value is moderate but not fully compensating for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('arm or disarm'), the resource ('track for recording'), and includes a specific caveat about failure on group/return tracks, which distinguishes it from sibling tools like set_track_mute or set_track_solo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly indicates when the tool should not be used (on tracks that can't be armed, e.g., group/return tracks), providing implicit guidance compared to alternatives. It does not name specific alternatives but the caveat is sufficient for an agent to avoid misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations indicate the tool is not destructive (destructiveHint=false). The description adds the behavioral context of the state values (0=In, 1=Auto, 2=Off) but does not disclose other potential side effects, persistence, or impact on playback. The description adds moderate value beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no redundant information. The first sentence clearly states the purpose and values; the second provides context. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters and an output schema assumed. The description covers the core functionality and necessary state values. It lacks detail on the return value or the track_index parameter, but overall it is sufficiently complete for a straightforward setting tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It explains the 'state' parameter with its three integer values, which is helpful. However, it does not explain the 'track_index' parameter at all, leaving a gap in meaning for that required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool sets input monitoring, provides the three possible values (0=In, 1=Auto, 2=Off), and mentions it is required for resampling/bounce workflows. This clearly distinguishes it from sibling tools which handle other track settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating it is 'Required for resampling/bounce workflows,' which implies when to use it. However, it does not explicitly exclude other scenarios or mention alternatives, but given it is the only tool for this function, the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations: specifies valid range (0.0-1.0) and that 0.85 equals 0 dB unity gain. Annotations only indicate non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with action, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, no return description needed. Covers volume range and meaning, but could mention it affects mixer volume. Adequate for a simple setter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Volume parameter is well-described with range and dB mapping. Track_index lacks any description beyond its name. With 0% schema coverage, partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('Set track volume') and provides the range and unity gain mapping, distinguishing it from sibling tools like set_master_volume.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage: to set a track's volume. No explicit when-to-use or alternatives compared to siblings like set_master_volume or set_return_device_parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool mutates the set and may remove/restore content, contradicting the destructiveHint: false annotation which implies it is not destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, well-structured, front-loaded with core action, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key side effects and usage context adequately for a simple undo tool with output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the schema fully covers them. Baseline 4 applies as description does not need to add param details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reverts the most recent undoable action, and distinguishes it from redo and batch_commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly suggests using redo for accidental undo and batch_commands for grouped edits, providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true (no modification) and destructiveHint=false. The description adds value by specifying it works offline and detailing what differences are reported, enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences), front-loaded with the core action, and every part adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description does not need to explain return values. It covers the key inputs and what the diff includes. Slightly incomplete in not mentioning if there are any prerequisites (e.g., files must exist).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description must explain parameters. It implies path_a and path_b are file paths to .als files but provides no details on format, validation, or use (e.g., relative vs absolute paths). This is minimal compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool diffs two .als files and lists specific changes it detects (tempo, time-signature, tracks, per-track deltas). This clearly distinguishes it from sibling tools like als_summary or als_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates it works 'offline' and is 'great for logging what changed between versions', implying when to use it. However, it does not explicitly state when not to use it or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses the behavioral trait of index shifting, which is important for correct multi-delete operations. This adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences with a clear instruction and a critical warning. No extraneous words, and the important note is highlighted in caps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple operation and presence of an output schema, the description covers the essential behavior and the main caveat. It could mention prerequisites like 'arrangement view must be active', but that is likely implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only hints that arrangement_clip_index is a position from get_arrangement_clips, but provides no details about track_index or parameter constraints. With 0% schema coverage, this is insufficient for an agent to reliably determine parameter values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete' and the resource 'a clip from the Arrangement timeline', with the specific method 'by its position in get_arrangement_clips' list'. This distinguishes it from sibling tools like delete_clip or delete_track.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a NOTE that explains how indices shift after each delete and advises to re-read get_arrangement_clips between deletes. This provides crucial usage guidance, though it does not explicitly list when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the destructive behavior (replacing notes), aligning with the destructiveHint annotation. It also details the algorithm and parameter effects, though some behavioral traits like output summary content are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and warning. It is moderately concise, though the algorithmic explanation could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, 0% schema coverage, and an output schema, the description covers the main algorithm and parameter usage. It lacks details on the return value and assumes MIDI clips, but is generally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by explaining key parameters (pitches, note_length, steps, source_clip_index) and their roles. However, track_index, clip_index, and velocity are not elaborated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a 'Philip-Glass additive process' into a Session clip, explicitly mentioning it replaces existing notes. This distinguishes it from sibling generative tools like generate_melody or generate_bassline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how the tool works with parameters but does not explicitly indicate when to use it versus other generative tools. No when-not or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states REPLACES existing notes (destructive), explains the Euclidean distribution, rotation, humanization, and instrument mapping. This adds significant context beyond the destructiveHint annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences front-loading the main action. However, the second sentence is a run-on list of parameter explanations, slightly lacking structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 params, no schema descriptions) and the presence of an output schema and annotations, the description provides enough context for most users. Missing seed and velocity details slightly reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains most parameters (steps, pulses, rotate, bars, humanize, instrument) but misses seed and velocity. Since schema coverage is 0%, the description should cover all parameters; missing two is a notable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a Euclidean (Bjorklund) rhythm into a Session clip, specifying the algorithm and how parameters affect the pattern. It distinguishes itself from siblings like generate_drum_pattern by the Euclidean algorithm focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for Euclidean rhythms but does not explicitly guide when to use this tool versus alternatives like generate_drum_pattern or write_drum_grid. No when-not-to-use or alternative names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true; description adds specific behavioral context: it reads sidechain routing for Compressor/Gate devices and provides available options. Does not mention error handling but is consistent and informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with two sentences: first states purpose, second adds context and actionable next steps. No unnecessary words, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the main functionality and constraints (device type, read-only, output usage). Could mention potential errors (e.g., invalid indices or non-sidechain device) but output schema likely covers return type. Good overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters track_index and device_index beyond their names. For a two-parameter tool with no schema descriptions, more semantic guidance is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads device audio-input (sidechain) routing, specifying both current state and available options. It distinguishes from siblings like set_device_routing and get_track_routing by mentioning 'Read' and contrasting with the setter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (to see sidechain routing) and that it applies only to sidechain-capable devices (Compressor, Gate). Also suggests using output with set_device_routing. Lacks explicit 'when not to use' but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the readOnlyHint annotation by explicitly stating that the tool lists 'previously unreachable nested devices,' which is important for understanding the tool's value and behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose and includes a usage tip. Every part earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (no need to explain returns), the description is fairly complete for a list tool. It explains what is listed and hints at follow-up actions. However, it could mention that the device must be a rack.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage (no descriptions for parameters), so the description should compensate. The description implies the tool works on a specific track and device but does not explicitly define track_index and device_index. With 0% schema coverage, more detail is needed to guide the agent on parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists an Instrument/Effect Rack's chains and the nested devices within each chain. It uses a specific verb (List) and resource (Rack's chains and devices), and distinguishes it from sibling tools like get_device_parameters by noting that these nested devices were previously unreachable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 this tool (to list rack chains and nested devices) and directs the agent to use set_chain_device_parameter to control them after listing. However, it does not explicitly state when not to use it or compare it to other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description is consistent and adds value by disclosing the specific data returned (names, values, min/max, display strings). No contradictory or missing behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, one for purpose and one for usage guidance. No unnecessary words, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with annotations and an output schema (not shown but present), the description adequately covers the essential purpose and usage context. The sibling set tool is referenced, providing navigation. Minor lack of parameter detail does not severely impact completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description does not elaborate on the parameters 'device_index' and 'return_index'. The titles in the schema are self-explanatory, yet the description misses an opportunity to clarify their meaning or range. This is a gap given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'parameters of a device on a Return track', and specifies the returned fields (names, values, min/max, display strings). It distinguishes the tool from its sibling 'set_return_device_parameter' by indicating its purpose as a precursor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises 'Call before set_return_device_parameter', providing clear sequential guidance. While it does not list alternatives or when-not-to-use, the context implies this tool is for inspection before modification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true. The description adds that the list returns index and name, which gives some behavioral context beyond the annotation. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that perfectly conveys the tool's purpose without any extraneous information. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, a readOnly annotation, and an existing output schema, the description is complete. It tells exactly what the tool does and what it returns, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description cannot add parameter semantics, but the baseline for zero-parameter tools is 4, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'return tracks', specifying the output includes index and name. This distinguishes it from sibling tools like create_return_track or get_track_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. However, the purpose is straightforward and obvious from the name and description, so the lack of guidance is less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnlyHint: true. The description adds that meters are post-fader, range 0.0-1.0ish with 0.85 ≈ 0 dB, and that polling is expected. This provides meaningful behavioral context beyond the annotation, though it does not detail whether values are peak or RMS.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the core function and range, then adds practical usage advice. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one parameter and an existing output schema, the description provides sufficient context for understanding the return values (left/right meters). It covers the essential behavior during playback. Minor deduction for not stating the output format or confirming stereo peak, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter, track_index, with schema description coverage 0%. The description does not explain the parameter beyond what the schema title implies. Since the description should compensate for low schema coverage, it falls short by not clarifying the role of track_index (though it's somewhat inferable).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Read a track's output level meters' and the resource 'post-fader' with a specific range and reference point (0.85 ≈ 0 dB). It distinguishes itself from siblings by explaining its unique role in monitoring levels during playback, contrasting with other track manipulation or info tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to 'Poll during playback to judge balance/clipping' and frames this as how to 'listen' without exporting. This implies when to use the tool (during playback) but does not explicitly list alternatives or exclude other contexts. Slight deduction for lack of explicit when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide 'destructiveHint: false'. The description adds context by explaining that the direction parameter controls next (>=0) or previous (<0) jump, which is the key behavioral trait. It does not mention any side effects or success conditions, but for a simple navigation tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with 22 words, front-loaded with the action verb. No superfluous text; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and an output schema, the description is complete. It covers the core functionality and the parameter's effect. No additional information is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full burden. It explains the meaning of the 'direction' parameter: non-negative jumps to next cue, negative jumps to previous. This adds value beyond the schema, which only shows type, title, and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Jump' and the resource 'playhead' with specific target 'locator/cue', and differentiates between next/previous based on direction. It distinguishes from siblings like 'jump_to_locator' (which jumps to a named locator) and 'jump_by' (which jumps by time amount).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'jump_to_locator' or 'jump_by'. The description only explains the behavior based on direction, but does not provide usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-destructive behavior (destructiveHint: false). The description adds minimal context ('in Live') but does not disclose what happens if there is no action to redo or other edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema exists, and the action is simple (redo), the description is complete. The output schema is not described but that's acceptable per guidelines.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%, so the description does not need to explain parameter semantics. The baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Redo the last undone action') and the domain ('in Live'), making it specific and distinguishable from sibling 'undo'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the pairing with 'undo' is implied by the name and description, there is no explicit guidance on when to use or not use this tool (e.g., 'Use after undo' or 'No effect if no action to redo').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals the key behavioral trait: layering vs replacing. Annotations declare destructiveHint=false, which aligns. Adds useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, 14-word sentence that front-loads the purpose and effect. No unnecessary words, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple toggle with one parameter and an output schema, the description covers the essential function completely. No gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'enabled' (boolean) with 0% schema description coverage. While the param is self-explanatory, the description does not add any additional meaning or syntax guidance. Adequate but no value added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'toggle' and the resource 'arrangement overdub', and explains the effect: layering MIDI onto existing clips instead of replacing. This distinguishes it from siblings like 'set_record_mode' or 'set_session_record'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for layering MIDI recording but does not explicitly contrast with other recording modes or provide when/not guidance. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clarifies that this tool modifies routing settings and notes a prerequisite (get_device_routing) and a follow-up action (set_device_parameter for ducking). Annotations only provide destructiveHint=false, which is not contradicted. The description adds useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences covering the main action and parameter mappings, plus a brief note on ducking. It is front-loaded with the primary purpose. Minor redundancy could be trimmed, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 required parameters and an output schema, the description adequately covers the purpose and key parameters. It explains the usage pattern with get_device_routing and set_device_parameter. However, it omits details about track_index and device_index, and does not describe the return value (though output schema exists).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides useful explanations for two parameters: field (listing values) and display_name (from get_device_routing). It does not explain track_index or device_index, which may be obvious to domain experts but lack explicit documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets a device's sidechain audio input. The verb 'Set' and resource 'device routing' are specific. It distinguishes from sibling tools like set_track_routing and get_device_routing by specifying 'device's sidechain audio input'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context: it explains that display_name comes from get_device_routing and for ducking, one must also use set_device_parameter. However, it does not explicitly state when not to use this tool or compare with alternatives like set_track_routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=false, so the tool is non-destructive. The description correctly describes the view switch behavior. For a simple action, no additional behavioral details are necessary beyond what the annotation provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action. It contains no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with a simple purpose and existing output schema, the description is fully complete. It tells the agent exactly what the tool does with no missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, meeting the baseline of 4. The description does not add extra meaning beyond the schema, but no parameters means no additional detail is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Switch') and resource ('Ableton's main window to the Arrangement view'). It is specific and distinct from siblings like 'back_to_arranger' or 'set_arrangement_time', which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It omits context such as prerequisites (e.g., not in Arrangement view already) or relationships to similar tools like 'back_to_arranger'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description details the offline classification logic and return of verdict plus driving devices, adding value beyond the readOnlyHint annotation. It explains the tool is a read-only analysis without mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: starts with the primary purpose, provides details on the classification criteria, and ends with the returned information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple classification tool with one parameter and an output schema, the description is complete. It explains the classification logic, criteria, and output content, enabling the agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (path) with schema description coverage at 0%. The description does not clarify that path should be a file path to a .adg/.adv file, leaving ambiguity. The tool expects the agent to infer the parameter's purpose from context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool classifies the Live edition needed for a .adg/.adv file based on devices present. Lists specific device examples for suite, standard, and intro, and mentions returning verdict and driving devices. Distinguishes from siblings like adg_analyze or adg_summary by focusing on edition classification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly guides when to use: to check if a preset will load on the user's edition before loading it. No explicit when-not-to-use or alternatives mentioned, but the context of compatibility checking is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds further context: 'offline' and 'reviewing a mix without Live', reinforcing the non-destructive, offline nature. No contradictions, and it provides behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action ('Read mixing and arrangement detail') and efficiently conveys purpose, scope, and relationship to siblings. No extra words, every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description need not detail return values. It sufficiently lists the data read (locators, track volume/pan/automation lanes). While it lacks mention of error conditions or limitations, the tool is simple and the description is adequate for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter (path) with no description in the schema (0% coverage). The tool description does not add details about the parameter, such as expected format or constraints. However, the parameter is intuitively the file path to the .als file, so the omission is partially mitigated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads mixing and arrangement details from a saved .als file, listing specific data (locators, track volume/pan/automation lanes). It distinguishes itself from sibling als_summary as a complement, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is for offline review of a mix without Live, and it complements als_summary. While it doesn't explicitly state when not to use it or list alternatives beyond als_summary, the context is clear enough for an agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint=false, and the description adds context by explaining what a return track is (a send bus). It does not contradict annotations. However, no further behavioral details (e.g., permissions, side effects) are given, which is acceptable given the tool's simplicity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 13-word sentence with parenthetical clarification. It contains no filler or redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and an output schema (assumed but not shown), the description is largely complete. It could mention if the tool returns the created track, but the current text is sufficient for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (schema coverage 100%), so the description correctly omits parameter details. With zero parameters, a baseline of 4 is appropriate; the description adds no param info but doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb "Create" and resource "return track", with an explanatory parenthetical defining a return track as a send bus for reverb/delay. This distinguishes it from siblings like create_audio_track or create_midi_track.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via the parenthetical explanation (shared reverb/delay), but it lacks explicit when-to-use or when-not-to-use guidance relative to the many sibling tools. Usage is implied but not formally stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description explicitly mentions overwriting, consistent with destructiveHint annotation. Adds copy vs move distinction, but lacks details like automation behavior or session-only context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states action and side effect, second adds value proposition. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main purpose and side effect, but could clarify scope (session only, same set) and limitations. Output schema exists, so return values are handled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, and description does not explain parameters individually. However, parameter names (src_track, dst_scene) are self-explanatory, mitigating the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (copy a clip), target (any other track/scene slot), and side effect (overwrites destination). Distinguishes from siblings like duplicate_scene or delete_clip.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage as 'cross-track way to build variations' provides context, but no explicit when-not-to-use or alternatives among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=false indicates the tool is not destructive, and the description aligns by stating 'edit subset' without implying data loss. The description adds value beyond annotations by detailing the matching rule for removal (pitch+start) and that it does not rewrite all notes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two sentences, front-loading the purpose and then detailing parameter structures. Every sentence contributes essential information without redundancy or excess words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of editing notes with add/remove and the existence of an output schema, the description covers the core functionality well. It lacks explicit explanation for the required indices, but these are intuitive given the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the structure for 'add' and 'remove' parameters with specific fields (pitch, start_time, etc.) and the matching rule. However, it does not explain the 'clip_index' and 'track_index' parameters, which are required and could benefit from clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool edits a subset of notes in a MIDI clip without rewriting all, specifying the add (pitch, start_time, duration, velocity, mute) and remove (pitch, start_time) structures. This distinguishes it from siblings like add_notes_to_clip (which only adds) and delete_clip (which deletes entire clips).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage by explaining the tool edits a subset of notes without rewriting all, and specifies the matching rule for removal. However, it does not explicitly state when to use this tool versus alternatives like add_notes_to_clip, nor does it mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the destructive behavior ('REPLACES existing notes') consistent with the destructiveHint annotation. It also details voice-leading and style options, adding valuable context beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the purpose, followed by parameter details. It is efficient, though bullet notation is informal but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While most key parameters are covered, some (seed, velocity, beats_per_chord) are omitted. Given the tool's complexity and 10 parameters, the description could be more complete without being overly verbose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description adds meaning to parameters by explaining the progression format, style options, center_pitch bias, and other parameters. This compensates for the lack of schema comments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Write voice-led jazz chord voicings') and the resource ('into a Session clip'). It also distinguishes itself from siblings by specifying 'voice-led' and 'jazz voicings', which differentiates from simpler chord tools like generate_chord_progression.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for jazz voicings but does not explicitly state when to use this tool versus alternatives like generate_chord_progression. It notes that it replaces existing notes, but lacks guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, and the description aligns with 'get' behavior. It adds beyond annotations by specifying the path format. No contradictions. The description could mention that the browser contents are dynamic (openWorldHint) but is not required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a one-sentence purpose statement followed by parameter details. No unnecessary words. Well-structured with clear separation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown), so the description does not need to detail return values. The input parameter is well-explained. However, it lacks details such as case sensitivity, error behavior on invalid paths, or whether the result is items or subfolders. Given the output schema, this is acceptable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description adds meaning to the 'path' parameter: format 'category/folder/subfolder' and that category is a browser category. This is valuable beyond the schema. It could be improved by listing possible categories.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get browser items at a specific path in Ableton's browser.' It uses a specific verb ('get') and resource ('browser items at path'), distinguishing it from sibling tools like get_browser_tree (which gets the tree structure) and search_browser (which searches).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the path format 'category/folder/subfolder' and that 'category is one of the available browser categories,' which implies usage context. However, it does not explicitly state when to use this tool versus alternatives (e.g., get_browser_tree for discovering paths) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, making safety clear. Description adds that it lists only devices with curated guidance, but no further behavioral details (e.g., authentication, rate limits) are disclosed. Acceptable given the simple nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence with no wasted words. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values need not be described. The description fully explains what the tool does for a simple list operation. Could be slightly more detailed about the nature of 'curated guidance,' but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description correctly omits parameter details. Baseline score of 4 for zero-parameter tools is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool lists devices with curated guidance from describe_device. Verb 'List' and resource 'devices' are specific. Distinguishes from sibling 'describe_device' which provides details on a specific device.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies when to use: to see which devices have curated guidance. While not explicit about alternatives, the context of sibling tools and the specific scope provide clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so the description does not need to reiterate safety. The description adds the specific data returned (name, description, default tempo/key/scale/bars), which goes beyond annotations. However, no additional behavioral context (e.g., whether the list is exhaustive, any performance implications) is provided, keeping it at an adequate level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the core action and includes all essential information. No redundancy or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose and output fields. Since an output schema exists, the agent can rely on that for detailed structure. For a simple read-only listing tool, this is complete enough. One could argue for a 5 if it explicitly noted that the list is exhaustive or provided a note about performance, but it's still very good.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is 100%. The description does not need to explain parameters, but it adds value by describing the output content, which compensates for the lack of parameter detail. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (list) on a clear resource (built-in composition recipes) and lists the fields returned (name, description, default tempo/key/scale/bars). It also mentions the primary use case (for apply_recipe), distinguishing it from sibling tools like apply_recipe itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly guides usage by stating 'for use with apply_recipe', indicating it is a prerequisite step. No explicit when-not-to-use or alternative tools are mentioned, but the context is sufficiently clear for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-destructive behavior (destructiveHint=false). The description adds meaningful context by clarifying the value range and its mapping to crossfader positions (full A, center, full B), which is beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no wasted words. The description is front-loaded with the verb and resource, followed by parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, non-destructive), the description provides sufficient context. An output schema exists, so return values do not need explanation. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'value' has 0% schema description coverage, but the description fully explains its meaning and range (-1.0 to 1.0 with semantic mapping). This compensates completely for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set the master crossfader') and the resource ('master crossfader') with specific value ranges. It distinguishes from tools like set_crossfade_assign by focusing on the crossfader value rather than assignment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., set_crossfade_assign). The description only states what the tool does without providing context on prerequisites, appropriate scenarios, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-destructive behavior (destructiveHint: false). The description adds behavioral context by explaining the effect (instant beat variations) and the operation types (mute/solo/rename). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, 20 words, front-loaded with action and resource. No wasted words. Efficiently conveys core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is an output schema (not shown), the description doesn't need to explain returns. It covers the main purpose and parameters well, though could be more explicit about renaming and device selection. Overall fairly complete for a moderate-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It explains the 'note' parameter via an example and hints at 'mute', 'solo', 'name' parameters, but doesn't cover track_index or device_index. Partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it mutes/solos/renames a single Drum Rack pad identified by MIDI note, which is a specific verb and resource. This distinguishes it from sibling tools that work with clips, tracks, or other drum-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use it ('instant beat variations without touching the notes'), but does not explicitly state when not to use it or mention alternative tools among the many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only destructiveHint=false. The description adds context: it scales grooves globally. It does not mention other behaviors like reversibility or performance impact, but the added context is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence of 20 words, front-loaded with the action and resource. Every word is necessary, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool with one parameter, the description covers the essential behavior and parameter meaning. The output schema exists but is not referenced; however, the return value is not critical for a setter. Overall, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter with no description (0% coverage). The description compensates by specifying the valid range (0.0 to 1.0) and the effect of the parameter, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set', the resource 'global Groove Amount', the range '0.0 to 1.0', and the effect 'scales how strongly every clip's assigned groove is applied across the whole set'. It is specific and distinguishes from siblings like set_swing_amount.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (to adjust global groove amount) but does not explicitly state when not to use it or mention alternatives. Usage guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral context (range 0.0-1.0, 0.85 = 0 dB) beyond annotations. No contradiction with destructiveHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, highly concise and front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and tool is simple, the description is adequate; however, could mention if there are any side effects or return values beyond schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no description for 'volume' parameter), but the description compensates by specifying range and dB reference, providing essential semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and resource ('Main/Master track volume'), with specific range and reference point, distinguishing it from siblings like 'set_track_volume'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives (e.g., set_track_volume); usage is implied but no exclusion criteria or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide destructiveHint=false, so the description carries the behavioral burden. It discloses the exact mode mapping, the error condition, and gives stylistic context for slicing mode. No hidden side effects are mentioned, which is acceptable for a simple setter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose+mode mapping, context for slicing, error warning. No wasted words; each sentence adds value. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and presence of an output schema (content unknown), the description covers the essential behavior, mode options, and error condition. It could mention the return value or success signal, but it's adequate for a setter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for the 'mode' parameter by linking integers to modes and describing 'Slicing'. However, it does not describe 'track_index' or 'device_index' beyond their names, leaving their ranges and zero-based indexing implicit. With 0% schema coverage, more detail is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set a Simpler device's playback mode' with explicit mapping of integer values to modes (Classic, One-Shot, Slicing). It differentiates from siblings by specifying the device type (Simpler) and provides actionable context for the 'Slicing' mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an important precondition: 'Errors if the device at that index is not a Simpler', guiding correct usage. However, it does not explicitly state when to avoid this tool or recommend alternatives for other device types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include destructiveHint=false, so the description adds behavioral context: it enables sidechain sources, bus routing, and resampling with recording implications. While it does not detail all consequences (e.g., audio flow changes), it provides meaningful extra information beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using three short sentences to convey purpose, fields, and usage guidance. Every sentence adds value without redundancy, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Considering the tool's complexity (routing in a DAW) and that an output schema exists, the description covers purpose, fields, use cases, and a prerequisite. It does not discuss error conditions or potential side effects, but it is largely sufficient for an agent to understand when and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for parameters. The description compensates partially by listing valid values for the 'field' parameter and instructing users to get display names from get_track_routing, but it does not explain each field's function or provide constraints for track_index. Given low schema coverage, more detail would be expected for a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('Set') and resource ('track routing'), and distinguishes from siblings like get_track_routing. It lists the specific fields (input_routing_type, output_routing_type, input_routing_channel, output_routing_channel) and explains use cases like sidechain, bus routing, and resampling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance to 'Get options from get_track_routing first,' indicating a prerequisite for knowing valid display names. It also implies scenarios for sidechain and bus routing, but does not explicitly state when not to use this tool or contrast with alternatives like set_send.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by explaining that solo affects monitoring but not clip/device content, and that other tracks may stay soloed. This complements the idempotentHint and destructiveHint without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core action, followed by behavioral context and an alternative. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter, the description covers behavior, scope (regular track), and alternatives. An output schema exists, so return values are handled. It is mostly complete although it omits potential failure conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description repeats the boolean meaning and adds 'regular track' context, but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'set' and the resource 'regular track's solo state', with a specific action (solo or unsolo). It distinguishes from sibling tool 'set_track_mute' by directing users to use that for silencing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: solo changes monitoring and does not alter content, warns that other tracks may remain soloed and need manual clearing for exclusive auditioning, and suggests an alternative tool (set_track_mute) for silencing. It lacks explicit when-not-to-use scenarios but is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only destructiveHint=false in annotations, the description adds significant behavioral context: it creates tracks, sets tempo, searches browser for instruments, and returns per-track report. It does not disclose potential side effects on existing tracks or failure scenarios, but overall adds value beyond the sparse annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two brief paragraphs with front-loaded purpose, a clear example, and no redundant information. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality well, including return format. It omits edge cases (e.g., track array empty, instrument not found) and does not reference the output schema, but given the tool's complexity and schema gaps, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates well for the tracks parameter with an example and explanation of the instrument field. The tempo parameter is only mentioned as 'set tempo' without range or unit, leaving some ambiguity. Overall, the description adds most of the missing semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Bootstrap a session in one call: set tempo and create named MIDI tracks, optionally loading an instrument.' This specifies the verb (bootstrap/set/create) and the resource (session), distinguishing it from siblings like set_tempo or create_midi_track that handle single actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for efficient session setup ('in one call') but does not explicitly state when to use it versus alternative approaches like sequential calls. It provides details on the tracks format but lacks exclusion criteria or comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide destructiveHint: false. The description adds that the tool stops a preview, a non-destructive action. It doesn't detail side effects or prerequisites beyond the start action, which is adequate for a simple stop operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no extraneous information. It front-loads the purpose and references the related tool, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and a straightforward stop action, the description suffices. It mentions the prerequisite (preview started). While output schema exists, the description doesn't elaborate on return values, but for a simple stop, that's acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. The description correctly adds no param info, as the schema already exhaustively covers the interface.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Stop the browser preview') and explicitly ties it to its counterpart 'preview_browser_item', making the purpose unambiguous and distinguishing it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after invoking preview_browser_item, providing clear context. It does not explicitly state when not to use, but the pairing with the start action is sufficient for guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint=false, indicating a non-destructive operation. The description adds context about the prerequisite (armed/monitored track) and implies the tool reads MIDI playback without side effects. It does not contradict annotations and provides useful behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every word is meaningful. No wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless tool with an output schema, the description adequately covers the action and prerequisite. The output schema handles return values, so no further detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100% trivially. Per rubric, with 0 parameters, the baseline is 4. The description does not need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Grab recently played MIDI into a new clip (Live's Capture MIDI).' It uses a specific verb ('grab') and resource ('recently played MIDI', 'new clip'), effectively distinguishing it from siblings like create_midi_track or capture_and_insert_scene.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite ('Requires that MIDI was recently played into an armed/monitored track') but does not explicitly guide when to use this tool versus alternatives or when not to use it. Context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true. The description reinforces this by mentioning 'discard material' and 'copy notes', which imply modification. It adds useful behavioral context like transposition behavior and pitch=-1 meaning all pitches.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a single sentence with a list of operations. It front-loads the core purpose ('Structural clip edits') and efficiently packs details about each operation. Minor improvement could be breaking into clearer bullet points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 8 parameters (3 required) and presence of an output schema, the description covers the main operations and relevant parameters. It is sufficiently complete for an experienced user, though some edge-case behaviors (e.g., error handling) are not covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains the key 'op' parameter with examples and clarifies pitch=-1. It also provides context for region_start, region_length, destination_time within duplicate_region. Other common parameters (track_index, clip_index) are not described but are typically well-understood.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs 'Structural clip edits' and lists three specific operations (duplicate_loop, crop, duplicate_region) with brief explanations. It distinguishes itself from sibling tools like edit_notes or delete_clip by focusing on structural manipulations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what each operation does and when to use them (e.g., 'extend 2 bars to 4 before adding variation' for duplicate_loop). However, it does not explicitly state when not to use this tool or mention alternatives like edit_notes for note-level changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states that the tool replaces clip notes if the clip already exists, aligning with the destructiveHint: true annotation. It also details the algorithmic behavior of shifting and repeating motifs, providing full transparency about how the output is generated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two paragraphs and concisely covers the essential algorithm and parameters. It could be slightly more structured but avoids unnecessary verbosity, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, 2 required, output schema exists), the description covers the algorithmic logic and key parameter behaviors. It lacks detail for required parameters but overall provides sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant meaning by explaining the role of pitches, shift, repeats, note_length, and source_clip_index. However, required parameters track_index and clip_index are not described, though their purpose may be inferred from context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a Steve Reich phasing pattern into a Session clip, replacing existing notes. It explains the algorithm of building a motif from pitches and stacking shifted copies, which distinguishes it from sibling generation tools like generate_melody or generate_bassline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool for creating phasing patterns and mentions an alternative input via source_clip_index. However, it does not explicitly state when not to use it or compare to other generation tools, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true; description adds behavioral detail by listing returned fields (name, start_time, etc.), enhancing understanding beyond safety annotation. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise: two sentences and one parameter bullet. Every word adds value, no redundancy. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, one required parameter, and presence of an output schema, the description fully covers what the tool does and what it returns. No missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter track_index is described as 'The index of the track to inspect', which adds clear meaning beyond the schema's type and title. With 0% schema description coverage, this is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List all clips placed in the Arrangement timeline for a track' using specific verb-resource pairing. It distinguishes from sibling tools like get_clip_info (which likely targets session clips) by specifying 'Arrangement timeline'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly clear that tool is for listing arrangement clips, but no explicit guidance on when not to use or mention of alternatives (e.g., get_clip_info for detailed clip data). With many sibling tools, additional usage context would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, which the description aligns with. The description adds specific details about the returned data (index + name + global amount), providing behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence front-loading the action and output. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and the presence of an output schema, the description adequately specifies the return content (groove index/name and global amount). Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no parameters, so baseline is 4. No parameter information needed as schema is empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'list' and clearly identifies the resource 'grooves in the Groove Pool' and what information is returned (index, name, global groove amount). It distinguishes from sibling tools like 'set_clip_groove' which is a write operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidelines about when to use this tool vs alternatives. Since it's a simple read-only listing, the usage context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true; description adds listing of arrangement locators, consistent and minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, information-dense sentences with front-loaded action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present and description naming the listed fields, it is complete for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; description appropriately does not add param details. Schema coverage high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists arrangement locators with specific fields (index, name, beat time) and distinguishes from sibling tool jump_to_locator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly guides use for structure-aware navigation and chaining with jump_to_locator, but no explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds non-obvious details: the exact values for monitoring state (0=In, 1=Auto, 2=Off) and that routing options are identified by display_name. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose and a secondary sentence adding important usage guidance. No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one simple parameter, an output schema (indicated by context), and a read-only annotation, the description covers all essential aspects. It explains what is returned and how to use the data, making it complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter is track_index, which is simply titled in the schema. The description does not add further explanation beyond what the schema provides. Since schema description coverage is 0%, the description carries the burden but the parameter is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Read a track's input/output routing and monitoring state,' specifying a clear verb and resource. It also distinguishes itself from the sibling tool set_track_routing by explaining that the routing options are used with that tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to use the returned routing strings with set_track_routing, providing clear context on how to use the output. However, it does not list alternative tools or scenarios when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide destructiveHint=false, so the description adds value by clarifying it moves the playhead during playback. It could be more explicit about behavior when stopped or during record, but it adequately discloses the core behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, no unnecessary words. Perfectly concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description covers purpose, parameter meaning, and usage context completely. No missing information needed for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains the parameter 'beats' as a relative number, including that negative values move backwards. This adds sufficient meaning beyond the schema's 'type: number'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Move the playhead by a relative number of beats', specifying the exact verb and resource. It distinguishes from sibling tools like jump_to_cue and jump_to_locator by emphasizing relative movement and on-the-fly navigation during playback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Works during playback for on-the-fly navigation', which indicates when to use the tool. However, it does not explicitly state when not to use it or provide alternative tools for absolute jumps or stopped playback.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds value by noting that the first call records a baseline (no diff). This behavioral trait is beyond annotation scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating purpose first. It could be slightly more structured, but it effectively communicates needed information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the tool's relative complexity, the description covers the diff scope well. It does not need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100% (empty). The description doesn't need to add parameter info, so baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: reporting changes since the last call, listing specific elements like tempo, tracks, and per-track parameters. It distinguishes from siblings like als_diff and get_session_snapshot by focusing on session state differences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance: 'Call it before and after an edit to verify it took effect.' While it doesn't explicitly list alternatives or when not to use, the context is sufficient for correct tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-destructive behavior. The description adds that it sets key context and suggests checking current values via get_session_info, but does not disclose side effects, required permissions, or impact on other states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second provides parameter details and a pointer to the read tool. No redundant information; every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with an output schema present, the description covers purpose, parameter semantics, and a usage hint. It lacks explicit information about behavior when both parameters are null, but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, leaving parameters ambiguous. The description adds essential meaning: root_note mapping (0=C, 2=D) and scale_name examples (Major, Minor, Dorian), which is critical for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'song's key context'. It distinguishes from the sibling tool 'get_session_info' by indicating that tool reads current values, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to read current values via get_session_info, providing context for when to use this tool vs. a sibling. However, it does not explicitly state when not to use this tool or mention other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true. The description adds that analysis is offline and requires no Live, confirming no side effects. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is detailed but front-loaded with key purpose ('Full offline analysis'). Every sentence contributes value, listing specific outputs. Slightly verbose but efficient for the information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and that an output schema exists, the description covers all necessary aspects: purpose, usage, parameter, and expected outputs. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage for the single 'path' parameter. The description implies it is the file path but does not specify format or constraints. However, with only one parameter, the description adds sufficient meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'Full offline analysis' of .adg or .adv files, listing exact outputs (macros, device tree, samples, etc.). It clearly distinguishes from siblings like adg_summary or adg_edition by detailing a comprehensive analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'No Live required,' indicating when to use offline. However, it does not contrast with sibling tools like adg_summary or suggest when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as readOnlyHint=true. The description adds important behavioral context: the tool operates offline on saved files, not on a running Live instance. It also details the output fields, helping the agent understand return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences front-loaded with the core purpose, followed by a list of output fields and a brief parameter explanation. Every sentence serves a purpose without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameter meaning, output content, and a key usage constraint (offline). It lacks error handling or format details (e.g., path encoding) but is adequate for a single-parameter tool with an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description explains the 'path' parameter as 'a filesystem path to a .adg or .adv file'. This adds meaning beyond the raw type (string) and clarifies acceptable file formats. No additional constraints are given, but the explanation suffices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Summarize a saved .adg rack or .adv device preset WITHOUT Live running'. It lists specific output fields (name, rack type, etc.), making the function unambiguous. The verb 'summarize' and resource 'adg/adv preset' are specific, and the 'WITHOUT Live running' distinguishes it from sibling tools that may require Live.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the tool works 'WITHOUT Live running', which is a key usage condition. It does not mention alternatives or when not to use it, but the context is clear: for offline summary of preset files.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, so no destructive behavior. The description adds that it works without Live running and uses a specific algorithm (Krumhansl-Kessler). This is meaningful beyond annotations. It does not mention error handling or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no redundancy. First sentence states purpose and condition, second explains note pooling behavior, third details parameters. Every sentence is essential and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema (not shown). The description covers input semantics well but does not mention return format or error cases. Overall adequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full burden. It explains path as filesystem path, weight with listed options (duration, velocity, product, count), and track_index for optional single-track pooling. This adds value beyond schema titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects key/scale of a saved .als file without Live running, using Krumhansl-Kessler algorithm. It specifies the resource (.als file) and action (detect key), and distinguishes from siblings like detect_clip_key which operate on live session. The exclusion of 'WITHOUT Live running' adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use: for saved .als files offline, with options to pool from all clips or a specific track. It does not explicitly mention alternatives or when not to use, but the context is clear. More detailed guidance on weight selection would improve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is known to be safe. The description adds value by disclosing that no Live runtime is required and what data is extracted, enhancing the agent's understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the main action, no extraneous words. Every sentence earns its place by stating the purpose and the key constraint ('No Live required').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with one parameter and an existing output schema, the description fairly covers what the tool does and what it returns. It could mention file existence requirements, but those are typical and implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, and it does by implying the 'path' parameter refers to a '.als file' and listing the extracted clip attributes. It could explicitly state the file format expectation, but the context is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the exact action ('List every track') and resource ('saved .als file') with detailed attributes of clips. It clearly distinguishes from sibling tools like 'als_summary' by noting 'No Live required' and the scope of listing all tracks with clips.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 (when needing to enumerate tracks and clips from an .als file without Live). It implicitly excludes other ALS tools by its specificity, but could explicitly mention alternatives for contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it adds new tracks, does not overwrite existing ones, and attempts to load instruments. The destructiveHint annotation is consistent with adding tracks being a permanent change.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the key action, and every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers input, behavior, side effects, and relationship to list_recipes. An output schema exists, so return details are not needed. It is nearly complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by explaining `name` is a recipe from list_recipes, giving examples, and stating tempo/key/scale/bars override defaults. This adds significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scaffolds a genre starter, listing specific actions: set tempo, add Drums/Bass/Chords MIDI tracks, load instruments, write parts. It distinguishes from sibling tools like generate_bassline by being a one-call composite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (for quick genre template) and mentions `name` comes from list_recipes. It also notes it adds tracks without overwriting, providing context. However, it lacks explicit when-not-to-use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the behavioral state (orange 'Back to Arrangement') and the action of returning control, which adds value beyond the annotation 'destructiveHint=false'. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that immediately states the purpose and context. Every word is necessary and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description adequately explains the purpose and usage context. It could optionally mention that the action is reversible, but it is sufficient as is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. The description does not need to add parameter information; a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (return playback control to the Arrangement) and specifies the resource (Arrangement) and the context (after Session clips have overridden arrangement content, the orange state). It distinguishes itself from siblings like 'switch_to_arrangement_view' by focusing on control return rather than view switching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 (after Session clips have overridden arrangement content). However, it does not explicitly state when not to use it or mention alternatives, though the context is sufficient for an informed decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it mentions the version dependency, the requirement for an empty clip slot, and the need for an audio track. Annotations only provide destructiveHint=false; the description clarifies the mutation's nature and prerequisites. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: starts with the core action, then version requirement, then parameter list. Every sentence adds value without redundancy. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the three required parameters, the presence of an output schema, and the single annotation, the description covers all necessary preconditions and parameter semantics. It leaves no obvious gaps for an agent to misuse the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains all three parameters: track_index, clip_index, path. It adds contextual details (absolute path, audio file examples, preconditions) that the schema alone lacks, providing complete semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: creating an audio clip in an audio track's clip slot by importing a file. It distinguishes itself from siblings like 'create_clip' (which likely creates MIDI clips) and 'set_clip_audio' by specifying the import mechanism and track type. The version requirement adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides preconditions (target track must be audio, slot must be empty, requires Live 12.0.5+) but does not explicitly contrast with sibling tools or state when to use this tool over alternatives. Usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive (destructiveHint=true). The description adds behavioral context: later returns shift down after deletion, which is beyond what annotations provide. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the verb and resource. No unnecessary words; every part of the sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, destructive action, output schema exists), the description provides sufficient context for an agent to use it correctly. It covers the action, indexing, and side effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% so description must compensate. The description adds meaning: '0 = Return A' and the shifting behavior, which is not in the schema (only type integer). This helps the agent understand the parameter's semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a return track by index') and specifies the resource ('return track') with concrete detail ('0 = Return A'). It distinguishes from siblings like 'delete_track' by specifying the target type and index-based deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool: when a specific return track needs to be deleted by index. It does not explicitly mention when not to use it or alternatives, but the sibling 'delete_track' implies the distinction. The context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true is already present, and the description explicitly states 'REPLACES the clip's notes if the clip exists,' confirming the destructive behavior. It also details the standard drum map and the effects of swing and humanize, adding transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose. It uses line breaks to separate key info: purpose, replacement note, parameter details, drum map reference. Every sentence adds value, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and an output schema (not shown but present), the description covers core behavior, destructiveness, style, swing, humanize, and drum map. However, it does not explicitly state whether the clip must already exist or if the tool creates it, and track_index/clip_index are not explained. These are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains style (list), swing (meaning), humanize (meaning), and references the drum map. However, it does not explain bars, seed, track_index, or clip_index. While some parameters are common, the description adds moderate value but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a genre drum pattern into a Session clip on a Drum Rack track. It specifies the resource (Drum Rack track, Session clip), verb (write/generate), and lists genre styles. It distinguishes from siblings like generate_bassline or generate_chord_progression by focusing on drums and mentioning replacements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists style options and explains swing and humanize parameters, implying usage for drum pattern generation. It mentions the standard drum map, giving context for note numbers. However, it does not explicitly state when to use this tool versus alternatives like add_notes_to_clip or write_drum_grid, but the specificity provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds the practical behavior: reading output meters and what the values indicate (clipping). This enriches the agent's understanding beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, and every word adds value. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema exists, the description is adequate. It explains what the output means (clipping indicator), though it does not detail the exact output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and schema coverage is 100% (vacuously). Baseline for 0 parameters is 4, and the description does not need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it reads the Master track's output meters and provides an interpretation of the values (clipping near 1.0). It distinguishes itself from write tools like set_master_volume and get_master_device_parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool (to check for clipping) and even suggests a follow-up action (pull set_master_volume down). However, it does not explicitly state when not to use it or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include destructiveHint=false. Description adds that the tool does NOT load the item onto a track, clarifying no side effects. It also mentions the need to stop the preview with another tool. This goes beyond the annotation by describing the non-destructive preview behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant information. First sentence states purpose and constraint, second provides parameter source and complementary tool. Highly efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and an existing output schema, the description covers purpose, parameter source, and teardown. It could mention the return value briefly, but output schema handles that. Overall adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage for item_uri. Description compensates by explaining that item_uri comes from specific tools (search_browser or get_browser_items_at_path), providing provenance and meaning for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool auditions a browser item through Live's preview tab without loading it onto a track. The verb 'audition' and resource 'browser item' are specific, and it explicitly distinguishes from loading tools by saying 'WITHOUT loading it onto a track'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description tells when to use (to audition before loading) and provides source for item_uri (search_browser or get_browser_items_at_path) and complementary tool (stop_browser_preview). It lacks explicit when-not-to-use but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses key behaviors: real-time recording (time cost equals wall clock), a 5-minute cap, automatic cleanup of the temporary track (default true), and that it runs transport and adds an arrangement clip. These details add significant context beyond the annotation alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences long, effectively front-loading the main purpose. Each sentence adds unique value: purpose, process, time constraints, and return value. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, an output schema (not shown), and complex real-time behavior, the description covers all aspects: what it does, how it works (temporary track, routing, arming), time and cleanup constraints, and the return value (WAV path). It is self-contained and leaves no major gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains all four parameters: 'source' (Resampling or track name), 'cleanup' (keep track if false), and 'start_beat'/'end_beat' as the recording range. It provides meaningful context like 'Resampling = the master output' that is absent from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Bounce a section of the arrangement to an audio file WITHOUT the Export dialog'. It specifies the resource (arrangement section) and outcome (audio file), distinguishing it from sibling tools like 'create_audio_clip' or 'trigger_session_record' by emphasizing internal signal capture and real-time recording.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for hearing an internal signal and avoiding the Export dialog, but it does not explicitly state when to use this tool versus alternatives like 'create_audio_clip' or 'capture_midi'. No when-not-to-use or exclusion criteria are provided; guidance is only implied through the process description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint. The description adds useful behavioral details: search is by display name (case-insensitive substring), returns URIs for loading, and lists category options. It does not describe behavior for max_results or empty results, but overall adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences, front-loaded with purpose, no redundancy. Every sentence adds necessary information: search method, output, category filtering, usage recommendation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (search with substring, return URIs) and presence of an output schema, the description covers core behavior and category options. It lacks explanation of max_results and handling of no results, which are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description carries the burden. It explains query as display name substring and category with explicit options. However, max_results is not mentioned, leaving its purpose implicit. This is a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches the Ableton browser by display name (case-insensitive substring) and returns loadable items with URIs. It distinguishes itself from the sibling 'get_browser_items_at_path' by explicitly preferring this when you know a name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Prefer this over walking get_browser_items_at_path when you know a name.' This provides clear context for when to use vs. an alternative. However, no other exclusions or when-not-to-use scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond destructiveHint: false, description adds that it moves the playhead and explains time in beats, though does not mention playback state effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus parameter line, all useful, front-loaded purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with output schema, description fully covers purpose and parameter with no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds full meaning to the lone parameter (time as beats from start, with example), compensating for 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Describes moving the arrangement playhead to a specific position, clearly differentiating from siblings like jump_to_locator or playback controls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides example time value but no explicit when-to-use or alternatives, leaving usage context implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint and destructiveHint. The description adds that it only renames without altering notes or audio, and confirms idempotent behavior. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each adding value. Core purpose is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, and idempotency. Could more explicitly state the precondition that the slot must contain a clip, but this is implied and the tool is simple. Output schema exists, so return values are covered. Good annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description does not add new semantic details beyond what the schema provides, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('rename'), the resource ('existing Session-view clip'), and the constraint ('without changing its notes or audio'). It distinguishes from siblings like set_track_name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use this tool ('for the clip label') and when to use an alternative ('use set_track_name for the track label'). Also notes idempotency ('Repeating the same name has no additional effect').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the destructive behavior (overwrites source unless `dest_clip_index` is given), consistent with the `destructiveHint: true` annotation. It also details clamping of out-of-range pitches, ignoring `amount` for invert/retrograde, and requiring `amount > 0` for augment. This adds significant value beyond the annotations, though it could mention reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief overall statement followed by a clear bulleted list for each operation. Every sentence adds value, and there is no redundancy or extraneous information. It is optimally concise for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, multiple operations, output schema exists), the description covers the essential behaviors and parameter usage adequately. It does not need to explain return values due to the output schema. Minor missing details like the note range or exact behavior of 'write' could be included, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining the `op` values and how `amount` is used (semitones for transpose, time factor for augment, ignored for others). It also clarifies `dest_clip_index` behavior. However, `track_index` and `clip_index` are not elaborated, assuming obvious context, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Read a MIDI clip's notes, apply a classical motif transformation, and write the result.' It identifies the resource (MIDI clip) and specific verb (transform). The distinct operations (transpose, invert, retrograde, augment) are enumerated, making it easy to differentiate from sibling tools like 'edit_notes' or 'humanize_clip'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use the optional `dest_clip_index` to avoid overwriting. The four operations are described with their parameter requirements and effects. However, it does not explicitly state when not to use this tool or compare it to alternatives like 'edit_notes' or 'humanize_clip', leaving some ambiguity for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true and idempotentHint=true; description adds that it removes all automation points (not a time range), manual parameter state remains, and undo can recover accidental clears. This context goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core action, followed by prerequisite, behavior, and recovery. Every sentence is necessary and informative, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 required parameters, output schema exists, and destructive behavior, the description covers all essential aspects: what it does, prerequisite, behavioral details, and recovery path. Completely adequate for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by instructing use of get_device_parameters to resolve the 'parameter' argument, which is not obvious from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Delete...entire automation envelope') and resource ('one device parameter...from a clip'), clearly distinguishing it from siblings like write_automation and undo. It also mentions the prerequisite tool get_device_parameters, reinforcing its focused purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisite ('Resolve the device and parameter with get_device_parameters first') and contrasts with alternatives (write_automation for replacing envelope, undo for recovery). Does not explicitly state when not to use, but the context and exclusions are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation shows destructiveHint=false, and the description confirms non-destructive behavior by stating 'resume playback.' It also adds specific detail about the playhead position, going beyond the annotation to explain the exact behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with a parenthetical clarification, front-loading the core purpose. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description completely explains its action (resume playback) and distinguishes it from a sibling. No further context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema coverage is 100%, so the baseline is 4. The description does not need to add parameter information, and the tool's behavior is fully conveyed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Resume playback from the current position' and distinguishes from the sibling tool 'start_playback' which 'restarts from the playhead's last start point instead.' It uses a specific verb and resource, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts with 'start_playback' to guide when to use this tool (resume vs. restart). It provides clear context but does not elaborate on other situations where it might be inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only behavior with 'Reads only; changes nothing,' which reinforces the readOnlyHint annotation. Also mentions the algorithm (Krumhansl-Kessler) and the effect of the weight parameter. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four well-structured sentences. First sentence states purpose and method, second provides use case, third explains parameter, fourth states safety. No superfluous words, front-loaded efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, output schema present), the description covers all necessary aspects: purpose, usage, parameter meaning, and behavioral safety. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions in schema), but the description explains the 'weight' parameter with valid options ('duration', 'velocity', 'product', 'count'). The 'track_index' parameter is not described, but it is self-evident from context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('Detect the key/scale'), the resource ('whole track'), and the method ('pooling the notes of every Session clip it holds'). Distinguishes from sibling tools like 'detect_clip_key' and 'detect_session_key' by specifying the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use case: 'Useful when a part is spread across several clips.' This implies when to use this tool over single-clip alternatives, though it does not explicitly name the alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (idempotentHint false, destructiveHint false). The description adds behavioral context: it fires row clips together, can replace/stop clips based on slot launch behavior. This goes beyond annotations, though it could also mention what happens if no clips are in the scene.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a third for alternatives. No redundant information, front-loaded with the main action. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, clear annotations, and an output schema, the description is complete. It explains the launch behavior, replacement/stop effect, and offers alternatives. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the only parameter 'scene_index' is described as 'Zero-based Session-view scene (row) index.'). The tool description does not add new meaning to the parameter; it only reinforces the context. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Launch a Session-view scene') and the resource ('scene'), and distinguishes itself from sibling tools 'fire_clip' (single track) and 'start_playback' (Arrangement transport). Verb+resource is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: use for Session launching, not for single-track or Arrangement transport. Mentions launch quantization and slot behavior, giving clear context on when and how to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint and idempotentHint. The description adds that the tool fails for empty slots or audio clips, and mentions that newer Live versions may add expression fields. This provides useful behavioral context beyond annotations, though it could clarify behavior for empty vs non-existent clips.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a brief list of note fields, all front-loaded and to the point. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (not shown), the description provides sufficient context: what fields are returned, failure conditions, and sibling distinction. It is complete for a tool with good annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description. The description does not add additional meaning beyond the schema; baseline 3 is appropriate as it doesn't compensate further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states returning every MIDI note from an existing Session-view MIDI clip, providing a specific verb (return), resource (MIDI notes), and context. It distinguishes from siblings like get_clip_info by mentioning it is for notes and not clip properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use (existing session-view MIDI clip) and when not to (empty slot, audio clip). It explicitly recommends get_clip_info for clip properties, providing an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent and non-destructive behavior. The description adds value by noting out-of-range clamping and that it affects the full mix, going beyond annotation signals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two main sentences plus a one-sentence differentiator. Every sentence is essential and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity, full schema coverage, annotations, and existence of an output schema, the description adequately covers prerequisites, behavior, and alternatives, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for each parameter. The description adds no new parameter information but reinforces the need to get native min/max from get_master_device_parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the target ('one enabled parameter on a device in the Master track's chain'), distinguishing it from similar tools for regular and return tracks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises calling get_master_device_parameters first, explains clamping behavior, and names sibling tools for regular and return tracks, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds clamping behavior and prerequisite beyond annotations which already indicate idempotent and non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action, then context and alternatives; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With full schema coverage, output schema, and annotations, the description covers prerequisites, alternatives, and behavior adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description adds minimal extra meaning; clamping is already in schema value description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it sets a parameter on a device in a return track's chain, and distinguishes from siblings like set_device_parameter and set_master_device_parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to call get_return_device_parameters first and names alternative tools for other track types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the single annotation (destructiveHint: false), the description adds that the tool only affects clips and not the transport. This is valuable behavioral context. No further hidden behaviors are expected for such a straightforward action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the essential information. Every word is meaningful, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description fully informs the agent of the tool's purpose and effect. It is complete for its complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100%. The description adds no parameter details because none are needed. Baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Stop every playing Session clip') and distinguishes from stopping the transport, which is a related but different function. It uses specific verbs and resources, and the scope ('every playing Session clip') is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 this tool (to halt all playing clips without stopping playback). It implicitly excludes stopping the transport, but does not explicitly list alternatives or when-not-to-use cases. Still, the guidance is sufficient for a simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide destructiveHint=false. The description adds details: repeated taps set tempo, single tap nudges transport, and it returns the resulting tempo, which is beyond annotation data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences that are direct and efficient. Every word contributes meaning, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and an output schema, the description fully explains behavior and return value. It is complete for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description correctly omits parameter details; baseline 4 for zero parameters is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool taps tempo and explains the effect of repeated taps (set tempo) vs single tap (nudge transport). It distinguishes from siblings like set_tempo and transport controls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for interactive tempo setting by tapping, contrasting with direct tempo setting via set_tempo. No explicit when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reinforces the destructiveHint annotation by stating 'REPLACES existing notes' and details velocity mapping and instrument names. However, it does not mention potential side effects like clip creation or automation behavior, which would enhance transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, an example, and front-loaded purpose. Every sentence adds value, and the use of line breaks improves readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the custom ASCII grid format, the description is complete with instrument list, velocity mapping, and example. The output schema exists, so return values are not needed. No major gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by thoroughly explaining the 'grid' parameter with format, instruments, and example. The 'swing' parameter is mentioned but not detailed; 'track_index' and 'clip_index' are not described, leaving some burden on common knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool writes drums from an ASCII grid and replaces existing notes, providing a specific verb and resource. It distinguishes from siblings like generate_drum_pattern by emphasizing direct writing and replacement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clarifies that the tool replaces existing notes, but it does not explicitly state when not to use it or compare it to alternatives like add_notes_to_clip or edit_notes for non-destructive edits. The grid format and instrument list are well explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Reads the session; changes nothing,' which matches the readOnlyHint annotation and adds valuable behavioral detail about what it checks. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence lists specific checks, the second clarifies read-only nature and output. Information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a read-only analysis tool with no parameters. It mentions returning 'machine-readable findings,' which is sufficient given an output schema likely exists. Could optionally note it runs on the current set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters; schema coverage is complete. The description does not need to add parameter info, and it implicitly covers the tool's functionality without parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines what the tool does: scan for common mix problems like tracks at 0 dB, muted/empty tracks, MIDI with no instrument. It uses specific verbs and resources, and it distinguishes from sibling tools by being an analysis-only tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when you need to check for mix problems before fixing) but does not explicitly state when not to use or mention specific alternatives among the many sibling tools. It could be more directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, description adds atomic-like behavior details: stops at first error, completed steps are a single undo away. Also mentions auto-translation of command names. Does not cover full error response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured and front-loaded with key idea. Slightly redundant with examples but overall efficient. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main points: purpose, usage, limitations (non-batchable tools), format. With output schema present, return value explanation is not needed. Could mention batch size limits or more error details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description fully defines the commands structure with examples: array of objects with 'type' and 'params', and notes auto-translation of names. Compensates completely for schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool runs several commands in one round-trip and undo step. It uses specific verbs 'run' and 'batch', and distinguishes from sibling tools by being a batch operation vs individual commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (prefer for multi-step edits) and when not to use (composite tools are not batchable). Provides alternatives by listing non-batchable tools by name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes failure conditions and length units beyond annotations (destructiveHint: false). Discloses that clip creation fails if slot occupied or track is audio, adding context. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, preconditions/length explanation, and typical usage chain. All sentences are essential, no waste, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, key parameters, failure modes, and usage flow. Output schema exists so return value explanation is unnecessary. Could mention defaults for empty clip (e.g., no notes), but generally complete for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% coverage, but description explains length parameter in beats (4.0 = one 4/4 bar). It indirectly clarifies clip_index and track_index by referencing 'Session slot' and failure when slot has a clip. Adds significant value for a low-coverage schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create an empty MIDI clip in a Session slot', using a specific verb and resource. It distinguishes from sibling tools like create_audio_clip and add_notes_to_clip by specifying MIDI and slot context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states failure conditions (slot occupied, audio track) and suggests alternatives (pick another clip_index or delete_clip). Provides a typical usage chain: create_clip -> add_notes_to_clip -> fire_clip/duplicate_to_arrangement, guiding when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Aligns with annotations (readOnlyHint: true) by stating 'Reads only'. Adds detailed behavioral context: algorithm (Krumhansl-Kessler), return values (best-fit key, confidence range -1..1, margin, runner-up), and weight parameter effect. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the primary action, no redundant text. Efficiently conveys purpose, behavior, and parameter guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers return values. However, it omits edge cases (e.g., empty clips) and does not explicitly require the clip to be MIDI. Still, it is mostly complete for a straightforward read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains the weight parameter's possible values ('duration', 'velocity', 'product', 'count') and its role in pitch-class histogram weighting. For clip_index and track_index, context from the tool name and description implies their meaning as clip identifiers. Adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'detect', the resource 'key/scale of one Session MIDI clip', and the algorithm (Krumhansl-Kessler). It distinguishes from sibling tools like 'als_detect_key' and 'detect_session_key' by specifying it operates on a single clip in Session view using track and clip indices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Reads only; changes nothing,' clarifying appropriate use cases. While it doesn't list alternative tools, the context of session clip focus vs. sibling tools like 'detect_track_key' provides implicit guidance. Some explicit when-not-to-use would improve it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Reads only,' matching the readOnlyHint annotation. It adds context about pooling notes from all MIDI tracks' Session clips and the algorithm used (Krumhansl-Kessler), which goes beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a parameter note, all front-loaded with the core purpose. Every sentence adds value with no redundancy or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's purpose (key detection), the description covers the algorithm, scope, parameter options, and read-only nature. With an output schema present, return values need not be detailed. The description is complete for an AI agent to understand and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description fully explains the single parameter 'weight,' listing its possible values ('duration', 'velocity', 'product', 'count') and their meaning (histogram weighting). Since the schema provides no enum or description, this adds critical semantic clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects the overall key/scale of the whole set by pooling notes from all MIDI tracks' Session clips using the Krumhansl-Kessler algorithm. This distinguishes it from sibling tools like detect_clip_key and detect_track_key which focus on individual clips or tracks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the tool is for detecting the harmonic center of the entire arrangement, implying it should be used when an overall key is needed rather than per-track or per-clip. However, it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description does not need to repeat that. The description adds value by listing what is included in the snapshot. However, it does not mention potential limitations like performance cost or missing details (e.g., devices beyond names).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first efficiently lists included data, the second gives a usage recommendation. No superfluous words; information is front-loaded and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no inputs and returns a comprehensive snapshot, the description covers the main data points. It could be more explicit about what is not included (e.g., device parameters, routing), but with an output schema present, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered. The description adds context about the snapshot's contents, which is helpful beyond the empty schema. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a one-call overview of the entire set, listing specific items like tempo, time signature, play state, and per-track details. It distinguishes itself from siblings like get_track_info by explicitly recommending it over many individual calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit guidance: 'Prefer this over many get_track_info calls.' This directly tells the agent when to use this tool versus alternatives, providing clear context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds behavioral details: 'omitted fields stay unchanged', 'end must be after start', and clarifies the role of each parameter. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose, followed by usage rule, parameter explanations, and sibling differentiation. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (though not shown) and annotations are present, the description covers purpose, usage, parameter semantics, and alternatives. It could explicitly mention required fields (track_index, clip_index) but schema covers them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with basic descriptions. The description adds meaningful context: start/end are 'loop-brace positions in clip-relative beats', start_marker controls 'non-looped launch beginning', looping enables/disables repetition. This goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Update') and resource ('selected loop and launch markers on one existing Session clip'). It clearly distinguishes from sibling tools like set_loop (global loop) and get_clip_info (inspection).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool vs alternatives: 'Use set_loop for the Arrangement's global loop region, not a clip, and get_clip_info to inspect current values.' Also advises to provide at least one optional field.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint: false), the description discloses the critical behavioral quirk that the response reflects the state before the command, which could be misleading. This transparency helps the agent avoid misinterpretation and correctly verify the state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences with no unnecessary words. The first sentence states the purpose, and the second adds a crucial note. It is front-loaded and efficient, earning a top score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists (context signal), the description covers the essential functionality and provides an important caveat. It could mention behavior if playback is already active, but overall it is sufficient for a simple command.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100% by default. The description adds no parameter details, but none are needed. A score of 4 (baseline for zero parameters) is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start Arrangement playback') and specifies the starting point ('from the current song time'). It distinguishes this from related tools like 'continue_playing' by implying it starts fresh from the current time, not resuming a paused state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance about the pre-command state reporting and recommends confirming with 'get_session_info'. This helps the agent understand how to interpret the response and take follow-up actions. It does not, however, discuss when not to use this tool (e.g., if already playing) or compare to 'continue_playing'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-destructive and non-idempotent; description explains shifting behavior for indices and empty track creation. However, it does not cover corner cases like out-of-bounds indices, but this is minor given schema constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences: first states purpose, second explains param behavior and alternatives. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema and clear annotations, the description covers purpose, usage, and behavior sufficiently. No missing elements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a good schema description, and the description adds value by explaining the shifting behavior of indices beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Insert an empty audio track at a chosen position') and resource, and explicitly distinguishes from siblings by suggesting alternatives (create_midi_track for instruments/MIDI, create_return_track for send bus).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use (audio track insertion) and when-not-to (use alternatives for MIDI or return tracks), along with parameter behavior for index values.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate destructiveHint=true. The description adds crucial behavioral traits: it deletes content, leaves slot empty, does not shift indices, and fails on empty slots. It also suggests using undo for reversal, implying irreversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences efficiently convey purpose, behavior, and usage alternatives. No wasted words, and key information is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 params, output schema exists), the description covers the action's effect, failure condition, and alternatives. It is complete enough for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description does not add parameter-specific details 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete the existing Session-view clip in a slot, including its content,' which specifies the action (delete) and the resource (Session-view clip). It also distinguishes from siblings like stop_clip and undo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use alternatives: 'Use stop_clip if the intent is only to stop playback; use undo immediately if the deletion was accidental.' It also notes that it fails for an empty slot, implying when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds behavioral context by describing the tool as a map and mentioning orientation, consistent with read-only nature. Does not disclose additional side effects, but annotations cover the safety profile adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load the purpose, then add supplementary information about toolsets and alternatives. Every sentence adds value; no redundancy or wasted phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and presence of output schema, description adequately covers what the tool returns (tool groups, conventions) and how to use it for orientation. It is complete for its intended role as a high-level overview tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in input schema (0 params), so description has no obligation to add param info. Baseline 4 is appropriate. The description does not mention parameters, but none exist to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool provides a high-level map of server tool groups and conventions, aiding orientation before first call. It distinguishes itself from siblings by explicitly naming alternative tools for specific use cases: get_session_snapshot for live state, analyze_mix for mix problems.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this tool for initial orientation before first call. It provides clear when-not-to-use guidance by directing to get_session_snapshot for current live state and analyze_mix for mix problems, with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses side effects: 'creates new content and increases the scene count; later scene indices shift to make room.' Annotations show destructiveHint: false, which is consistent. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the main purpose, and every sentence adds value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, full schema coverage, and an output schema present, the description covers the tool's purpose, side effects, and alternatives thoroughly. It is complete for an AI agent to understand when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema's description of scene_index; it only explains the tool's overall behavior, not the parameter itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Insert a copy of one Session scene, including every clip in its row.' It uses a specific verb (insert copy) and identifies the resource (scene). It also distinguishes from sibling tools by mentioning duplicate_track and duplicate_clip_to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use alternatives: 'Use duplicate_track for a whole track or duplicate_clip_to for one clip.' It also suggests a use case: 'Use the new scene as an editable section variation.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=false), the description reveals creation of new content, increase in track count, and index shifting, giving the agent full understanding of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences efficiently convey core action, side effect, and alternatives. No fluff, front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, simple action) and the presence of an output schema, the description covers purpose, side effects, and alternatives comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description does not add extra semantics to the single parameter (track_index) beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Insert a copy of one regular track, including its devices and clips') and distinguishes from sibling tools by mentioning 'Use duplicate_scene for a Session row or duplicate_clip_to for one clip.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use alternatives (duplicate_scene, duplicate_clip_to) and suggests post-duplication actions ('Rename or edit the copy to create a variation').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations idempotentHint=false and destructiveHint=false are not contradicted. The description adds important behavioral context: launching takes Session control, replaces other clips, and may retrigger an already-playing clip.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then details and alternatives. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has output schema, and the description covers preconditions, behavior, and alternatives, making it complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description does not add extra parameter meaning 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Launch one existing Session-view clip using Live's launch quantization,' clearly stating the verb and resource. It distinguishes from siblings by mentioning fire_scene and continue_playing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use fire_clip ('The slot must contain a clip'), describes its behavior, and provides alternatives: 'Use fire_scene to launch a whole row, or continue_playing for transport only.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds value by detailing exactly what is read (scale name, root note, intervals, tuning system) and mentions the tuning system context (microtonal, Live 12.3+). Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Purpose is front-loaded, and cross-references to related tools are provided concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and a clear output schema, the description fully explains what the tool returns and provides context on tuning system. It also links to setter tools. Sufficient for agent to correctly invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters. Schema coverage 100%. Description does not need to add parameter info; baseline 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Read' and resource 'the song's scale and tuning', listing exact items. It distinguishes from sibling set_song_scale by noting that tool sets the scale while this reads it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (to read) and provides alternatives: 'Set the scale with set_song_scale; tune device parameters with set_device_parameter.' Gives clear when-not and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool does not modify the set, which aligns with the readOnlyHint and idempotentHint annotations. It further discloses the detailed return contents, adding context beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: main purpose, list of return fields, and sibling references. Every sentence is valuable, and the key info is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description does not need to detail return values. It covers all necessary context including what is included and how it differs from siblings, making it complete for the one-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the single parameter with 100% description. The description adds context that the track must be a regular track, but does not significantly extend beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns detailed state for one regular track without modifying the set. It uses a specific verb 'Return' and resource 'regular track', and distinguishes from siblings by listing alternative tools for different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (for detailed track state) and when to use alternatives (get_session_info, get_device_parameters, get_clip_info), providing clear guidance for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses non-idempotent behavior ('repeated calls add duplicates') and that loading selects the return track. This adds significant context beyond the annotations (idempotentHint=false, destructiveHint=false). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences. First sentence defines purpose, second adds behavioral details, third provides usage context. No wasted words, front-loaded, and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained. The description covers behavioral side effects, prerequisites (search_browser), and usage context. For a simple two-parameter tool, this is fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents both parameters thoroughly. The description reiterates the schema's info (obtain item_uri from search_browser, zero-based index) but adds little new semantic value. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Append one loadable browser device or preset to a return track's chain,' specifying the action (append) and target (return track). It distinguishes from sibling tools by naming alternatives: 'use load_instrument_or_effect for a regular track or load_device_to_master for the Master chain.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent to obtain item_uri from search_browser. Provides contextual advisory: 'Prefer audio effects on returns' and warns about repeated calls creating duplicates. Directs to alternatives for different track types, making usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the exact behavior of restoring overridden automation and adds the critical note that setting a device parameter with an envelope overrides it until this tool is called, which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, purpose front-loaded, critical note included without extra fluff; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and presence of output schema, the description completely covers the tool's purpose, trigger, and behavioral note; no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no parameters, so description does not need to explain them; baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool restores automation overridden by manual changes, using specific verbs and resource context, distinguishing it from siblings like clear_automation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (when automation overridden) and includes an important warning about parameter setting overriding envelopes, but doesn't compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (idempotentHint=true, destructiveHint=false), the description adds that no content changes and it's purely visual, reinforcing safety and non-destructiveness. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the primary purpose. Every sentence adds value: purpose, visual-only nature, alternative tool, and idempotency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given annotations and schema, the description covers purpose, usage boundaries, behavioral traits, and idempotency. No gaps remain for an agent to correctly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description does not add new parameter-level context beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb ('Set') and resource ('existing Session clip's palette color'), clearly stating the tool's function. It explicitly differentiates from sibling tool set_track_color by noting the latter is for track header recoloring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use for visual organization only, and directs to set_track_color for track header changes. It also notes idempotency (repeating same color no effect), helping agents decide when to call the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already provide idempotentHint=true and destructiveHint=false. The description adds critical behavioral context: that the tool does not move the crossfader or change track volume immediately, and that repeating the same assignment has no additional effect. This clarifies the exact scope of the tool's action, which is beyond what annotations alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: four sentences covering purpose, behavior, recommended next step, and idempotency. Every sentence adds value and no word is wasted. It is front-loaded with the core action, making it easy for an agent to quickly understand the tool's primary function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool is simple (2 parameters, no enums, no nested objects), the description, annotations, and schema together provide a complete picture. The description explains what the tool does, what it does not do, the correct usage pattern, and idempotency. The presence of an output schema (though not detailed) and clear annotations further ensure the agent has all necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameters with clear descriptions (e.g., assign: '0 is A, 1 is none, 2 is B'; track_index: 'zero-based index of a regular track'). The description does not add new parameter details beyond stating the track is regular and the assignment options are A/none/B. Since schema coverage is high, the description's marginal addition is minimal, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Assign one regular track to crossfader side A, neither side, or side B') using a specific verb and resource. It distinguishes from the sibling tool 'set_crossfader' by noting that this does not move the crossfader, and explicitly mentions that repeating the same assignment has no effect, which differentiates it from other track operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it says this tool does not move the crossfader or change volume, and directs the agent to 'use set_crossfader afterward to blend the A/B groups.' It also implies when not to use (if immediate volume change is needed) and hints at idempotency by stating repeating has no effect. This completely addresses when and how to use the tool alongside alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that enabling alone does not record, and repeating state has no effect, confirming idempotentHint annotation. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: front-loaded with main action, then parameter explanation, then usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 bool param, output schema exists), the description fully covers behavior, usage, and constraints. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with description for the single boolean parameter. Description adds 'true enables recording; false disables it' but mostly repeats schema info. Baseline 3 adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it arms or disarms Live's global Arrangement Record state, with specific verb+resource. Distinguishes from sibling tools like set_session_record and trigger_session_record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (for Arrangement Record) and when to use alternatives (set_session_record/trigger_session_record for Session slots). Also explains prerequisites (arm tracks, start playback) and idempotency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint and destructiveHint, but the description adds value by explicitly stating 'without changing any clips' and 'repeating the same name has no additional effect,' which aligns with and elaborates on the annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two short sentences. The first sentence states the core purpose, and the second adds alternatives and idempotency. No wasted words, front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple rename tool with two parameters and an output schema, the description covers the action, side effects (no clip changes), idempotency, and sibling differentiation. It provides all necessary context for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already defines both parameters ('name' as display name, 'scene_index' as zero-based index). The description does not add additional semantic detail beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renames one Session-view scene and explicitly notes it does not change clips. It provides a specific verb ('rename') and resource ('Session-view scene'), and distinguishes from the sibling tool 'set_clip_name'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Use set_clip_name for an individual clip.' This tells the agent when not to use this tool and directs to the correct alternative. It also notes that repeating the same name has no additional effect (idempotency).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false. The description adds value by explaining that it changes bar/grid and metronome interpretation but does not rewrite clip notes, and that repeating the same signature has no additional effect. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences front-load the purpose and scope, immediately followed by usage guidelines and behavioral notes. No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers purpose, usage boundaries, safety (idempotent, non-destructive), and parameter scope. The output schema exists (not shown) but the description's focus on input is adequate for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters having descriptions that explain meaning (e.g., 'Number of beats per bar' for numerator). The description does not add new information 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'set' and the resource 'Live set's global time signature', with concrete examples like 4/4, 3/4, 6/8. It distinguishes itself from the sibling tool 'set_clip_signature' by specifying scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use this tool (global time signature) versus when to use an alternative ('Use set_clip_signature instead when only one clip needs a different meter for polymeter'). Also states that repeating the same signature has no effect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond idempotent and non-destructive annotations by explaining what muting does ('silences that track in Live but preserves its clips, devices, and mixer settings'). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, front-loaded sentences with no wasted words. Action stated first, then behavior, then usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, behavior, usage guidelines, and parameter meaning. No gaps for a simple 2-parameter tool with output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description repeats 'true mutes; false unmutes' which is already in schema. Does not add extra meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Set one regular track's mute state' and immediately explains the effect. It distinguishes from siblings by mentioning set_track_solo and stop_clip, providing specific alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool vs alternatives: 'Use set_track_solo to audition a track relative to the rest, or stop_clip when only Session clip playback should stop.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds that it returns guidance (no side effects). It also notes case-insensitivity of device_name. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two front-loaded sentences plus parenthetical examples. No wasted words; all information serves a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, output schema exists, and annotations present, the description fully covers purpose, parameter details, and sibling context. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no description for device_name (0% coverage). The description compensates by listing example values and stating case-insensitivity, adding essential meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns 'curated guidance' for an Ableton device, specifying what the guidance includes (parameters, units, values, mixing tips). It also lists example device names, distinguishing it from sibling tools like get_device_parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to pair with get_device_parameters for live indices and ranges, providing a clear alternative. Context implies when to use: when needing curated insights rather than raw parameter data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'OVERWRITES whatever already occupies the destination range... like recording over tape - this is also the supported way to REPLACE a section,' adding significant behavioral context beyond the destructiveHint annotation. It also mentions the underlying API and Live version compatibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence, behavioral notes, workflow, and parameter list. Every sentence adds value, and the length is appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description need not explain return values. It covers purpose, behavior, parameters, and typical usage, making it complete for an AI agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite the input schema having no descriptions (0% coverage), the description explains each parameter: track_index (track owning clip), clip_index (clip slot in Session), destination_time (beat position in arrangement). This fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Copy a Session-view clip into the Arrangement timeline,' specifying the exact action (copy/duplicate) and resource (Session clip to Arrangement). It distinguishes from siblings like 'duplicate_clip_to' and 'delete_arrangement_clip' by focusing on the specific Session-to-Arrangement operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a typical workflow (create clip, duplicate_to_arrangement, switch_to_arrangement_view) and explains that it overwrites content, implying use for placement/replacement. It does not explicitly state when not to use it, but the context is clear given the workflow and sibling operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true (safe read) and openWorldHint=true (output variability). The description adds behavioral context that the tool returns a shallow listing (no deep hierarchy). While it doesn't detail output format, the presence of an output schema compensates. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences and a list of parameter values. It front-loads the purpose, includes a crucial NOTE, and uses no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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, annotations present, output schema provided), the description fully covers purpose, usage boundaries, parameter semantics, and behavioral traits. It is complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions), but the description enumerates all possible values for 'category_type' (all, instruments, sounds, drums, audio_effects, midi_effects), adding critical meaning beyond the schema's generic string type with default. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists the browser's top-level categories and immediate entries, with specific verb and resource. It distinguishes itself from sibling tools by noting it returns a shallow listing, and mentions alternatives like get_browser_items_at_path for deep hierarchy and search_browser for known names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (for shallow listing) and when to use alternative tools (get_browser_items_at_path for deeper drill-down, search_browser when you know a name). This provides clear usage context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the two-step mutation process, potential failure mode (empty rack remains), and that repeated calls add more racks. Annotations are minimal (non-idempotent, non-destructive) and description adds crucial context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is somewhat long but each sentence serves a purpose. Well-structured: action, prerequisites, behavior, alternative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 required params, 100% schema coverage, and output schema present, the description covers purpose, prerequisites, side effects, and alternatives completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by explaining the relationship between rack_uri and kit_path, giving an example for kit_path, and clarifying track_index is zero-based.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action: load a Drum Rack and then the first loadable kit at a browser path. Distinguishes from sibling tool load_instrument_or_effect by specifying the two-step process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use prerequisites: search_browser and get_browser_items_at_path. Provides clear alternative: use load_instrument_or_effect for a single known URI.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms the destructive nature (replace entire notes) which aligns with the destructiveHint annotation. It adds behavioral context beyond annotations by specifying the operation replaces all notes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences: purpose, alternative, parameter format and precondition. No fluff, front-loaded with action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the tool's simplicity, the description covers purpose, parameter details, precondition, and alternative. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds significant meaning for the 'notes' parameter by detailing its structure (pitch, start_time, etc.). However, 'clip_index' and 'track_index' lack additional semantics beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'REPLACES the clip's entire note content', providing a specific verb and resource. It distinguishes itself from the sibling 'edit_notes' by contrasting replacement vs. subset modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly contrasts with 'edit_notes' for subset operations, and includes a precondition (clip must exist). This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a side effect (moves playhead to time) and explains the internal reason, adding behavioral context beyond the destructiveHint: false annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear front-loaded purpose and a separate paragraph for side effects and alternatives, no unnecessary verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the main behavior, side effect, and usage context, and output schema exists to handle return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema coverage is 100%, the description adds important context about the time parameter's side effect and the rename behavior for name, improving understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or renames an Arrangement locator at a specific beat position, distinguishing it from sibling tools like set_arrangement_time and get_locators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when to use alternatives: 'Use set_arrangement_time when only the playhead should move, and get_locators to inspect existing markers.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant context beyond the destructiveHint annotation, detailing exact destructive behavior: 'creates a clip when the slot is empty; otherwise resizes its loop and replaces every existing note'. This fully discloses the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear first sentence defining purpose and a well-structured second paragraph covering behavior, prerequisites, format, and alternatives. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (making return value documentation unnecessary), the description covers all essential aspects: purpose, destructive behavior, prerequisites, input format, and alternatives. It's fully complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description still adds value by explaining chord symbol format and listing supported qualities, which is domain-specific guidance not present in the schema. This goes beyond the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Generate voiced chords and write them into one Session-view MIDI clip', specifying the resource and action. It distinguishes from siblings like add_notes_to_clip and edit_notes by giving explicit alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (generating chord progressions) and when not to, referencing specific alternatives ('Use add_notes_to_clip for exact notes or edit_notes to preserve existing ones'). It also notes a prerequisite: 'The track must accept MIDI'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it does not modify the set, aligning with annotations readOnlyHint and idempotentHint. It details the returned data (tempo, time signature, etc.), adding value beyond annotations with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and is concise. Every sentence adds value, including the alternative tools at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and presence of an output schema, the description fully covers the tool's purpose and return values, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so no parameter explanation is needed. Baseline of 4 applies as there is nothing to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return global Live-set and transport state without modifying the set' and lists specific data (tempo, time signature, etc.). It distinguishes from siblings by mentioning get_track_info and get_session_snapshot as alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool ('without modifying the set') and provides alternatives for track-specific or compact overview needs, guiding correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by disclosing that the API support is conditional ('if the Live API supports it (it does not on most versions)') and explains the return behavior (whether the API call is available and whether the save succeeded). This provides critical behavioral context that annotations alone do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The first sentence delivers the core purpose, and the second adds essential nuance and an alternative. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers all necessary context: the action, the API limitation, the return values, and an alternative. It is complete and informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description naturally has no parameter information. With 0 parameters, the baseline is 4. The description implicitly clarifies that no parameters are needed because it saves the current set.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves the current Live set to its existing file, with the verb 'save' and resource 'current Live set'. It distinguishes from saving under a new name by referencing the GUI Save-As, which differentiates it from any sibling tools that might handle save operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool (to save to the current file) and provides an alternative for saving with a new name/path ('use the GUI Save-As'). This is clear guidance on when to use versus not use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and destructiveHint=false. Description adds behavioral detail: true turns device on, false bypasses while preserving device and parameter values, and clarifies it changes audible signal flow but not clip content. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two paragraphs, well-structured. First sentence is a clear summary, followed by a bullet-style explanation. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (boolean toggle) and that an output schema exists, the description fully covers behavior, parameter effects, and alternatives. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions. Description adds extra meaning by explaining the effect of true/false on the device (bypassing preserves device and parameter values), going beyond the schema's simple 'True turns on; false turns off.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Enable or bypass one device on a regular track.' Uses specific verb+resource and distinguishes from siblings like set_track_mute and set_device_parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool vs alternatives: 'Use set_track_mute to silence the whole track, or set_device_parameter to change one control.' Provides context on what this tool does (changes audible signal flow but not clip content).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (idempotent, non-destructive), description adds that the region is updated even when enabled=false and playback will not repeat. This gives agents full understanding of side effects without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs, each sentence earns its place. Front-loaded with purpose, then clarifies parameters and alternative tool. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and annotations, description fully covers what agents need: what it does, parameter semantics, behavioral nuance, and when to use alternative. Complete for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, so baseline is 3. Description adds meaning beyond schema: 'start is an absolute beat', 'length is a positive beat duration', and clarifies enabled's effect (region updates but no repetition). This adds significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it sets the global Arrangement loop region and its enabled state, with specific verb 'Set' and resource 'global Arrangement loop region'. It distinguishes itself from the sibling tool 'set_clip_loop' by explicitly naming the alternative for Session clip loops.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (for Arrangement loop) and when not to (use set_clip_loop for Session clips). Also explains behavior when enabled=false, providing clear context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false. Description adds clamping behavior and side effect (changes mixer state, non-destructive to audio), which are beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences, no fluff. Front-loaded with purpose and clear structure. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity, full schema coverage, and presence of annotations and output schema, description covers purpose, behavior, side effects, and alternatives. Complete for an agent to use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3. Description adds '0.0 is centered' and clamping behavior, providing meaning beyond the schema's just range. Extra value justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Set one regular track's stereo pan position' with specific verb and resource. It distinguishes from sibling tools by mentioning alternatives: 'Use set_master_device_parameter for a device control, and set_crossfader for A/B crossfading.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says Live clamps the value to the track's native range, and clarifies it changes mixer state not audio content. Provides explicit alternatives, giving clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ableton-live-mcp MCP server](https://glama.ai/mcp/servers/wstierhout/ableton-live-mcp/badges/card.svg)](https://glama.ai/mcp/servers/wstierhout/ableton-live-mcp)

Score Badge

Copy to your README.md:

[![ableton-live-mcp MCP server](https://glama.ai/mcp/servers/wstierhout/ableton-live-mcp/badges/score.svg)](https://glama.ai/mcp/servers/wstierhout/ableton-live-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/wstierhout/ableton-live-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server