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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It not only states the action and return value, but also reveals an important side effect: new tracks inherit SV's default singer, and if none is configured, the user must pick one in the UI. This goes beyond the minimum and helps the agent anticipate user interaction.

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 the action and resource, followed by a concise caveat. Every sentence earns its place with no fluff or repetition.

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

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

The tool has a simple interface (one optional param, no output schema), and the description covers the primary behavior, return value, and a notable behavioral caveat. It is complete enough for an agent to select and 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 schema already fully documents the single optional 'name' parameter with a clear description. The tool description adds no additional parameter-level meaning, so the baseline of 3 applies as the schema does the heavy lifting.

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

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

The description uses the specific verb 'add' with a clear resource ('a new track') and the context ('to the current Synthesizer V Studio project'). It also states the return value (1-based track index), distinguishing it from sibling tools like create_group.

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

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

The description provides clear context for when to use the tool (adding a track to the current project), but does not explicitly mention alternatives or when not to use it. It lacks a direct comparison to sibling tools, but the purpose is sufficiently distinct.

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 explains that the group is empty, returns the group index, and inherits SV's default singer, adding useful behavioral context. However, it does not mention error handling (e.g., invalid track) or side effects beyond creation, which keeps it from a 5.

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, front-loaded with the main action, and efficiently provides context about the SV singer assignment and sibling tool behavior. 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 only two parameters and no output schema, the description covers the essential aspects: what it does, when to use it, and what it returns (group index). It also explains the singer inheritance, making it sufficiently complete for this tool's 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?

Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema, though it does clarify the track is the target and mentions the optional name is for the new group. This is consistent with the schema's own 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 'Create a new empty note group on a track and return its group index,' which specifies a clear verb and resource. It also distinguishes itself from the sibling insert_notes by noting that insert_notes can auto-create a group when the track has none, making this tool's purpose more specific.

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 states when to use this tool ('the usual first step before insert_notes when no suitable group exists yet') and mentions an alternative behavior ('insert_notes also auto-creates a group when the track has none'), providing clear contextual guidance.

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

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

With no annotations, the description fully discloses key behavior: it deletes by onset-order indices, renumbers remaining notes, and is one undo step. This reveals side effects and reversibility, exceeding typical tool descriptions.

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, no fluff. The first sentence states the action and source; the second covers the crucial side effects. Everything 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?

Despite no output schema, the description covers the essential context for a delete operation: how to get indices, the renumbering side effect, and undo behavior. For a 3-parameter tool with 100% schema coverage, this is 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 100%, so the baseline is 3. The description adds the critical semantic that indexes are on-order indices from get_notes, but this is a minor contextual addition beyond what the schema already documents. No significant parameter meaning is added.

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 action ('Delete notes'), specifies the resource ('notes by their current onset-order indices'), and ties it to a data source ('from get_notes'). This clearly distinguishes it from sibling tools like update_notes or insert_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?

It provides clear usage context: indices come from get_notes, and the tool should be re-read with get_notes after deletion due to renumbering. While it doesn't explicitly state when not to use it, the guidance is specific enough for an agent to select it appropriately.

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 takes on full responsibility. It proactively explains the `submitted=false` return value and the appropriate user-facing action, which is valuable for runtime 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 sentences, front-loaded with the primary action, and every clause earns its place. It's concise without sacrificing needed 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?

For a zero-parameter tool with no output schema, the description fully covers what the agent needs: what it does, what it returns, and how to proceed. It is complete in its context.

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

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

The tool has zero parameters, so the schema provides full coverage. The description adds no parameter details because there are none to explain, aligning with the baseline for parameterless 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 uses a specific verb ('Fetch') and resource ('syllable plan the user submitted from the lyrics editor page'), clearly distinguishing it from sibling tools. The reference to open_lyrics_editor provides context without conflating them.

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 implies when to use (after opening the editor) and instructs the agent to ask the user to press submit if nothing is submitted yet. However, it doesn't explicitly contrast with alternatives, though none exist for this specific purpose.

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 disclosure burden. It reveals key behaviors: note indices are ordered by onset and shift upon insert/delete/move, positions use a specific 'measure.beat' format with 1-based indexing, and 'phonemes' is conditionally present only for user overrides. This goes beyond a simple list and gives the agent critical expectations about the returned data's semantics and stability.

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, tightly packed with essential information. The main purpose is front-loaded, and additional details are presented in a logical, readable order. Every sentence contributes useful context without 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?

For a read-only list tool with no output schema, the description explains the return format (measure.beat, phonemes conditionality) and the order (by onset). It also flags the shifting note index behavior. However, it does not enumerate all fields of a note object (e.g., lyrics, onset, duration), so the agent must infer some return structure. Given the complexity of the tool and the absence of an output schema, this is a minor but notable 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?

The schema already covers 100% of parameters with descriptions, so the baseline is 3. The description adds meaningful context: it explains the 'measure.beat' position format, the conditional 'phonemes' field, and references get_project_info for group semantics. This adds value beyond the raw schema, especially for understanding how fromMeasure/toMeasure relate to the position format, though it doesn't elaborate on every 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 opens with a specific verb+resource: 'List the notes of a track in the current Synthesizer V Studio project.' This clearly distinguishes the tool from siblings like get_phrases or get_phonemes by stating the exact object (notes) and scope (current project track). It also immediately establishes the context of the Synthesizer V Studio domain.

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 practical usage guidance: it reminds the agent that track indices are 1-based and directs to get_project_info for reference. It also warns that note indices shift on edits, implying the tool should be re-read before making changes. However, it does not explicitly mention alternatives or when not to use the tool, which would have earned a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the asynchronous converter behavior via the `complete` flag and advises retrying, which adds meaningful context. It does not explicitly state read-only nature, but the verb 'Get' implies it.

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

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

The description is three sentences, front-loaded with the core purpose, followed by a use case and a vital async note. Every sentence earns its place with 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?

Given no output schema, the description sufficiently covers the return scope (phonemes plus overrides) and the important `complete` flag behavior. It also situates the tool's use case. It could be more exhaustive about exact return shape, but it is complete enough for a focused getter 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?

Schema description coverage is 100% for both parameters, including detailed descriptions for `group` (default behavior and SV Studio 2 nuance) and `track` (1-based). The description adds no parameter-specific details beyond the schema, so the baseline score of 3 applies.

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

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

The description clearly states the tool gets the phonemes used for synthesis for every note in a group, specifically SV's text-to-phoneme output alongside user overrides. This distinguishes it from sibling tools like set_phonemes and get_notes with a specific verb and resource.

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

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

Provides a clear use case ('Useful to check pronunciation before or after edits') that conveys when to use the tool. It does not explicitly name alternatives or state when-not to use it, but the context is sufficient for an agent to recognize its purpose relative to 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 the full burden of behavioral disclosure. It thoroughly describes the analysis behavior (finding rests, identifying phrases, flagging section boundaries) and details the output semantics, including the meaning of the 'shape' label. While it doesn't explicitly state side effects, the term 'analyze' implies a read-only operation.

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

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

The description is well-structured and front-loaded with the core purpose. Each sentence adds value: it explains the mechanism, the output fields, the shape-label semantics, and the recommended next step. No redundant or filler content; it is appropriately detailed without being verbose.

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

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

Given the tool has no output schema, the description compensates by listing the phrase fields (note index range, note count, position, pitch range, lyrics, shape) and explaining their meaning. It also covers the use-case context and follow-up action. The tool has 4 params but no output schema, and the description is sufficiently complete for an agent to understand when and how to use it.

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

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

Schema documentation covers all four parameters with descriptions (100% coverage), so the baseline is 3. The description does not add additional parameter-specific meaning beyond what the schema already provides. It references 'restThreshold' and 'sectionThreshold' only implicitly via 'long rests' and 'section boundaries' but does not elaborate on their syntax or 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 clearly states the tool's function: 'Analyze a track's melody into phrases by finding rests between notes.' It identifies the specific resource (track melody) and distinguishes this analysis tool from sibling tools like get_notes. The context 'recommended first step when flowing lyrics onto an imported melody' further clarifies its unique role.

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 frames this as 'the recommended first step' for a specific workflow (flowing lyrics onto an imported melody) and directs the user to follow up with set_lyrics. This provides clear usage context, though it does not explicitly mention when *not* to use this tool or directly compare against alternatives like get_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?

With no annotations provided, the description carries the full burden. It correctly indicates a read-only overview action and lists returned data. However, it does not explicitly confirm that the tool makes no modifications or describe behavior if no project is open, leaving minor gaps in behavioral disclosure.

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

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

The description is two sentences long, front-loaded with the core purpose, and every word adds value. The structure is highly efficient, covering what the tool does and why it matters without 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 no-parameter read-only tool, the description lists the key return categories and highlights the importance of track indices for other tools. It is almost complete, though it could mention potential error states or a slightly more detailed return structure, but given the simplicity, it is quite 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 tool has zero parameters, so the input schema is effectively empty. The description appropriately adds no parameter details, and the baseline of 4 applies since there is nothing to explain 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 clearly states the tool's purpose: getting an overview of the currently open project, listing concrete contents like file name, tempo marks, time signatures, and track list with note counts. It also distinguishes itself from siblings by noting that track indices returned here are used by all other tools, which positions it as a foundational getter.

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 second sentence explicitly conveys usage context: 'Track indices returned here are used by all other tools,' indicating this tool should be called first to obtain indices needed by sibling tools. It provides clear guidance on when to use relative to alternatives, though it does not explicitly state exclusions or when not to use.

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

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 discloses that the insertion is one undo step, returns a snapshot of all notes overlapping the inserted range with fresh indices, and explains the start-position chaining rule. This gives the agent important operational insight beyond the schema, though failure modes or permission requirements are not mentioned.

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 four sentences, each with a specific purpose: core action, note requirements and start behavior, undo step, and lyric conventions. It is front-loaded with the main purpose and then provides necessary detail without redundancy. No filler or tautology.

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 (nested notes array, optional start chaining, language-specific lyrics) and no output schema, the description covers the essential behaviors: what is inserted, how positioning works, lyric rules, undo grouping, and the return snapshot. It omits mention of the `group` parameter, but the schema explains its default and purpose. Overall, the description is complete enough for an agent to invoke the tool correctly without relying on external documentation.

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 covers 100% of parameters, but the description adds significant meaning beyond the schema. It explains that omitting `start` chains notes sequentially and that the first note must have an explicit start, and it details lyric conventions (one kana per note, '-' for vowel extension, '+' for multi-syllable English). This enriches the `lyrics` and `start` parameters beyond their schema descriptions. The `group` parameter is not mentioned in the description, but its schema description is sufficiently clear.

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: "Insert notes into a track (1-based index) of the current Synthesizer V Studio project." This clearly distinguishes the tool from siblings like update_notes, delete_notes, and get_notes. It also gives the core action and context in one sentence.

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 usage context: required note fields, the behavior of omitted start positions, and detailed lyric conventions (Japanese kana, '-' for vowel extension, '+' for English word continuation). While it doesn't explicitly name alternatives like update_notes, the guidance is specific and actionable for inserting notes. No exclusions are stated, but the context 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?

With no annotations, the description carries the burden and does well: it discloses that this is an interactive browser page, that changes are not applied yet ('BEFORE they are applied'), and that the user must confirm submission. It does not cover edge cases like cancellation or page load failures, but the core behavior is 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 three sentences long and every sentence contributes: what it does, how the editor works, and what to do after. It is slightly longer than strictly necessary but well structured and free of 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?

Given the interactive complexity and lack of output schema, the description covers the full lifecycle: when to open, what the editor shows, and the follow-up calls. It doesn't explain what the tool returns or what happens on failure, but the workflow is otherwise complete and actionable.

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 covers 100% of parameters, but the description adds the critical format example ('fixing あし た to あ した') and explains the live count constraint, giving meaning to noteCount and syllables beyond their schema descriptions. This elevates it above a baseline 3.

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 opens a local browser page for reviewing and adjusting lyric syllable boundaries, with a concrete example. It is distinct from siblings like get_lyrics_editor_result and set_lyrics by explicitly positioning itself as the pre-application review step.

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 explicit workflow guidance: use before applying readings, and after user submission call get_lyrics_editor_result and set_lyrics. This tells the agent exactly when and how to chain this tool with others, which is better than simply describing the tool in isolation.

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 success returns host information (SV edition, version, OS) and suggests it as a diagnostic step, but it does not describe failure behavior (e.g., what happens if the bridge is not running) or explicitly rule out side effects. This is a moderate gap for a tool that serves as a health check.

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 only two sentences, front-loaded with the purpose, followed by the success output and a direct usage tip. Every word earns its place, with no repetition 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?

Given the tool's low complexity (no parameters, no output schema), the description covers the purpose, success return, and a practical usage scenario. It could be slightly more complete by describing failure behavior, but overall it provides enough context for an agent to select and invoke the tool correctly.

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

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

The tool has zero parameters, so the input schema trivially provides 100% coverage. The description does not need to explain parameters, and the baseline for a zero-parameter tool is 4, which is appropriate here.

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 'check' and explicitly names the resource 'bridge script inside Synthesizer V Studio', clearly distinguishing it from sibling tools that manipulate notes or tracks. It is unambiguous and immediately conveys 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?

The description provides an explicit usage scenario: 'Call this first if other tools time out.' This gives clear contextual guidance for when to invoke the tool. However, it does not explicitly mention when not to use it or suggest alternatives, but for a ping/health check this is sufficient.

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 that the override applies to specific note indices, that empty string resets to the group/track default, and implicitly that this modifies note language. It doesn't mention permissions or reversibility, but for a non-destructive language override, these are less critical. The explanation of the default language context adds useful behavioral insight.

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, front-loaded with the verb and object, and every clause contributes: the use case, the scope, and the reset behavior. 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 setter with no output schema and no annotations, the description is complete enough: it explains the purpose, the target, and the special reset case. Minor gaps remain about return value and interactions with existing overrides, but these are not significant for a well-scoped 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?

Schema description coverage is 100%, so the baseline is 3. The tool description adds no new parameter meaning; 'Pass an empty string to reset' is already mirrored in the language parameter's description. The mention of 'given note indices' duplicates the indexes description. No extra semantic enrichment is provided 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 opens with a specific verb+resource: 'Set a per-note language override.' It clearly distinguishes from sibling tools like set_lyrics and set_phonemes by focusing on language, and provides a concrete example (English word inside Japanese lyrics) and reset behavior.

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 states when to use it: 'for mixed-language songs' and explains the empty-string reset path. It doesn't explicitly list when not to use it or alternatives, but the niche use case is clear. It could have explicitly contrasted with setting a group/track-wide language, but the group parameter semantics cover that.

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 transparency burden and does well: it discloses the failure mode ('Fails if the array runs past the last note'), the undo behavior ('One undo step'), and special lyrical semantics for '-' and '+'. It does not explicitly mention overwriting behavior or permission requirements, but the core behavioral traits are covered.

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, each earning its place. The primary action is front-loaded, followed by mapping rules, language-specific syntax, and error/undo behavior. No filler 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 complete for a moderate-complexity tool: it covers the operational flow, error condition, undo, and special lyric syntax. There is no output schema, so return values are not expected. It could mention what happens if the lyrics array is shorter than the note range, but overall it is sufficiently comprehensive.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds meaningful semantics beyond the schema: it explains that each lyric string maps to one note in onset order, and clarifies the special meaning of '-' and '+'. This supplements the schema's generic 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?

Description opens with a specific verb+resource: 'Assign lyrics to consecutive existing notes' and gives the context 'the typical way to put lyrics on an existing melody' with a reference to get_notes. It clearly distinguishes from sibling tools like insert_notes or open_lyrics_editor.

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 states the typical use case ('typical way to put lyrics on an existing melody') and the ordering (each array element goes to one note in onset order), which helps the agent decide when to use it. However, it does not explicitly name alternative tools or exclusion conditions, though the sibling context implies the distinction.

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 transparency burden. It discloses the mutation behavior, the reset capability, and the one undo step, which is valuable. It doesn't cover potential errors or permissions, but for this domain it adequately describes what happens.

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, front-loaded with the main action, and includes essential details (examples and reset behavior) in three sentences. Every sentence adds value and there is no redundancy with the schema.

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 and lack of output schema, the description is nearly complete. It explains the note addressing, phoneme format, reset behavior, and undo step. It could mention error conditions or constraints on valid phonemes, but the provided information is sufficient for most use 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 already provides descriptions for all parameters (100% coverage), so baseline is 3. The description adds meaningful examples of phoneme formatting (Japanese/English) and the empty string reset semantics, which goes beyond the schema. Thus a 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 states a specific verb ('Override') and resource ('phonemes of specific notes'), with the indexing method ('by onset-order index from get_notes') clearly defined. It distinguishes itself from sibling tools like 'get_phonemes' and 'set_lyrics' by focusing on phoneme overrides.

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 for use: it explains how to specify notes (via get_notes index) and the default group behavior, and mentions empty string to reset. However, it does not explicitly state when not to use it or contrast with alternatives like set_lyrics, so it falls short of a 5.

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

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

With no annotations, description discloses key behaviors: removals applied before additions, global effect on measure/beat mapping, one undo step, and return of resulting signature list. No contradictions.

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

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

Three sentences, each with unique value: purpose/usage, warning, and undo/return. Front-loaded and 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?

Explains return value, side effects, ordering, and use case. Given moderate complexity and no output schema, description is complete enough for correct tool 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 descriptions cover 100% of parameters, so baseline is 3. Description adds context about order (removals before additions) but doesn't add meaning beyond schema for individual 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?

States a clear action (add/update/remove) on a specific resource (time signature marks) with a purpose (so the grid matches music). Distinguishes from get_phrases by noting it is for setting meter while get_phrases is for inferring it.

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 gives use case (after importing MIDI without meter information), points to alternative get_phrases for inference, and advises setting signatures before position-based work. Clear when-to-use and reference to alternative.

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 full behavioral burden. It discloses partial updates ('Only the provided fields change'), re-sorting side effects, the need to use fresh indices, a return snapshot, and the one-undo-step behavior. This is highly 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 concise: three sentences, front-loaded with purpose, and every sentence adds meaningful information without repetition or fluff.

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

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

Covers key operational caveats (re-sort, undo, snapshot) and orients the user to get_notes. It does not specify the return snapshot structure, but the absence of an output schema and the description's mention of the snapshot make it sufficiently complete for a tool with rich schema documentation.

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

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

The schema already has 100% coverage with descriptions for all parameters. The description adds minimal parameter-level meaning, only reinforcing that indices come from get_notes and that moving notes can re-sort the group. Meets the baseline for schema-heavy 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 a specific verb ('Edit') and resource ('existing notes'), and specifies the indexing method ('current onset-order index'). It distinguishes from sibling tools like insert_notes and delete_notes by targeting existing notes for modification.

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

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

Provides clear context: notes are addressed by indices from get_notes, and users are instructed to use the returned snapshot for follow-up edits. It does not explicitly enumerate when not to use this tool versus alternatives, but the context strongly implies it.

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