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

With no annotations, the description carries the full burden. It explains the action but omits side effects, prerequisites (e.g., whether an existing track is required), or whether existing automation is replaced. It also does not describe error behavior or limitations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured, using bullet points for targets and parameters. It is concise, with no unnecessary verbosity, and each piece of information is relevant and directly tied to the tool's operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the core action and parameters but does not mention preconditions (e.g., an active project) or what the tool returns. Although an output schema exists, it is not shown, and the description alone does not provide complete context for a successful call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description thoroughly explains every parameter: 'target_type' with allowed values, 'param' with examples, 'points' with the structure and example, 'target_index' with its meaning for each target type, 'name' with default behavior, and 'smooth' with true/false semantics. This fully compensates for the schema's lack of descriptions (0% coverage).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the function: 'Create an automation curve that controls a parameter over time.' It lists all automatible targets (song, track, mixer) and parameters, which distinguishes it from the sibling tool 'add_automation_track' that likely creates a track instead of a curve.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides implicit guidance by enumerating the targets and parameters, making it clear this is for creating automation curves. However, it does not explicitly compare to 'add_automation_track' or state when to prefer this tool, so it falls short of full explicitness.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It only says 'Add...' with no mention of project prerequisites, side effects, duplicate-name behavior, or whether the operation appends to the current project. The mutation nature is clear, but the consequences are not.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The main sentence is front-loaded and concise, stating the action and purpose immediately. The 'Args:' block is redundant with the input schema and adds minor noise, but the overall structure remains efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple and has an output schema, but the description still omits prerequisites such as a loaded project and gives no usage boundary or relationship to sibling tools. An agent gets no guidance on when to choose an automation track over other track types.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description needed to compensate for the parameter, but 'Args: name: Track name' merely restates the schema's own string property title. It does not explain that the parameter is optional, how the default value behaves, or any constraints on valid names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States 'Add an automation track' with a specific verb, resource, and purpose ('for parameter automation'). It is clearly distinguishable from sibling track-creation tools like add_instrument_track, add_sample_track, and add_pattern_track, as well as from add_automation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no explicit when-to-use or alternative guidance. It never references sibling tools such as add_automation or the other add_*_track tools, leaving the agent to infer context from the phrase 'for parameter automation'.

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

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

No annotations are provided, so the description carries the full burden. It adds helpful behavioral details such as valid effect names, wet/dry range (0.0-1.0), mixer index 0=Master, and position None=end. However, it does not disclose mutation side effects, error handling, or whether inserting at a position replaces an existing effect.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: a one-sentence summary followed by a clear Args list. Every line adds necessary information, and the effect-name enumeration is repetitive but essential for correct invocation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the 6 parameters, no annotations, and an output schema present, the description is complete enough for correct invocation. It covers all parameter meanings, valid values, and insertion semantics. Error behavior is not described, but all invocation-critical details are present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the Args block must compensate, and it does. It documents all six parameters with concrete semantics: target_type values, target_index meaning, the complete list of valid effect names, wet range, enabled flag, and position insertion behavior. This goes well beyond the bare schema types and defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with a specific action and resource: 'Add an effect to a track's or mixer channel's effect chain.' The sibling tools remove_effect, toggle_effect, and get_effect_chain make the differentiation clear, so an agent can immediately understand what this tool does versus its alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context about target type ('track' or 'mixer') but does not explicitly state when to use this tool instead of remove_effect, toggle_effect, or get_effect_chain. The intended usage is implied by the verb and sibling names rather than stated with exclusion criteria.

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

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

Annotations are absent, so the description carries the full burden for behavioral disclosure. It only states the add action and parameter ranges; it does not mention whether an existing project is required, whether the addition is reversible, how mixer channels are affected, or any failure behavior. The description adds only core-purpose information.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with a one-line summary and followed by a compact Args block. Every line provides necessary parameter information, including a valuable enum-style list for instrument choices. There is no filler or unnecessary repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Parameter coverage is thorough and the presence of an output schema means return values do not need to be described. The main gap is the lack of context about requiring an active project and how adding an instrument track relates to mixer channels or other project state, but the description is otherwise sufficient for successful invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the Args section fully compensates by documenting all five parameters: name with examples, instrument with the complete lowercase plugin list, mixer_channel with 0=Master semantics, volume range 0-200, and panning range -100 to +100. This adds substantial meaning beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Add an instrument track to the project,' which clearly distinguishes this tool from sibling track-creation tools like add_sample_track, add_automation_track, and add_pattern_track. The track type is explicit, so an agent can understand the tool's role immediately.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance about when to use this tool versus the many sibling track/mixer tools, nor any mention of prerequisites such as needing an open project. The tool name implies usage, but the description provides 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.

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

With no annotations, the description carries the full burden of behavioral disclosure, and it does so by revealing a non-obvious gotcha: the channel is routed to Master via an explicit <send> element because LMMS drops the implicit connection, otherwise the channel is silent. This is precisely the kind of side effect an agent needs to know. It does not mention project-state implications such as requiring a loaded project.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences plus a compact Args list; every sentence earns its place. The crucial routing warning is front-loaded immediately after the main action, and there is no padding or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is largely complete for invocation: it covers the required name parameter, optional volume semantics, and the critical routing behavior. The presence of an output schema partially lessens the need to document return values, though it omits the prerequisite of a loaded/current project and how the new channel is referenced by later sibling calls.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the Args section fully compensates by providing name examples ('Drums', 'Bass', 'Lead') and explaining the volume range (0.0-2.0) and the meaning of 1.0 as 0dB. Without this text, the volume default would be opaque and value validation impossible.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Add a new mixer channel,' a specific verb and resource that exactly names the operation. The subsequent detail about routing to Master and the sibling set (get_mixer_channels, set_mixer_channel_volume) make the target resource unambiguous and distinct from track-adding tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool—whenever a new mixer channel is needed—but provides no explicit when-not-to-use guidance or comparison with sibling tools such as set_mixer_channel_volume or add_effect. An agent must infer that this is the creation step and that modifications belong to other tools.

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

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

With no annotations, the description carries the behavioral burden. It discloses important behaviors: notes are placed inside the target pattern, clips are extended automatically when notes exceed the pattern length, and notes beyond the clip end would be silent. It also clarifies the effect of pattern_index and the prerequisite of using place_pattern.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with a one-sentence purpose and then uses a tightly organized Args block. Each parameter line adds meaningful operational detail without fluff, making the length appropriate for a 7-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, zero annotation coverage, and 0% schema description coverage, the description provides everything needed to call the tool correctly: all parameter semantics, edge-case behavior, constraints, and a prerequisite pointer. Since an output schema is present, not describing the return value is acceptable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description fully compensates. Every parameter is explained with units, ranges, defaults, or examples: key maps 60=C4 and 69=A4, pos uses ticks with 192 ticks per bar, length gives note equivalents, volume spans 0-200, panning spans -100 to +100, and pattern_index has its default and prerequisite explained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear, specific statement: 'Add a note to a track's pattern.' This identifies both the action and the target resource, and the MIDI-note-number parameter distinguishes it from siblings like add_note_by_name and add_notes_batch.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides concrete usage constraints: the track must be an instrument or pattern track, positions are relative to the pattern start, and place_pattern should be used to create additional patterns first. It does not explicitly contrast this tool with add_note_by_name or add_notes_batch, but the intended context is clearly conveyed.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. It explains parameter units and formats, but it does not mention side effects, prerequisites such as an active project or existing track, state mutation, or what the output contains. The 'Add' verb implies mutation but leaves operational context undisclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, front-loaded with the primary purpose, and then uses a clean Arg list. Every line provides useful information with no filler or repetition of the schema types.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The parameter semantics are complete enough for invocation, and an output schema exists so return values need not be described. However, the description lacks usage context such as when to prefer this over add_note or add_notes_batch, and it does not state prerequisite conditions like a loaded project or valid track. This leaves selection and error-prevention incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description fully compensates. Every parameter is explained with meaningful detail: track_index is zero-based, note_name uses a note-name format, pos and length are in ticks with concrete values, and volume has a range of 0-200. Examples clarify the expected string formats.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states what the tool does: 'Add a note using a note name' with concrete examples like 'C4', 'A#3', and 'F#5'. It names the resource and the operation, but it does not explicitly distinguish itself from the sibling tools add_note and add_notes_batch beyond the by-name hint.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance about when to use this tool versus add_note, add_notes_batch, or note_name_to_key. There is no mention of alternatives, exclusions, or conditions that would help an agent choose this tool over its siblings.

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

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

With no annotations provided, the description carries full behavioral disclosure burden. It only states the mutating action 'Add' and then focuses on parameter defaults/ranges. It does not disclose whether notes are appended or replace existing notes, whether the track must pre-exist, how invalid values are handled, or any side effects. This is a significant gap for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-organized: a one-line summary followed by a clear Args block. Every sentence earns its place, and the essential information is front-loaded. There is no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, the return value is covered elsewhere, so that gap is acceptable. The description thoroughly documents all input parameters and defaults. The main missing contextual detail is whether notes are appended or overwrite existing notes on the track, which is relevant for a batch mutation tool but not critical enough to lower the score further.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides only bare parameter names and types, with zero description coverage for the notes object. The description compensates thoroughly by documenting track_index as zero-based and specifying each note field: key formats ('C4'), pos in ticks, length default 48, volume range 0-200, panning range -100 to +100. This is the strongest part of the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Add'), a specific resource ('multiple notes to a track'), and the 'at once' phrase clearly distinguishes it from the single-note siblings add_note and add_note_by_name. An agent can immediately understand what this tool does without inspecting the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies batch usage ('at once') but never explicitly contrasts this with add_note/add_note_by_name or states when not to use it. No alternative routing or exclusion conditions are provided, so an agent must infer the intended use case.

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

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

With no annotations, the description carries the behavioral disclosure burden. It explicitly states that a default inner kick instrument is created, that notes can be added immediately, and that the track is triggered via place_bb_clip. This is useful side-effect disclosure for a creation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded with the core purpose. Every sentence adds useful information about what the tool creates or how to use it, with no filler. The Args line is slightly redundant with the schema but still helpful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter creation tool with an output schema, the description covers the essential context: what kind of track is created, what instrument is defaulted, how to add notes, and how to trigger the clip. It does not mention prerequisites like needing a loaded project, but the low complexity makes this a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does so by documenting the sole parameter as 'Pattern track name', clarifying that the name identifies the track. For a single simple string parameter with a schema default, this is sufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Add a beat/bassline pattern track for drum sequencing.' This clearly differentiates it from sibling track-adding tools like add_instrument_track, add_sample_track, and add_automation_track, and the mention of a default kick instrument reinforces its drum-specific purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear workflow context: notes can be added immediately via add_note and triggered in the song editor with place_bb_clip. 'For drum sequencing' implies when to use this tool, though it does not explicitly name alternative track types 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.

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Add a sample track' and does not mention side effects, whether the track is created empty, whether a project must be loaded, whether the operation is reversible, or what happens in the current project context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded with the main purpose, followed by a compact Args list. Every line provides useful information and there is no redundant filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The parameter explanations and output schema cover the basic call mechanics, but the description lacks usage guidance and behavioral context for a mutating tool with no annotations. An agent still needs to infer when a sample track is appropriate and what side effects to expect, so the description is only minimally complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even though schema description coverage is 0%, the description compensates by documenting all four parameters with meaningful details: track name, mixer_channel '0=Master', volume range '0-200', and panning range '-100 to +100'. This adds real value beyond the bare schema titles and defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Add a sample track for arranging audio files.' This distinguishes it from sibling tools like add_instrument_track, add_automation_track, and add_pattern_track, though it does not explicitly name those alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance about when to use this tool versus the other track-creation siblings. The phrase 'for arranging audio files' implies a use case, but it does not state when not to use it or point to alternatives such as add_instrument_track or add_vst_track.

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

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

With no annotations present, the description carries the full disclosure burden and delivers meaningful context: it names the host mechanism (Vestige), exposes a real failure mode ('64-bit LMMS needs 64-bit VSTs'), and documents parameter ranges. It stops short of describing error behavior for invalid paths, but the mutation semantics are self-evident from 'add' and the output schema covers the return shape.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three terse sentences plus a scannable Args block; the purpose statement is front-loaded and every sentence earns its place. There is zero wasted wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema covering return values, the description correctly focuses on invocation semantics and covers the important non-obvious facts: Vestige hosting, architecture compatibility, and all parameter ranges. Only minor gaps remain, such as explicit error behavior for bad paths and explicit sibling routing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate — and it does completely. Every parameter gains value beyond its title: dll_path gets the 'absolute path' requirement, mixer_channel gets '0=Master', volume gets '0-200', panning gets '-100 to +100', and name gets a concrete example.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource: 'Add a track hosting a VST plugin (.dll file).' The VST/Vestige qualifier clearly distinguishes this from the sibling track creators (add_instrument_track, add_sample_track, add_automation_track, add_pattern_track) without needing to inspect their schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied: use this when the goal is hosting a VST .dll, reinforced by the Vestige-host line. However, it does not explicitly name alternatives or state when-not-to-use, such as when a built-in LMMS instrument route (add_instrument_track) would be the better choice.

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

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

No annotations are present, so the description carries the full behavioral disclosure burden. It states the core assignment action but does not explain whether existing clip assignments are overwritten, what happens if the track has no clips, or any side effects of this mutating operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: purpose, path guidance, and parameter details. Every sentence adds value, and the most important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter tool, the essential call information is present, and an output schema exists. However, behavioral gaps remain—overwrite semantics, failure behavior, and prerequisites for the sample track—so the definition is adequate but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description adds meaningful parameter context: track_index is the sample track index, and file_path supports WAV/OGG/MP3/FLAC with relative or absolute path guidance. This goes beyond the bare schema types and titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's specific action: assigning an audio file to all clips on a sample track. This is distinct from sibling tools like place_sample_clip, which likely places individual clips, and add_sample_track, which creates tracks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context on how paths should be specified: relative paths for built-in samples and absolute paths for external files. It does not explicitly name alternatives or when-not-to-use conditions, but the 'all clips on a sample track' scope makes the intended use reasonably clear.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It adds useful context by specifying the fixed conversion rate and the 4/4 time-signature assumption. It does not describe edge cases, rounding, or error behavior, but those are less critical for a simple converter with an output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely compact and front-loaded, with a single conversion statement followed by a parameter line. Every element is useful, and there is no filler or repetition beyond the minor redundancy in the parameter description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter utility converter with an output schema, the description is functionally complete. It communicates the conversion factor, the time-signature assumption, and the input meaning. The existence of an output schema means return-value details are not required in the description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description should compensate by explaining parameter meaning. However, 'bars: Number of bars' merely restates the parameter name and schema type without adding constraints, defaults, or contextual nuances. The conversion formula in the description partially informs the parameter, but the parameter-specific text adds little beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific operation ('Convert bars to ticks') with an exact conversion rate (192 ticks per bar in 4/4 time). It clearly distinguishes this tool from the sibling `ticks_to_bars_converter` by identifying the direction of conversion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended usage is implied by the tool name and description, but there is no explicit guidance about when to choose this tool over `ticks_to_bars_converter` or any other alternative. No exclusions or decision criteria are provided.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state what happens to the currently loaded project, whether unsaved work may be discarded, or how creation affects the application/project state. The parameter ranges are useful but do not cover these 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a brief one-sentence purpose followed by a compact argument list. Every line in the Args section adds range/semantic information not present in the schema, and the purpose statement is front-loaded. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

All parameters are covered and an output schema exists, so return-value documentation is not needed. However, the description omits important contextual behavior about replacing/discarding the current project and when to prefer this over load_project or the individual setter tools. This leaves the agent with a moderate but meaningful gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description compensates fully by documenting every parameter with meaning and valid ranges (e.g., bpm 10-999, master_volume 0-200, master_pitch -12 to +12). This adds real value beyond the bare schema defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Create'), a clear resource ('a new empty LMMS project'), and the word 'empty' distinguishes it from loading or saving projects. It clearly separates this tool from siblings like load_project and save_project.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The usage is implied: create a fresh project, rather than load an existing one or adjust settings post-creation with set_tempo/set_time_signature/set_master_volume. However, there is no explicit when-to-use/when-not-to-use guidance or mention of alternatives, so the agent must infer from sibling names.

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

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

Annotations are absent, so the description carries the full burden. It clearly signals destructive behavior with the word 'delete', but it does not disclose whether the deletion is permanent, whether it can be undone, or how it handles a non-existent clip at the given position.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short and front-loaded: the first sentence states the purpose, and the Args section adds only relevant parameter semantics. Every line earns its place with no unnecessary wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 2-parameter delete tool, the description covers the basic action and parameter meanings adequately. Still, it leaves out practical details like indexing convention, behavior on missing clips, and side effects, which would help an agent avoid misusing the tool in an automated workflow.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides only types and titles with no descriptions. The description's Args section adds useful meaning: track_index identifies the containing track, and pos_bars is the clip start position in bars. However, it does not specify whether track indexes are zero-based or what bar value formats are accepted.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Delete a clip'), the object ('a clip'), and the location ('at a given position from a track'). This is specific enough to distinguish it from sibling tools like move_clip or place_sample_clip without needing to infer intent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given about when to use this tool versus alternatives such as move_clip or the various 'place' tools. There is no mention of prerequisites, exclusions, or typical usage context.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It reveals the output type conceptually (MIDI key numbers and note names) but does not state whether this is a pure calculation, whether it modifies the project, or what error behavior to expect.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a one-sentence summary followed by a concise Args block. Every line adds value, and the most important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is minimally viable for a simple generator tool, especially since an output schema exists. However, it lacks usage guidance and explicit behavioral context, and with no annotations it does not fully clarify whether the tool is side-effect free or how its output should be integrated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema coverage is 0%, so the description must compensate. It adds useful meaning by giving a root note example ('C4', 'A3'), enumerating all accepted scale types, and explaining num_octaves. It does not state constraints like valid ranges, but it is far more informative than the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Generate a musical scale as MIDI key numbers and note names.' This clearly distinguishes it from sibling tools like note_name_to_key or add_note, which target single-note conversion or placement rather than scale generation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives. It does not mention relationships to note_name_to_key, key_to_note_name, or add_note tools, so the agent must infer its role purely from the name and summary.

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

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

No annotations are provided, so the description carries the burden, and it does disclose meaningful behavior: results are sorted by time, include every clip/automation curve, and positions/lengths are given in ticks and bars. It does not explicitly state that it is side-effect-free or what happens if no project is loaded, but the 'Get' framing and output details clarify the primary behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences: the first gives the purpose and the second details the content. There is no verbose or redundant wording, and the most important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read tool with an output schema, the description is largely complete: it states the resource, the scope, sorting, content types, and units. It could add explicit notes about project-load requirements or contrast with get_track, but those are not critical for successful invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so parameter semantics are fully covered by the empty input schema. No additional description is required, and the baseline of 4 applies because there is nothing for the description to clarify.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('Get the full song editor arrangement') and then enumerates exactly what is included: patterns, BB clips, sample clips, and automation curves with positions and lengths. This clearly distinguishes it from sibling tools like get_track or get_project_info.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'full song editor arrangement' establishes a clear context: use this when you need the complete arrangement, not a single track. It does not explicitly name alternatives or state when not to use it, so it falls short of full routing guidance.

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

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

No annotations are provided, so the description must carry the behavioral burden. The verb 'List' implies a non-destructive read, and 'all effects' defines scope, but the description does not clarify whether disabled/bypassed effects are included, how invalid target indices are handled, or whether the operation is read-only in an explicit way. It is adequate for a simple list operation but leaves some behavior to inference.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: the purpose appears in the first sentence, followed by a minimal parameter block with no filler. Every sentence contributes useful information, and the length is proportionate to the tool's simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter read-only listing tool with an output schema, the description covers the resource type, the two accepted target locations, and the meaning of each argument. It does not discuss error behavior or result ordering, but given the output schema and very simple scope, the essential context is present and only minor details are left out.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides 0% description coverage for parameters, so the description must compensate. It defines target_type as 'track' or 'mixer' and target_index as a track index or mixer channel number, giving agents the key semantic constraints the schema omits. It stops short of specifying exact indexing conventions or whether the values are case-sensitive, but it substantially compensates for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear action ('List all effects') on a specific resource ('a track's or mixer channel's effect chain'), immediately distinguishing it from sibling mutation tools like add_effect, remove_effect, and toggle_effect. It is specific, actionable, and not a tautology of the tool name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes the tool's scope clear by naming both target types, but it does not explicitly say when to choose this tool over related siblings, nor does it mention any exclusions or when-not-to-use conditions. An agent can infer the use case, but the 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.

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does describe the returned information (version, path, plugin availability) and adds useful nuance with 'detected' and 'actually available.' However, it does not explicitly state that the operation is read-only or describe failure behavior, though the name and 'info' imply no 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three short sentences, with each sentence earning its place: it states the operation, lists the specific output details, and gives a direct usage guideline. It is front-loaded and contains no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters, an output schema exists, and it is a simple read-only info operation, the description is mostly complete. It covers what the tool shows and why to use it, though it could briefly mention that it does not modify the project or LMMS environment.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

This tool has zero parameters, so there is no parameter ambiguity. The baseline of 4 applies: the description does not need to explain parameter semantics because none exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves information about the installed LMMS application and lists specific details it returns: version, installation path, and available plugins. It is clear and specific, but does not differentiate from the sibling tool list_available_plugins, which likely overlaps in the plugin-availability aspect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use this to check whether a plugin is supported before using it,' which gives a clear use case. However, it does not mention when not to use it or name alternative tools such as list_available_plugins.

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

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

With no annotations, the description carries the behavioral disclosure burden. It does add useful scope semantics by saying 'all' mixer channels and 'with their settings', but it never explicitly states that the operation is read-only, has no side effects, or what happens when the project has no mixer channels. This is partial but not comprehensive behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence where every word adds value: 'Get', 'all', 'mixer channels', and 'with their settings'. There is no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple, zero-parameter getter and an output schema exists, so the description does not need to explain return types in detail. However, since annotations are absent, a brief note about the operation being read-only or about behavior on an empty project would make it more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and the input schema is already complete with an empty properties object. The zero-parameter baseline of 4 applies; there is no parameter meaning for the description to add.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb and resource: get all mixer channels along with their settings. It is distinguishable from sibling tools that add or set mixer channels, though it does not explicitly name an alternative or contrast itself with another tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance about when to prefer this tool over alternatives such as get_track, list_tracks, or get_effect_chain. There is no mention of use cases, prerequisites, or exclusions, so the agent must infer usage entirely from the tool name and basic wording.

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

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

With no annotations, the description carries the behavioral burden. It discloses the main observable behavior by saying the tool returns tempo, time signature, tracks, and mixer channels, and 'Get' implies a read-only operation. But it does not mention prerequisites such as a loaded project, error behavior, or whether the operation affects any state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short, front-loaded sentences with no filler. The main purpose appears in the first sentence and the return categories in the second, which is efficient and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-parameter getter backed by an output schema and a simple domain, the description is largely complete: it states the resource and the main return categories. It loses a point only because 'and more' is vague and the relationship to sibling getter tools is not clarified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and the input schema already covers this completely with an empty properties object, so there is no parameter semantics left for the description to add. This earns the baseline 4 for zero-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies a clear verb and resource: get comprehensive information about the current LMMS project. It lists concrete contents (tempo, time signature, tracks, mixer channels) but does not explicitly distinguish itself from siblings like get_project_xml or list_tracks, so it is clear rather than sharply differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'comprehensive information about the current LMMS project' implies the agent should call this when it needs a broad project overview. However, it gives no explicit guidance about when to prefer this over more specific siblings such as list_tracks, get_mixer_channnels, get_project_xml, or get_lm_ms_info, and it states no exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It conveys the read-only nature via 'Get' and the return type 'raw XML representation', but it does not explicitly state that it has no side effects, what error conditions may occur, or whether a project must be loaded first. This is adequate but not fully transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences with no filler. The core action and resource are front-loaded, and the secondary sentence adds practical context about why the tool is useful. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read-only tool with an output schema, the description is nearly complete. It states what the tool returns and when it is useful. The only missing piece is an explicit note that a project must exist or be loaded, which is implied by 'current project' but not stated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and the input schema fully documents this (100% schema coverage). The baseline for no parameters is 4, and the description does not need to add parameter-level meaning since there are none.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and a precise resource ('raw XML representation of the current project'). This clearly distinguishes it from sibling tools like get_project_info by indicating the format and detail level. The purpose is immediately understandable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear use context: 'debugging or understanding the exact project structure.' However, it does not explicitly state when this tool should be preferred over alternatives like get_project_info, nor does it mention any exclusions or prerequisites.

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

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

With no annotations, the description must carry the burden. It signals a read-only operation with 'Get' and clarifies that the track is addressed by zero-based index, which is useful. However, it does not disclose error behavior for invalid indices or what 'detailed information' actually includes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two lines of content with no redundant text; the primary purpose is front-loaded, followed by parameter documentation. It is as concise as a minimal but complete tool definition should be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, one parameter, and presence of an output schema, the description is largely complete for a successful call. The agent knows the tool expects a zero-based track index. It would be slightly more complete if it pointed to list_tracks for obtaining valid indices, but that is not essential.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explicitly documents 'Zero-based index of the track', adding critical meaning the raw schema lacks. This compensates for the 0% schema description coverage; the agent knows to pass a zero-based integer rather than a one-based one.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a clear verb ('Get') and resource ('detailed information about a specific track'), making its purpose easy to understand. It is implicitly distinct from list_tracks (which lists all tracks), but does not explicitly name sibling alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use get_track versus alternatives. The description implies the agent should call it when it needs details on one track, but does not reference list_tracks or mention preconditions like obtaining a valid track index.

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

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

With no annotations, the description must carry the behavioral burden. It clearly states the core conversion behavior, but it does not disclose details like octave naming convention, sharp/flat preference, or behavior on invalid key values. Still, the operation is clearly a pure conversion with no 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is minimal and front-loaded: one clear sentence states the purpose, followed by a compact Args block. There is no filler or redundant restating of the schema, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter pure conversion utility with an output schema available, the description is largely complete. It covers the input semantics and range. It could be improved by explicitly mentioning the inverse sibling or note formatting convention, but nothing essential is missing for invoking the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does well by adding 'MIDI key number (0-127)', giving both the semantic meaning and the valid range beyond the bare integer type in the schema. It does not over-explain, but this is sufficient for a single required parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with a clear, specific verb and resource: 'Convert a MIDI key number to its note name.' This unambiguously states the operation and direction, and it naturally contrasts with the sibling tool note_name_to_key, which performs the inverse conversion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance is given about when to use this tool versus note_name_to_key or other siblings. The intended use is implied by the description and tool name, but the 'when-not-to-use' or alternative routing is left to the agent to infer.

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

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

With no annotations, the description carries the burden. It discloses that the list is dynamically detected and includes both built-in and custom plugins. For a read-only list tool, this is adequate but does not mention potential performance costs, plugin availability after scanning, or whether VSTs are included/excluded. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core action, followed by scope detail and a practical usage hint. No filler or redundancy; each sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is largely complete for a zero-parameter list tool, especially with an output schema present. It covers plugin scope and downstream usage. The only minor gap is not explicitly stating whether VSTs (handled by scan_vst_directory) are included, which could matter for an agent deciding between list_available_plugins and scan_vst_directory.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there is no parameter semantics to clarify. The description still adds value by explaining what the returned list contains and how custom plugin names can be reused, which is the relevant semantic context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description states a specific verb ('List') and resource ('ALL plugins installed in your LMMS'), with concrete scope ('built-in instruments/effects' + 'custom plugins the user added'). This distinguishes it from sibling scan_vst_directory, which handles a different plugin source (VST directory). The phrase 'dynamically detected' adds precision about how the list is obtained.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly implies when to use the tool: to discover custom plugin names for add_instrument_track / add_effect. It gives actionable context ('Custom plugins can be used directly by name') but does not explicitly state exclusions or directly compare with sibling alternatives such as scan_vst_directory.

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

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

With no annotations, the description carries the burden of indicating side effects, and the verb 'list' clearly conveys a non-mutating read-only query. It also discloses the scope (current project) and the exact returned data. It does not mention failure behavior when no project is loaded, but the risk is minimal for a no-argument listing tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence contains the action, resource, scope, and output fields with no filler. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, low-complexity query with an output schema, this description is complete. It identifies what is listed, where it is listed from, and what fields are returned, which is all an agent needs to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and the schema coverage is 100%, so the schema fully defines the call signature. The description compensates by stating what the response contains, which is useful since no arguments exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'List all tracks in the current project' and explicitly names the returned fields (index, name, type). This clearly distinguishes it from single-track get_track and mutation tools like add_* and remove_track.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The usage is implied: an agent would use this when it needs an overview of every track in the current project before targeting a specific track. However, it does not explicitly state when to prefer this over alternatives such as get_track, 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.

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

With no annotations provided, the description carries the burden of disclosing behavioral traits. It clearly indicates a non-destructive list operation by using the verb 'List', and describes the category filtering behavior. It does not mention potential side effects, but for a simple listing tool none are expected. The description could have added context about where presets are sourced, but the core behavioral profile is transparent enough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded. The main action is stated in the first sentence, with the parameter details presented in a compact Args block. Every sentence earns its place, and there is no redundant or filler content. The structure is easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with a single optional parameter and an output schema available, the description is complete. It covers the operation's purpose, the parameter's optionality, example values, and the default behavior (omit to list all). Since the output schema exists, returning the list format need not be described. No critical information is missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully compensate for the parameter's meaning. It does this well: 'category' is explained as an optional filter, with concrete examples ('Bass', 'Strings') and an explicit statement that omitting it lists all categories. This adds substantial semantic value beyond the bare schema definition, making the parameter's role unmistakable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'List available ZynAddSubFX presets (.xiz files)'. This clearly identifies the operation as a read-only query for preset files, which is distinct from sibling tools like load_zyn_preset or set_zyn_params. The purpose is immediately comprehensible and not a tautology.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context on how to use the tool, including the optional category filter with examples and the instruction to omit it for all categories. It does not explicitly compare itself to sibling tools, but the listing operation is inherently distinct from loading or modifying presets, so exclusion guidance is not critical here. The usage context is sufficient for an agent to decide when to call it.

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

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

With no annotations, the description carries the full burden. It explains what file types are accepted and that a path is needed, but does not disclose whether loading replaces the current project, discards unsaved changes, or requires the file to exist. This is a meaningful gap for a state-changing load operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences plus a one-line arg note, front-loading the core purpose and adding only the necessary path detail. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the basic contract and an output schema exists, so return values do not need explanation. However, it omits the important context that loading a project likely replaces the current in-memory project, which an agent should know before invoking. This is a clear but not severe gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It does by adding 'Full path' and naming the file formats, which gives the single pathway parameter real meaning beyond the bare string type. This is sufficient for the one parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Load') and resource ('LMMS project file') with the accepted formats (.mmpz or .mmp). It also specifies 'existing', which distinguishes it from create_project and save_project.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Use is implied by 'Load an existing LMMS project file' and the sibling context, but there is no explicit guidance about when to prefer this over create_project or get_project_info. No exclusions or alternative conditions are stated.

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

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

No annotations are provided, so the description carries full behavioral burden. It does disclose the track prerequisite and supported preset reference formats, but it does not mention what happens to existing settings, failure behavior for invalid tracks, or whether the operation overwrites the current preset. The description is adequate but not deeply transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the core action, followed by the key prerequisite and parameter details. There is minor redundancy between the prose explanation of preset reference formats and the Args section, but overall it is well-organized and without significant fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter tool, the description covers the essential call context: what the tool does, the required track instrument, and accepted preset formats. It does not explain error cases or return values, but an output schema exists, so return-value documentation is less critical. A brief pointer to list_zyn_presets for discovering valid preset names would improve completeness further.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description compensates by defining both parameters: track_index as the target track index and preset as a name, 'Category/Name', or absolute path. This gives the agent meaningful guidance beyond the bare schema field names, though it could further specify indexing details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Load'), a concrete resource (ZynAddSubFX preset .xiz), and the target (a zynaddsubfx instrument track). It clearly distinguishes itself from sibling tools like load_project and set_zyn_params by focusing on preset loading into a specific track type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides clear context: the target track must use the 'zynaddsubfx' instrument, and presets can be referenced by filename, 'Category/Name', or full path. It does not explicitly name alternative tools for related tasks like listing presets or adjusting parameters, but the usage context is sufficiently clear.

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

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

No annotations are provided, so the description carries the full burden. It only says a clip moves to a new time position; it does not disclose whether the old position is cleared, whether overlaps are allowed, what happens on invalid input, or any other side effects. This is too thin for a mutating tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short, front-loads the purpose, and then adds a compact argument list. The Args section partly duplicates schema property names, but it adds useful semantic context, so it is justified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The essential behavior and all three required parameters are described, and an output schema exists. However, with no annotations, the definition omits behavior around invalid positions, overlapping clips, track constraints, and error handling, leaving some ambiguity for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description gives meaningful semantics for all three parameters: track index identifies the track, old_pos_bars is the current start, and new_pos_bars is the destination. It also specifies the unit (bars), which the bare schema does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Move'), a specific resource ('clip'), and the clip types covered (pattern/bbtco/sampleclip), plus the new time position. This clearly distinguishes it from sibling tools like place_* 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The operation name and description imply it should be used when repositioning an existing clip rather than placing or deleting one. However, there is no explicit comparison to siblings like place_pattern, place_bb_clip, or place_sample_clip, and no mention of prerequisites or invalid states.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states that the tool mutates or unmutates a track, which conveys the side effect, but it does not mention permissions, reversibility, return behavior, or possible constraints on track_index. For such a simple operation this is acceptable but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded with the core purpose. The Args section is compact and directly relevant, containing no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter mute/unmute action, the description plus schema covers the required semantics completely. The presence of an output schema means return-value explanation is unnecessary, and no other context is needed to invoke this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema describes track_index and muted only with titles and types, and schema description coverage is 0%. The description compensates fully by explaining that track_index is zero-based and that muted=true means mute while muted=false means unmute, adding meaning the schema itself does not provide.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Mute or unmute a track,' which clearly identifes the specific action and resource. It is distinct from sibling tools like solo_track or set_track_volume, though it does not explicitly call out those alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The usage is implied by the action described: use this when you want to mute or unmute a track. However, there is no explicit guidance about when not to use it or which sibling tool might be more appropriate for similar situations.

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

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

No annotations are present, so the description carries the full burden. It discloses the core conversion behavior and gives representative note-name formats, but it does not specify the octave convention (e.g., which MIDI number C4 maps to), invalid-input behavior, or case sensitivity. This is adequate for a pure conversion, but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is a single terse sentence plus an example line, with no filler. The core transformation is front-loaded, and the examples make the expected input format immediately usable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter conversion utility with an output schema available, the description covers the necessary input format and purpose. The main omissions are explicit routing to the inverse sibling and edge-case behavior, which keep it from being fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description compensates by explaining the 'name' parameter and providing examples that include sharps and flats ('A#3', 'Bb2'). It adds significant meaning beyond the bare string type, though it stops short of a complete syntax or validation pattern.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb, 'Convert,' and defines the exact transformation from a note name to a MIDI key number, with concrete examples such as 'C4' and 'A#3'. The directional wording clearly distinguishes it from the inverse sibling tool key_to_note_name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (when a note name must become a MIDI key number), but it does not explicitly mention alternatives or when to prefer other tools. There is no exclusion guidance such as 'use key_to_note_name for the reverse direction.'

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

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

No annotations are present, so the description must carry the behavioral burden. It usefully explains that placing the clip triggers the BB pattern at the given time and that the default length is one 16-step BB cycle. However, it does not disclose side effects such as overwriting existing clips, whether placement is reversible, or other mutation consequences.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact: two short sentences and a focused Args list with no filler or redundancy. The core purpose is front-loaded, and every line contributes useful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 3-parameter tool with an indicated output schema, the description covers the action, prerequisites, parameter semantics, and the BB-pattern relationship. It is complete enough for an agent to call the tool correctly, though it could optionally mention how this differs from place_pattern.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the Args block compensates by defining bb_track_index, pos_bars in bars, and length_bars with the BB-cycle default meaning. This adds real semantic value beyond the raw schema properties.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a concrete action ('Place...') and a specific resource ('beat/bassline clip on a pattern track'), which is clear and unambiguous. It establishes BB-pattern specificity but does not explicitly distinguish itself from sibling tools like place_pattern or place_sample_clip.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a useful prerequisite: the BB pattern should be created via add_pattern_track and filled with notes. This tells the agent when the tool is appropriate, though it does not provide explicit exclusions or direct comparisons to sibling placement tools.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It does reveal that the pattern starts empty and that notes added later go into the first pattern. However, it does not describe side effects like overwriting existing clips, error behavior, or whether the clip is appended or inserted, leaving some gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a clear one-sentence summary, a brief workflow note, and a compact Args list. Every sentence adds value, and the structure makes scanning for parameter semantics easy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's purpose, parameter semantics, and its relationship to add_note, which is enough for basic invocation. It does not discuss error cases, validation, or explicit comparisons to similarly named clip-placement tools, but given the output schema and reasonably straightforward behavior, it is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. The Args section explains every parameter with meaningful semantics: track_index identifies the instrument track, pos_bars is in bars with 0 meaning beginning, name defaults to track name, and length_bars is pattern length in bars. This fully makes up for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action, resource, and scope: 'Place an empty pattern clip on an instrument track (song arrangement).' This clearly distinguishes it from siblings like place_sample_clip and place_bb_clip, and the 'empty pattern' phrasing further differentiates it from note-adding tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear workflow context: it can be used to sketch the arrangement structure first, and it notes that add_note places notes into the first pattern. It does not explicitly list or exclude alternatives among other placement tools, but the guidance is sufficient to infer appropriate use.

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

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

With no annotations, the description must carry the behavioral disclosure burden, but it only names the operation and parameter meanings. It does not state whether placing a clip overwrites existing content, whether the audio file must exist, what happens if the sample track index is invalid, or whether the operation is reversible.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: a one-line summary followed by a scannable Args list. Every line adds information, and there is no repetition of schema-level facts like defaults or requirements.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations, important operational context is missing: it does not say that the target track must be a sample track, how to create one, whether the file is validated, or what happens when length_bars exceeds the audio file duration. The presence of an output schema helps with return values, but the precondition and failure-mode gaps remain significant.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the Args list is essential. It covers all four parameters and adds useful meaning beyond the schema: file_path can be relative to LMMS samples or absolute, pos_bars is in bars with 0 meaning the beginning, and length_bars is the clip length in bars. It could be richer on track_index constraints, but it compensates well for the empty schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action ('Place an audio file clip') and a clear resource ('sample track'), with positional context. It is distinguishable from siblings like add_sample_track because it explicitly targets sample tracks and audio file clips, though it does not explicitly contrast itself with closely related tools like assign_sample_file or place_bb_clip.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to prefer this tool over alternatives such as assign_sample_file, place_pattern, or place_bb_clip. It also omits prerequisites such as the sample track needing to already exist, so the description does not help an agent choose correctly among sibling tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the removal action but does not disclose possible failure modes, effects on audio routing, whether the operation is reversible, or what happens if the effect name/position is invalid. This is a significant gap for a mutating tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and efficient: one purpose sentence followed by a structured Args block. The main operation is front-loaded, and every sentence adds value without redundant detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a three-parameter removal tool, the description covers the essential operation and all argument semantics. An output schema exists, so return values need not be described. The main missing context is error behavior and index-base clarification, but these are not critical for correct invocation in most cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, but the description compensates by explaining all three parameters: target_type values, target_index meaning, and effect as either name or position with examples. Minor ambiguity remains (e.g., zero-based vs one-based positions, exact string matching rules), but overall the added meaning is substantial.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Remove'), resource ('effect from a chain'), and method ('by name or chain position'). This clearly distinguishes it from sibling tools like add_effect, toggle_effect, and get_effect_chain without reference to the function name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied by the description: use it when you want to remove an effect from a track or mixer chain. However, it does not explicitly mention when not to use it, nor does it reference alternatives such as toggle_effect (for enabling/disabling) or add_effect (for insertion), leaving the selection to inference.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only restates the core action. It does not mention that removal is likely permanent, whether associated clips or mixer channels are affected, or whether track indices renumber after removal. No error or edge-case behavior is described.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences plus a one-line Args block, with the action front-loaded and no filler. Every sentence earns its place, and the parameter note is compact and directly useful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, an output schema exists, and the single parameter is explained, so the missing return-value details are not a concern. However, the description omits usage context and destructive side effects, and with many track-related siblings, an agent gets minimal help deciding this is the right tool or understanding the consequences of calling it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides only an integer type with no description (0% coverage), so the description's 'Zero-based index of the track to remove' adds essential semantic meaning. It clarifies the indexing convention and the parameter's referent. While it does not cover ranges or track types, it is substantial for a single-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Remove a track by its index.' It clearly distinguishes the tool from siblings like add_instrument_track, add_sample_track, delete_clip, and remove_effect, since removing a track is a unique operation. The scope is unambiguous enough for an agent to identify this as the removal action for tracks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use remove_track versus alternatives such as delete_clip or remove_effect. The description only states the action, leaving selection entirely to inference from the tool name. No exclusions, prerequisites, or alternative routing are provided.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses that LMMS runs in headless mode without GUI, that the project is saved before rendering, and that an external LMMS installation is required. It could also mention output file overwrite behavior, but the disclosed side effects and prerequisites are already substantive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose in the first sentence, followed by a compact behavioral note and a clear Args list. Every sentence provides useful information, with no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter tool with no annotations, the description covers the key contextual needs: external dependency, headless behavior, save-first side effect, and complete parameter semantics. An output schema exists, so return-value details are not required. Minor omissions like overwrite behavior do not undermine usability.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema only provides titles and defaults with no descriptions, so the Args section adds essential meaning: allowed file_format values, samplerate units in Hz, bitrate purpose for lossy formats, and the output_path default behavior of <project>.wav in the same directory. This fully 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Export the current project to an audio file.' This clearly distinguishes render_project from siblings like save_project or get_project_info, and there is no other export/render tool in the sibling list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended use case is clear: export the current project to an audio file via LMMS. It mentions prerequisites ('Requires a working LMMS installation') but does not explicitly name alternatives or exclusion conditions. Since no sibling tool overlaps with rendering to audio, the absence of explicit alternatives is acceptable.

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

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

With no annotations, the description carries the full burden and largely succeeds. It discloses default-path behavior, compression format selection, and importantly warns that writing compressed data into a .mmp file breaks LMMS and other tools. It does not mention overwrite behavior or permissions, but the format warning is strong for a write operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the first sentence, and the Args section is compact and well-structured. The parameter explanations and warning are all useful, though the two separate default-directory cases in the path description are slightly redundant and could be condensed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers both parameters thoroughly and includes a practical failure warning, while the presence of an output schema handles return value documentation. It omits minor context such as whether existing files are overwritten and whether a project must already be open, but these are largely inferable from the tool name and sibling set.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides zero parameter descriptions, and the tool description fully compensates. It explains path defaulting to the projects directory, filename-only handling, and the compressed parameter's True/False/None semantics including the extension-based fallback and the .mmp plain-XML rule.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence 'Save the current LMMS project to a file' states a specific verb, resource, and file target, making the tool's purpose immediately clear. It is distinct from sibling tools like load_project, create_project, and render_project because it explicitly refers to saving the project file itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains how the parameters behave but gives no explicit guidance on when to choose save_project over alternatives. It does not mention exclusions, prerequisites, or contrast with related operations like load_project or render_project, leaving the agent to infer usage context.

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

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

With no annotations provided, the description carries the behavioral burden. The verb 'Scan' clearly indicates a read-only discovery operation, and the explicit reference to .dll files plus the recursive option explains traversal behavior. It does not cover edge cases like invalid paths or permission errors, but the output schema likely covers the result shape and this is a simple non-destructive tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single clear opening sentence followed by a compact Args list with no filler. The example path earns its place by clarifying the expected path format, making the structure efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter read-only scan with an output schema present, the description is nearly sufficient: purpose, target file type, path example, and recursion toggle are all included. It lacks explicit usage conditions or alternative routing, but the simplicity of the tool and the presence of an output schema make that a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the Args block is essential and fully compensates. The directory parameter gets a purpose plus a concrete path example, and recursive is explicitly defined as 'Include subdirectories'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Scan'), a specific resource ('a folder'), and a specific target ('VST plugin DLLs (.dll files)'). This clearly differentiates it from sibling tools such as list_available_plugins or add_vst_track.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool should be used when discovering VST DLLs on disk, but it never explicitly states when to use it instead of plugin-related alternatives or gives exclusions. There is no sibling comparison or contextual routing, so usage guidance is only implicit.

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

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

With no annotations, the description carries the behavioral disclosure burden. It reveals the core state-changing operation and the constraint range (-12 to +12 semitones), which is useful, but it does not mention side effects, persistence, or whether this affects playback/rendering immediately.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is minimal and well-structured: a clear one-line purpose statement followed by a single parameter explanation. There is no redundant or unnecessary content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter setter, the description covers the purpose and parameter semantics well. The output schema exists, so return-value details are not needed. The main gap is the lack of usage/side-effect context, but the tool is simple enough that this is a minor omission.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema only says 'pitch' is an integer with no description. The description compensates by explaining the parameter meaning ('Pitch offset in semitones') and its valid range (-12 to +12), providing exactly the semantic information an agent needs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Set') and the target resource ('the master pitch offset'), making it easy to distinguish from siblings like set_master_volume or set_tempo. It is specific and uses a verb+resource structure, though it does not explicitly differentiate itself from alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus other setters, no mention of prerequisites, and no stated effect on the current project. The intended usage is only implied by the tool name and the verb in the description.

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

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

No annotations are provided, so the description carries the behavioral burden. It clearly communicates that this is a mutation operation on the master volume, but it does not disclose whether out-of-range values are clamped, whether the change is persistent, or what side effects might occur. Basic behavior is clear, but richer behavioral context is absent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short and front-loaded, with no filler. The one-line purpose and one-line parameter explanation are efficient and directly usable by an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has a single required parameter, a documented range, and an output schema, the description is sufficient for correct invocation. However, the lack of sibling differentiation or usage context slightly reduces completeness in the broader toolset.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description fully compensates by explaining the parameter: "volume: Master volume (0-200, 100=normal)". This adds a range and a meaningful reference point that the raw schema does not provide.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: "Set the master volume." This clearly distinguishes the tool from volume-related siblings like set_track_volume and set_mixer_channel_volume because it targets the master volume, not a track or mixer channel.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance about when to use this tool versus alternatives. The sibling list includes set_track_volume and set_mixer_channel_volume, but the description does not mention these or any conditions that would make one volume control more appropriate than another.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only gives the action and parameter hints ('0=Master'), but does not mention whether the channel must already exist, whether the change is reversible, how errors are handled, or what side effects may occur.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, front-loaded with the action, and uses a clear argument list. Every line serves a purpose, and there is no filler or repetition of schema details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple two-parameter setter with an output schema, so the description is minimally viable. However, it lacks important context such as whether the channel must exist, what happens for invalid channel numbers, and whether renaming affects other references. These gaps are notable for a mutation without annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for both parameters: channel_num is clarified as 0=Master, and name is described as 'New channel name'. This goes beyond the bare schema, though the explanation of 'name' is somewhat tautological.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Rename') and resource ('mixer channel'), which clearly conveys the tool's function. It does not explicitly differentiate from sibling tools like set_mixer_channel_volume, but the action and target are distinct enough for an agent to understand the core purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as add_mixer_channel or get_mixer_channels. It implies usage when renaming is desired, but there is no explicit context, prerequisite, or exclusion.

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

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

The description discloses the core behavior: setting a volume value, with a documented range and 0dB reference. However, there are no annotations, and the description does not mention possible clamping, side effects, or how the operation interacts with the master volume when channel_num is 0.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely compact and front-loaded with the action, followed by a clean Args block. Every sentence and detail earns its place, with no filler or repetition of schema data.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter setter with an output schema, the description provides nearly all necessary calling context: channel semantics, volume range, and decibel reference. It is slightly incomplete in that it does not explain when to prefer this over sibling volume tools or what happens when setting channel 0.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by documenting both parameters: channel_num is defined as 0=Master, and volume is given a numeric range plus the meaningful 1.0=0dB reference. These details add value far beyond the bare input schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb and resource: 'Set the volume of a mixer channel.' This is specific enough to distinguish from track-level operations, though it does not explicitly differentiate itself from set_master_volume, especially since channel_num 0=Master overlaps with that sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The resource scope 'mixer channel' implies when the tool should be used, but there is no explicit guidance about when to choose set_mixer_channel_volume over set_track_volume or set_master_volume. The special case of channel_num 0=Master is noted, but no alternatives or exclusions are mentioned.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It communicates that the operation sets a value and gives the valid BPM range, but it does not mention side effects, whether the tempo is applied to the current project only, or what the response contains. For a simple setter this is adequate but not fully transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, consisting of one clear sentence and a single parameter definition. Every word earns its place, with no filler or repetition of schema information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter setter with an output schema present, the description is largely complete: it states the action, the target, the parameter's meaning, and its valid range. It lacks explicit usage guidance and behavioral details, but the simplicity of the tool keeps these gaps minor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description fully compensates by explaining that bpm is 'Tempo in beats per minute (10-999)'. This adds unit, meaning, and an explicit validation range that the raw integer schema lacks.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Set the song tempo (BPM)'. This makes the tool's function immediately clear and distinguishable from sibling tools like set_time_signature, set_master_volume, and set_master_pitch.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended use is implied by 'Set the song tempo', but there is no explicit guidance about when to choose this over related settings or whether a project must be loaded first. It does not name alternatives or exclusions, so the agent must infer the usage context.

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

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

There are no annotations, so the description carries the full behavioral burden. It only explains the parameter meanings and does not disclose whether the change is global, whether existing notes are affected, what valid ranges are, or what happens on invalid input.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief, front-loaded with the purpose, and uses a clean Args section with no redundant filler. Every sentence contributes necessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter setter, the description covers the essential meaning of both parameters and the operation itself. It could be more complete with allowed ranges or global scope, but the low complexity and presence of an output schema make this adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the parameter explanations in the description are essential. It adds real meaning by defining numerator as 'Beats per bar' with examples and denominator as 'Beat unit' with note-value examples, going beyond the bare integer schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the exact operation with a specific verb and resource: 'Set the time signature.' This is unambiguous and naturally distinguishes it from siblings like set_tempo or set_master_volume, since the resource is uniquely the time signature.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool — whenever a time signature needs to be set — but does not explicitly state alternatives, exclusions, or contextual conditions. There is no direct comparison with related set_* tools.

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

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

With no annotations, the description must carry disclosure of behavior. It states that the tool sets panning and documents the valid value range, but does not explain side effects, invalid-index handling, persistence, or whether automation may override the value. Adequate for a simple setter, but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single clear sentence plus a compact argument list with no filler. The core action is front-loaded, and each line earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter setter, the description covers all input semantics needed to call it correctly, and an output schema exists for the return value. Minor gaps like requiring an existing track or failure behavior do not materially hinder correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description compensates by defining track_index as zero-based and panning as a scale from -100 to 100 with positional anchors. This adds meaningful context beyond the bare integer schema properties, though it omits behavior for out-of-range values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description states a specific action—set the panning of a track—with a clear resource and property, distinguishing it from sibling tools like set_track_volume. It is not a tautology and tells the agent exactly what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives, though the action is clear enough to imply its use case. There is no mention of prerequisites, exclusions, or conditions that would make a sibling tool more appropriate.

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses the mutation ('Set') and constrains valid input (0-200, 100=normal) and zero-based indexing, but it does not mention failure behavior, out-of-range handling, or whether the change is immediate or audibly applied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two compact sentences plus a tight args block with no filler. The core action is front-loaded and each parameter detail earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 2-parameter mutation with an output schema, the essential invocation details are present: action, argument meanings, and range. Missing guidance about when to prefer this over mixer/master volume tools keeps it from being fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% — the schema only gives integer types and titles. The description compensates by defining zero-based track_index and the volume scale with a normal level, which is essential for correct invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Set the volume of a track.' It is clear and distinct from siblings like set_mixer_channel_volume by resource, but it does not explicitly differentiate itself from those siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for individual track volume control through its verb and object, but it provides no explicit when-to-use guidance, prerequisites, or comparisons to alternatives such as set_mixer_channel_volume, set_master_volume, or mute_track.

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

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

With no annotations, the description carries the behavioral disclosure burden. It does disclose a key behavior: 'Only provided parameters are changed,' and it states the 0-127 value range. However, it does not describe mutation effects, error behavior, or what happens if the track is not a ZynAddSubFX track.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and efficient: a one-sentence purpose, two crucial usage constraints, then a clean parameter list. Nothing is redundant, and the front-loaded purpose makes orientation immediate.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter mutation tool with no annotations, the description covers the core requirements: target resource, parameter meaning, value range, and partial-update semantics. It could be more explicit about what 'global parameters' means versus per-note parameters, but the provided information is largely sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It enumerates all eight parameters with human-readable meanings and value ranges, e.g., 'filterfreq: Filter cutoff frequency (0-127)' and 'track_index: Index of the zynaddsubfx track.' This adds meaning beyond the bare schema titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Set ZynAddSubFX global parameters on a zynaddsubfx track.' This clearly distinguishes the tool from siblings like set_track_volume and load_zyn_preset, and the parameter list makes the scope explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. Usage context is only implied by the tool's purpose; there is no explicit 'use when...' statement.

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