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

The destructiveHint annotation is confirmed by the description's implication of mutation. The description adds value by explaining validation against inventory, the graceful 'not found' message, and the explicit statement that Orpheus never auto-installs plugins, which goes beyond the annotation.

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

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

The description is concise with two sentences delivering core purpose and behavioral traits. It is front-loaded but could be slightly more structured by separating parameter 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?

The description covers validation and error handling, which is good. However, it lacks parameter semantics, and the mention of 'all three live servers' is an anecdote that may not be necessary for an AI agent. Given the tool's simplicity and presence of an output schema, it is adequate but has clear gaps.

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 must explain parameters. It mentions 'fuzzy name' for fx_name but provides no details on the 'track' parameter (e.g., format, how to specify it). This is insufficient for an agent to understand parameter usage.

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 adds an FX by fuzzy name with validation against installed plugins. It distinguishes itself from sibling tools (e.g., set_fx_param, get_fx_params) by focusing on adding a new FX and handling errors gracefully.

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 indicates using the tool to add an FX by name and includes behavior for no-match cases. However, it does not explicitly state when not to use it or mention alternatives, though no direct alternative sibling exists for adding FX.

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 annotation readOnlyHint indicates no mutation, but the description adds that it renders to WAV and computes metrics, mentioning optional dependency for higher accuracy. This provides some behavioral context, but it does not clarify if the WAV is saved or temporary, nor does it discuss performance or resource implications.

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 concise with two sentences, packed with essential information: the action, the computed metrics, and the optional enhancement. Every phrase serves a purpose, making it easy to process 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?

Given that there is an output schema (not shown but known to exist) and no required parameters, the description adequately covers what the tool does and what it returns. It lacks details on prerequisites (e.g., whether stems/master must be audible or selected) but is mostly complete for its simplicity.

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?

There are no parameters, so the schema coverage is complete (100%). The description adds value beyond the schema by explaining what the tool computes and the optional extra, which helps the agent understand the tool's capabilities without needing to interpret an empty 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 specifies the action ('Render stems/master to WAV and compute') and lists exact metrics computed (3-band energy, spectral centroid, LUFS, etc.), making the tool's purpose very clear and distinguishing it from sibling analysis tools like analyze_groove or analyze_harmony.

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 obtaining post-FX sonic fingerprint metrics, but does not explicitly state when to use this tool versus alternatives (e.g., analyze_groove) or provide any exclusion criteria. The sibling names provide some context, but the description lacks direct 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?

Annotations already declare readOnlyHint=true, so the description does not need to repeat that. It adds context about analyzing 'raw MIDI PPQ onset deviation off the grid', but does not disclose whether it operates on selected items or the entire project. With annotations covering safety, the description provides moderate behavioral context but lacks details about input 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?

Two highly concise sentences with no wasted words. The first sentence clearly states functionality, and the second provides marketing context. 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?

Given zero parameters and an existing output schema, the description adequately explains what the tool does. However, it could be more complete by specifying the contextual input (e.g., whether it analyzes the selected MIDI item or the whole project). Slight gap but otherwise 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?

The input schema has zero parameters, and schema description coverage is 100%. The description does not need to explain parameters, but it could clarify that no arguments are required. The baseline score of 4 applies as per guidelines, and the description adds no confusion.

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 computes 'swing%% and tightness' from raw MIDI onset deviations. The verb 'compute' and specific metrics distinguish it from siblings like 'quantize_notes' or 'analyze_audio_character', which perform different tasks. The claim of being a unique differentiator further clarifies its 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 does not explicitly state when to use this tool over alternatives. It only implies it is for swing analysis and notes its uniqueness. There is no guidance on prerequisites or exclusions, leaving the agent to infer context from the name and 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?

Description reveals beyond readOnlyHint=true: it filters drum tracks, uses music21, always returns confidence+alternatives, and hedges on non-chordal material. No contradiction.

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

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

Two sentences, front-loaded with purpose. Second sentence adds essential behavioral traits. No redundant information.

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

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

With no parameters, annotations present, and output schema, the description covers all relevant behavioral aspects: filtering, algorithm, return type, and edge 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?

No parameters, so baseline 4. Description adds context about what the tool does but no need for parameter-level 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?

Description starts with 'Detect key/scale/chords/Roman numerals/cadences' which is a specific verb and resource. It clearly distinguishes from sibling tools like analyze_audio_character or analyze_groove.

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?

Description explains when to use (for harmonic analysis) and what to expect (confidence+alternatives, hedging on non-chordal). Does not explicitly state when not to use or name alternatives, but context is clear.

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

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

Annotations indicate destructiveHint: true, so the description's mention of 'Execute' aligns. Additionally, it reveals that edits are wrapped in Undo_BeginBlock/EndBlock for single undo, which is valuable behavioral context beyond annotations. However, it does not detail side effects like project state changes or necessary permissions.

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 consists of two concise sentences. The first covers the main action and undo behavior, the second provides a critical usage instruction. No unnecessary words, and the key information is front-loaded.

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

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

Given the tool has one parameter with a complex nested schema and an output schema exists, the description provides a clear purpose and a key behavioral note (undo grouping). It lacks explicit mention of prerequisites (e.g., requirement of a prior approved plan) or return value details, but remains largely complete for its complexity.

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 single parameter 'plan' is fully detailed in the schema (100% coverage). The description adds semantic value by instructing to 'Pass back the exact plan the user approved — do not re-derive it', clarifying it must be the output of recommend_changes, not a newly generated plan.

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 executes an approved EditPlan, listing specific symbolic edits it performs. It distinguishes from siblings like recommend_changes by explicitly saying 'do not re-derive it here', establishing it as the execution step after approval.

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 this tool is used after a plan is approved by saying 'pass back the exact plan the user approved — do not re-derive it'. This differentiates from recommend_changes, but does not explicitly state the workflow or list alternatives, leaving room for clearer usage 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?

The description mentions 'bake the matched curve onto a master-bus ReaEQ + limiter', hinting at destructive changes, which aligns with the 'destructiveHint' annotation. However, it lacks details on what exactly is destroyed (e.g., existing FX settings, original audio) and the overall effect on the 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?

The description is short but overloaded with jargon, making it hard to parse. It could be more concise while being clearer. The structure is front-loaded but ineffective.

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 and a destructive annotation, the description should explain the transformation, what inputs are needed, and what the output or state change is. It fails to provide sufficient context for an AI agent to understand the tool's operation.

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 only parameter 'fingerprint' is described as a string in the schema, but the description only mentions 'fingerprint's reference WAV' without specifying the expected format or content (e.g., file path, UUID). No additional meaning is added 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 uses cryptic jargon like 'spectral half', 'Matchering', and 'ReaEQ' without explaining what the tool accomplishes. It fails to clearly state that it applies EQ and limiting based on a fingerprint reference. The purpose is vague and confusing.

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 this tool versus sibling tools such as 'apply_changes' or 'render_and_audit'. The description does not specify prerequisites or context for invoking the tool.

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 indicate readOnlyHint=true, consistent with description's analytical nature. Description adds context about fusion and output format but doesn't disclose constraints like data dependencies or processing time.

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 concise sentences, front-loaded with purpose and key detail about output format and role.

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 no parameters and presence of output schema, description is adequate but lacks guidance on when to invoke (before recommend_changes) and what the report contains.

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?

No parameters exist, schema coverage 100%. Description provides context about analysis inputs (symbolic+audio) but not necessary since schema is empty. Baseline 4 applies.

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

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

Description clearly states it fuses symbolic and audio analysis into a CompositionSpec and plain-English report, serving as contract for recommend_changes. Verb 'build' in name plus description gives clear purpose, but doesn't explicitly differentiate from siblings like analyze_audio_character.

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?

Implied usage as prerequisite for recommend_changes via 'contract handed to recommend_changes', but no explicit when-to-use or alternatives discussed.

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 only states the core function without disclosing behavioral traits beyond the annotation 'readOnlyHint: true'. It does not confirm that the tool does not modify state, nor does it mention return values, side effects, or required permissions. The annotation provides some transparency, but the description adds minimal value.

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 (one sentence) and lacks necessary details about parameters, usage, and behavior. While concise, it sacrifices clarity and completeness. It is not front-loaded effectively, as it misses critical information that would fit in the same length.

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 complexity of music theory and the lack of parameter descriptions, the description is incomplete. It does not explain the format of 'notes', valid 'key' strings, or 'mode' options. The existence of an output schema is not leveraged, and the description fails to compensate for the low schema coverage. The agent would struggle 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?

Schema description coverage is 0%, meaning no descriptions for any of the three parameters. The description does not explain what each parameter represents (e.g., that 'notes' are MIDI note numbers, or valid values for 'key' and 'mode'). This leaves the agent with only the schema types, which is insufficient for correct usage.

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 'Snap' and the resource 'proposed note set', and specifies the action 'to the nearest in-key pitches before writing'. This distinguishes it from siblings like 'get_scale_notes' (which returns scale notes) and 'transpose_notes' (which shifts pitches). It is specific and unambiguous.

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

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

The description does not provide any guidance on when to use this tool versus alternatives or when not to use it. It lacks context about prerequisites, such as requiring a key or mode, and does not mention any exclusions. The phrase 'before writing' hints at a sequential use but is insufficient.

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 already indicate 'destructiveHint: true'. The description adds that the tool 'returns a stable take identity', which is useful for subsequent operations. However, it does not disclose other behavioral traits like overwriting behavior or required permissions.

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 efficient sentence (13 words), front-loaded with the action. Every word contributes meaning, and there is no 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?

For a tool with 3 parameters and an output schema, the description covers the core behavior but omits edge cases like whether existing items are overwritten or if the track must exist. The mention of a stable identity partially compensates, but gaps remain.

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 carries the full burden. It explains that the tool operates 'over a bar range' (linking to start_bar and length_bars) and implies the track parameter, but it does not provide data types, constraints, or examples, leaving significant ambiguity.

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 ('Create'), the resource ('a MIDI item/take'), and the scope ('over a bar range'). It distinguishes itself from siblings like 'create_track' and 'insert_midi_notes' by focusing on creating a new MIDI item as a container for notes.

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 creating a MIDI item on a track within bar boundaries, but it does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it.

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

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

Annotations indicate destructiveHint: true, which is consistent with creation. The description adds that the tool returns a stable GUID and is a composite bridge call, providing behavioral detail beyond annotations. No contradiction.

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

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

A single, well-structured sentence that front-loads the action and output. Every word serves a purpose; no 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?

The description covers core purpose and output but lacks usage context, parameter details, and confirmation of what the output schema provides. For a simple create tool, it is minimally adequate but could be 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?

Schema description coverage is 0% (no descriptions in schema). The description only mentions 'named track' which relates to the 'name' parameter but does not explain the 'index' parameter or its default null. Parameter semantics are poorly 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 clearly states the action ('Insert a named track'), the output ('stable GUID'), and a technical note ('one composite bridge call'). It distinguishes from sibling tools like list_tracks (list) and set_track_volume_pan (modify).

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 (when creating a track) but does not explicitly state when not to use or mention alternatives among siblings. No exclusions or context provided.

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

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

The description states 'understanding without transformation,' which aligns with the readOnlyHint annotation. It adds context by describing the underlying mechanism (feature thresholds) and the output (human-readable reasons), going beyond what annotations provide.

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

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

The description is concise, using only two sentences. It front-loads with a clear question and key functionality, with 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?

Given the tool's simplicity (no parameters, read-only analysis), the description adequately covers what the tool does and returns. However, it does not detail the format of reasons or potential edge cases, but the output schema likely covers the return value.

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 no parameters, and the input schema is empty with 100% coverage. The description does not need to explain parameters since there are none, and it adds no parameter info, which is appropriate.

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

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

The description uses a specific verb phrase 'run feature thresholds' and clearly states the tool returns human-readable reasons for why the project sounds like something. It distinguishes itself from sibling tools like analyze_audio_character or recommend_changes by focusing on explanation without transformation.

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 is for understanding style, but it does not explicitly state when to use it versus alternatives like analyze_audio_character or list_style_fingerprints. No guidance on when not to use it is provided.

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

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

The description adds significant detail beyond the readOnlyHint annotation: it explains that the tool 'round-trips a real ping through the bridge' and returns specific information (REAPER's version and latency) or an error message if the script isn't running. This fully discloses behavior without contradicting annotations.

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

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

The description is extremely concise: two sentences with no wasted words. The first sentence states the purpose; the second provides usage guidance and behavioral detail. The structure is 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?

Given the tool's simplicity (no parameters, a single clear purpose), the description fully covers what the tool does and what it returns. An output schema exists to provide further detail on return values, so the description is complete for contextual understanding.

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 no parameters and schema coverage is 100% (since there are none). The description does not need to add parameter details. With zero parameters, a baseline score of 4 is appropriate.

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

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

The description clearly states that the tool checks whether REAPER is running and the Orpheus bridge loop is alive, using a specific verb ('check') and resource. It distinguishes itself from sibling tools by advising to call it first, highlighting its role as a connectivity health check.

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 'Call this first,' providing clear usage guidance for when to use this tool. It does not specify when not to use or name alternatives, but the context implies it should precede other operations. Overall, it gives clear context without 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?

Annotations already indicate readOnlyHint=true, but the description adds behavioral context by emphasizing parameters are decoded by name, not as opaque 0-1 values. This goes beyond the annotation, though it omits details like error handling for missing tracks.

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, efficient sentence that front-loads the key behavioral trait (decoding by name). 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?

The tool has a single parameter and an output schema (not shown), but the description omits parameter explanation and usage context. It is adequate for a simple tool but lacks completeness regarding input and error scenarios.

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 has one required parameter 'track' with no description, and schema description coverage is 0%. The description does not explain the 'track' parameter at all, leaving its semantics completely undocumented.

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 decodes FX chain parameters by name (e.g., compressor ratio), distinguishing it from opaque 0-1 values. This verb+resource combination is specific and differentiates from siblings like set_fx_param and add_fx_by_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 use when needing parameter names rather than raw values, but does not explicitly state when to use this tool vs alternatives like set_fx_param. No exclusions or when-not-to-use guidance is provided.

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

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

The readOnlyHint annotation already covers safety, so the description adds minimal behavioral context (e.g., that it's a lookup of typical style elements). There is no information about side effects, authentication, or side effects beyond the annotation. It does not contradict annotations.

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

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

The description is extremely concise: two sentences that front-load the output contents. No extraneous words, and every sentence adds value.

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 (reducing need to detail returns), the description covers the core output elements. It is missing explicit examples or valid genre names, but for a simple single-parameter lookup, it is nearly 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 input schema has 0% description coverage, so the description must compensate. It implies the 'genre' parameter is a style name but does not specify valid values, format, or examples. The description mostly describes the output rather than clarifying the parameter's semantics.

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 explicitly lists the elements returned (progressions, scales, BPM range, instruments, drum rhythms) and labels it as a 'lookup,' making the tool's purpose very clear. It distinguishes from siblings like 'explain_style' by using 'profile' and 'RECOMMEND-side lookup.'

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 a vague context ('RECOMMEND-side lookup') but no explicit guidance on when to use this tool over siblings, when not to use it, or any alternatives. The lack of exclusions or criteria limits the usefulness for tool selection.

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 already provide readOnlyHint=true, so the description's added detail about returned fields is useful but not essential. Does not disclose if there are any side effects or costs.

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?

One concise, front-loaded sentence with no unnecessary words. Perfectly 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?

For a zero-parameter, read-only tool with an output schema, the description is complete and tells the agent exactly what fields to expect.

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?

No parameters exist, so baseline is 4. The description is not required to add param info.

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 explicitly lists the fields returned (tempo, time signature, length, track count, transport state), making the purpose clear. However, it does not differentiate from sibling tools like get_connection_status or get_scale_notes.

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 on when to use this tool versus alternatives. Implicitly for general project info, but lacks explicit context or contraindications.

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 annotations already declare readOnlyHint=true, so the description's addition of 'generated notes stay diatonic' adds some context but does not detail the return format or any constraints. Given the output schema exists, this is adequate but not exceptional.

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, short sentence that conveys the core purpose without extraneous information. It could be slightly improved with more structure, but it is appropriately concise.

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?

While an output schema exists, the description lacks parameter guidance and does not explain what 'key' or 'mode' are expected to be. The tool is simple, but for a 2-parameter tool with no schema descriptions, the description should provide at least minimal constraint information.

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 does not explain the parameters 'key' or 'mode' at all. The agent receives no semantic help beyond the schema itself.

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 it returns MIDI notes for a key/mode, and the phrase 'so generated notes stay diatonic' clarifies its purpose in maintaining diatonic scales. It is specific enough to distinguish from sibling tools like 'constrain_to_key', though not explicitly.

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 such as 'constrain_to_key'. The description does not mention prerequisites or typical use cases, leaving the agent to infer usage.

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 already declare readOnlyHint=true, so the agent knows it's a safe read operation. The description adds value by specifying the returned data (pitches, positions in BEATS, velocities, CC), which goes beyond the annotation.

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

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

The description is a single sentence with no fluff, conveying all essential information efficiently.

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 presence of an output schema, the description need not explain return values. However, it omits guidance on specifying which take if multiple exist, and the single parameter lacks detail. It is adequate for a simple tool but missing some contextual completeness.

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 parameter 'track' lacks any documentation. The description implies it refers to the track containing the take but does not clarify if it expects a name or ID, nor how to handle multiple takes.

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 'Read' and the resource 'a take's MIDI notes (pitch, start/duration in BEATS, velocity) + CC', which is specific and distinguishes it from siblings like create_midi_item or insert_midi_notes that modify MIDI data.

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

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

The description does not provide explicit guidance on when to use this tool versus alternatives (e.g., when to use list_tracks first). However, the purpose is clear enough that an agent can infer its usage for reading existing MIDI notes.

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 declare destructiveHint=true, and the description confirms the tool modifies data by writing notes. It adds behavioral details such as batching, tempo correction, and a call cap, which go beyond the annotation. No contradiction with annotations.

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

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

The description is extremely concise: two sentences plus a third for the cap. The first sentence front-loads the core purpose, and every subsequent sentence adds valuable context without waste.

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 an output schema (inferred), return values are covered elsewhere. The description explains the key context: batching rationale, tempo alignment, and performance cap. It is sufficient for an agent to use the tool correctly, though it could mention what happens if the cap is exceeded.

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 has detailed descriptions for all properties, so schema_description_coverage is effectively high. The description adds value by clarifying that notes are in beats and mentioning the constant MAX_NOTES_PER_CALL for the cap, which is not in 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 clearly states 'Batch-write notes into a take' and emphasizes the key capability of PPQ/tempo-correct batch writing in one round-trip. This specific verb-resource pair ('write notes into a take') distinguishes it from sibling tools like 'quantize_notes' or 'transpose_notes'.

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 why batching is necessary ('per-note round-trips would hit the ~10 ops/sec file-IPC ceiling') and mentions a cap to avoid stalling the audio thread. While it doesn't explicitly state when not to use it or suggest alternatives, the rationale provides clear context for when this tool should be used over individual note insertion.

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 adds context beyond the readOnlyHint annotation by explaining that fingerprints are cached results of an analysis pipeline over per-era reference tracks. This helps the agent understand the nature of the data.

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 consists of two sentences, front-loading the verb and resource, with no wasted words. It efficiently conveys purpose and context.

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 no parameters and the presence of an output schema, the description provides sufficient context about what the tool returns and how the fingerprints are generated. It is complete for an agent to understand and invoke the tool.

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

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

With zero parameters, the description does not need to explain parameter semantics. The baseline is 4, and the description adds value by describing the output content.

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 lists cached target fingerprints, provides concrete examples (e.g., 'classical', 'hiphop', 'dominic-fike-sunburn'), and explains what they represent (analysis pipeline over reference tracks). This specificity distinguishes it from sibling tools like list_tracks.

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

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

The description implies usage for retrieving available style fingerprints but lacks explicit guidance on when to use this tool versus alternatives. No exclusions or prerequisites are mentioned.

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

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

Annotations already provide readOnlyHint=true. The description adds valuable context about the output content (typed tree with specific fields), which goes beyond what annotations convey.

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, front-loaded sentence with no unnecessary words. Every word adds value.

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 no parameters and the presence of an output schema, the description is complete. It lists the key fields of the output, sufficient for agent understanding.

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 has no parameters (100% coverage), so no parameter explanation is needed. Baseline score of 4 is appropriate.

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

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

The description clearly states the tool returns a typed track tree listing specific fields (name, vol/pan, mute/solo, role, FX-chain names, item count). It distinguishes from siblings like create_track or get_track_midi.

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 this is for viewing track structure but does not explicitly state when to use it over alternatives or any preconditions. No when-not guidance is provided.

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

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

Beyond the destructiveHint annotation, the description adds minimal behavioral context. It mentions internal action IDs but does not disclose side effects (e.g., stopping current playback, recording over existing data) or any required states. Annotations already signal destructiveness, but the description fails to elaborate.

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 sentence that immediately states the tool's purpose and enumerates the commands. No unnecessary words, and the most critical 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 one-parameter tool with an output schema, the description covers the main commands but omits details like exact string format (case sensitivity) and expected behavior during recording (e.g., whether it fails if already recording). It is minimally complete but leaves room for agent uncertainty.

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 defines 'command' as a string with no enum values, so the description compensates by listing the three possible values: 'play', 'stop', 'record'. This provides essential semantic meaning that the schema lacks, though it could be more precise about format (e.g., case sensitivity).

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 is for transport control with three specific commands: play, stop, and record. It distinguishes itself from siblings as the only transport control tool, and the verb 'control' combined with listed operations makes the purpose unambiguous.

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

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

No guidance is provided on when to use this tool versus alternatives or when not to use it. The description lacks any usage context, prerequisites, or conditions, leaving the agent to infer when transport control is 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?

Annotations already include destructiveHint: true, and the description adds the context that this is a cleanup operation. This adequately discloses that the tool modifies the notes.

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 sentence that efficiently conveys purpose and context without unnecessary 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?

Description provides purpose and timing context, but lacks details on parameter semantics and does not specify what the output schema contains. Given the simple nature and presence of output schema, it is acceptable but not fully complete.

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

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

Schema description coverage is 0% and the description does not explain the parameters. 'Quantize... to a grid' hints at the grid parameter, but no details on the track parameter or valid values for grid are given.

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 clearly states the tool quantizes a take's notes to a grid for cleanup before or after analysis. This verb+resource combination distinguishes it from sibling analysis tools like analyze_groove or analyze_harmony.

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?

Description implies usage as a cleanup step before or after analysis, providing clear context. However, it does not explicitly mention when not to use or name alternatives 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?

Reinforces readOnlyHint from annotations and adds honest caveats about detection confidence and taste calls, providing additional behavioral transparency beyond annotations.

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

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

Four sentences that efficiently convey purpose, usage, and caveats without fluff. Front-loaded with the core action.

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 output schema exists, return values don't need description. The tool has low complexity with one parameter; description covers main aspects but lacks error conditions or prerequisites, which is acceptable for a read-only analysis tool.

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

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

The description mentions 'target fingerprint' which maps to the 'target_style' parameter, but does not explicitly describe the parameter format or provide examples. With 0% schema coverage, some compensation exists but not full.

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?

Clearly states the tool diffs current project against target fingerprint and returns an EditPlan with specific dimensions. Verbs and resource are explicit, and the distinction from 'apply_changes' is made.

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

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

Explicitly states it is read-only and instructs to surface reasons to user for approval then call apply_changes, providing clear when-to-use and follow-up step.

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 already indicate readOnlyHint=true, and the description adds that it measures LUFS/spectrum. No further behavioral details are provided, but the annotations cover safety aspects.

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 sentence, front-loaded with action and purpose, no waste.

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 zero parameters and presence of output schema, the description fully covers the tool's purpose and behavior.

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?

No parameters exist, so the description cannot add parameter semantics. Baseline for zero-param tools is 4.

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 renders then measures LUFS/spectrum, distinct from sibling tools like render_project or analyze_audio_character, which either only render or only analyze.

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

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

The description implies use for self-checking and iteration without a human ear, but does not explicitly state when not to use or name alternatives, though the context suggests it replaces separate render + analyze steps.

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 already indicate destructiveHint=true. The description adds that it performs a headless render but does not disclose what is destroyed (e.g., overwritten files) or any side effects. Minimal added value beyond annotations.

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

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

The description is a single sentence, which is concise, but it includes cryptic references (Main_OnCommand(41824)) that reduce clarity. It could be restructured to be more accessible.

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 destructive hint and lack of parameter explanations, the description omits important context like file overwriting behavior, prerequisites (e.g., open project), or what the output schema contains. An output schema exists but its content is not leveraged 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%. The description mentions 'format/bounds' but bounds is not a parameter, and it does not explain out_path or fmt. No parameter descriptions are provided, leaving the agent to infer from names only.

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 'Headless render to WAV/MP3', clearly indicating the action (render) and output formats. The technical details suggest it renders the entire project, distinguishing it from sibling tools like render_stems. However, the jargon may obscure clarity for some agents.

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 vs alternatives like render_stems or render_and_audit. The description provides no context for choosing this tool over 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?

The annotation 'destructiveHint: true' already signals destructiveness. The description adds the 'sequential solo' behavioral detail, but does not disclose other traits like file overwriting or required permissions. The mention of feeding into another tool is also useful.

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 single sentence is concise and front-loaded, but it sacrifices essential parameter information. The description could be structured to include key details without expanding significantly.

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?

Despite having an output schema, the description omits return value details and does not explain how the stems are used by 'analyze_audio_character'. The missing parameter semantics further reduce completeness.

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 has one required parameter 'out_dir' with no description, and schema coverage is 0%. The tool description does not mention 'out_dir' at all, leaving the agent with no guide on what value to 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 clearly states it renders per-track stems and mentions the method (sequential solo). It distinguishes from sibling 'render_project' by focusing on individual tracks. However, it could be more explicit about what 'stems' are and how it differs from 'render_and_audit'.

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 as a precursor to 'analyze_audio_character', giving context for when to use it. However, it lacks explicit when-not-to-use guidance and does not compare to alternatives like 'render_project' or 'render_and_audit'.

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 already mark destructiveHint=true. The description adds the name→index resolution feature but does not disclose other behavioral traits such as whether the change is reversible, authorization requirements, or side effects. It relies on 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?

A single sentence that is front-loaded with the core purpose. No wasted words; the parenthetical provides key technical detail without verbosity.

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 minimal. It explains name resolution but omits details on other parameters (track, fx, value) and usage context. Although an output schema exists, the description does not address what the tool returns or error conditions.

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 adds meaning to the 'param' parameter by explaining name→index resolution. However, it does not clarify 'track', 'fx', or 'value' (e.g., range or units). Partial 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 'Set an FX parameter', which is a specific verb+resource. It distinguishes from sibling tools like get_fx_params (read) and add_fx_by_name (add).

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 setting FX parameters by name, but does not explicitly state when to use this tool versus alternatives like get_fx_params or add_fx_by_name. No guidance on prerequisites or complementary 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?

The annotation destructiveHint=true already signals destructive action. The description adds the formula (seconds_per_beat = 60 / bpm), which provides behavioral context beyond the annotation, though it doesn't detail other 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 single sentence with the formula, no wasted words. It is front-loaded with the core purpose and efficiently conveys the essence.

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

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

With one parameter, an output schema present, and a destructive hint annotation, the description is complete for the tool's simplicity. It covers the purpose and a key behavioral detail (the formula).

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 tool has only one parameter, bpm, whose meaning is obvious. The description provides the downstream formula but does not elaborate on the parameter beyond its name and constraints in 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 tool sets the project tempo in BPM, with a downstream formula. The verb 'set' and resource 'project tempo' are specific, and it distinguishes from siblings like set_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 usage for setting tempo, a distinct task. While it doesn't explicitly list when-to-use or alternatives, the context of sibling tools (e.g., set_time_signature) makes the use case 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?

The annotation already declares destructiveHint=true. The description only says 'Set', which implies a change, but adds no extra behavioral context such as whether existing time signatures are overwritten or if it affects MIDI items.

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 short sentence, which is concise. However, it could be expanded to include parameter hints without becoming verbose.

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

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

For a destructive tool with no output schema details provided, the description does not explain return values or side effects. It lacks completeness for confident use.

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 has no descriptions for parameters (coverage 0%). The description does not mention parameters like numerator or denominator, leaving their meaning unclear.

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 'Set' and the resource 'project time signature'. It distinguishes from siblings like set_tempo, but there is no other time signature tool, so no sibling differentiation needed. Still clear.

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 on when to use this tool vs alternatives (e.g., set_tempo). No prerequisites or context for use 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?

Annotations already indicate destructiveHint=true, so the agent knows it's a mutation. The description adds the behavioral detail that it accepts fuzzy values like '-6dB' and 'center', which is useful. However, it does not elaborate on other behaviors such as range limits or side effects.

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

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

The description is extremely concise at two sentences, front-loading the purpose and then adding key behavioral detail. Every word adds value with no 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?

For a simple setter with 3 parameters, the description covers the main behavior and input format. It does not specify how tracks are identified (name vs index), but given the schema's track string, this is minor. The presence of an output schema further reduces the need to describe returns.

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 has no descriptions for parameters (0% coverage). The description compensates by providing concrete examples of acceptable fuzzy values for volume and pan ('-6dB', '+3', '50%', etc.), adding meaning beyond the schema. The track parameter is left implied but is straightforward.

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 clearly states it sets fader/pan for a track, using the verb 'Set' and specifying the resource as 'fader/pan'. This distinguishes it from sibling tools like set_fx_param or set_tempo, which operate on different resources.

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. The description only states what it does, not when or when not to use it. Sibling tools provide many alternatives like set_fx_param, but no context is given to differentiate them.

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 already declare readOnlyHint=true, so the tool is read-only. The description adds minimal behavioral context beyond the output format. No mention of side effects, rate limits, or other behavioral traits.

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 sentence, concise but under-specified. It front-loads the purpose but omits essential details, making it less helpful despite brevity.

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 3 parameters, an output schema (unshown), and no schema descriptions, the description is inadequate. It doesn't explain the output format (Roman numerals, MIDI) or genre types, leaving significant gaps.

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 does not explain individual parameters (key, mode, genre). Schema coverage is 0%, so the description should compensate but fails to clarify parameter semantics, defaults, or acceptable 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?

The description clearly indicates the tool generates chord progressions based on genre and key, outputting Roman numerals and MIDI data. It distinguishes from siblings like analyze_harmony (analyzes existing) and constrain_to_key (constrains), but could be more explicit about the generative nature.

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 on when to use this tool versus alternatives like insert_midi_notes or analyze_harmony. The description does not mention prerequisites, exclusions, or context, leaving the agent to infer usage.

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 already set destructiveHint=true, indicating mutation. The description clarifies the resource ('take's notes') and purpose ('key/mode retargeting'), but doesn't disclose additional behavioral details such as exactly which properties are modified or any prerequisites.

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 single-sentence description is concise and front-loaded with key action and resource. However, it could include brief parameter hints without becoming verbose while still adding value.

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?

Despite having an output schema and only two parameters, the description omits critical context: what happens to existing notes, whether the transpose is absolute or relative, and any constraints on semitones. This is insufficient for a mutation tool with destructiveHint=true.

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% with no parameter descriptions. The description does not explain the 'track' or 'semitones' parameters, forcing the agent to rely solely on names. This is a significant gap for a tool with only two required parameters.

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?

Specific verb 'Transpose' and resource 'take's notes' clearly stated. The phrase 'APPLY verb for key/mode retargeting' distinguishes it from sibling tools like 'constrain_to_key' which may set a fixed key rather than transpose.

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 after key/mode retargeting analysis but lacks explicit when-to-use or when-not-to-use guidance. No alternatives are listed, leaving the agent to infer context from the sibling list.

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