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

With no annotations, the description carries full burden but only states the basic action. It does not disclose side effects, error conditions, or behavior such as overwriting existing symbols, leaving significant behavioral gaps.

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

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

The description is extremely concise, two sentences that front-load the purpose without any 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?

Given no annotations and 0% schema coverage, the description covers parameter semantics minimally but glosses over outcome or constraints. It is adequate for a simple tool but not fully 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?

Although schema coverage is 0%, the description adds meaning by specifying that measure is 1-indexed and providing chord symbol examples, which aids understanding beyond the raw types.

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 ('Add'), the resource ('chord symbol'), and the context ('in the live score'), making it distinct from siblings like add_live_rehearsal_mark.

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 (e.g., for chord symbols vs. rehearsal marks) or any prerequisites or conditions are provided.

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

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

No annotations provided, so the description carries the burden. It only states 'Add a rehearsal mark' without disclosing side effects (e.g., overwriting existing marks), required connections, or error handling for invalid measures.

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, using a single sentence plus a compact Args block. Every word adds value, and it is front-loaded with the core purpose.

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 (not shown) and only two parameters, the description covers the basics. However, it lacks information on return values, edge cases (e.g., invalid measure), and behavioral details that would fully equip an agent, especially with no annotations.

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

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

The description adds meaning beyond the schema: '1-indexed' for measure and examples ('A', 'B', 'Intro') for text. With 0% schema description coverage, this effectively explains both parameters, though it could further clarify constraints (e.g., allowed characters).

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 ('Add') and resource ('rehearsal mark') with context 'in the live score'. It distinguishes from sibling tools like add_live_chord_symbol by specifying the type of mark, though it could be more explicit about the tool's 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?

No guidance on when to use this tool vs alternatives (e.g., add_live_chord_symbol). Missing prerequisites or conditions such as needing a connection to a score app or that the tool is for a specific measure and text.

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

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions the connection mechanism (WebSocket) but lacks details on connection behavior, such as idempotency, error handling, timeout, or what the tool returns upon success or failure.

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 a clear first line stating the purpose, followed by background information, then parameter descriptions. Every sentence serves a purpose without unnecessary 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 tool connects to a running application, which has moderate complexity. The description covers prerequisites (Dorico 4+, WebSocket server) but omits what the tool returns (output schema exists but is not described) and error states. It is adequate but lacks completeness for a connection 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 schema has 0% description coverage, so the description adds value by explaining host and port are WebSocket-related and noting defaults. However, it largely repeats what the schema already shows in titles and defaults, adding only minimal new context.

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

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

The description clearly states 'Connect to a running Dorico instance via its Remote Control API.' It uses a specific verb (connect) and resource (Dorico instance), and distinguishes from sibling tools like connect_to_musescore and connect_to_sibelius by naming Dorico specifically.

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 context about Dorico's built-in WebSocket server and port configuration, indicating when the tool can be used (Dorico 4+). It does not explicitly state when not to use or compare to alternatives, but the sibling differentiation is clear from the tool name.

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

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

No annotations are provided, so the description must cover behavioral traits. It mentions the plugin requirement and that it connects via WebSocket, but it does not detail error handling, what happens on duplicate connections, or side effects beyond establishing a connection.

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 for the purpose and prerequisite, followed by parameter descriptions. It is front-loaded with the core action.

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

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

Given the tool has two simple optional parameters and an output schema (not shown but present), the description provides enough context to use the tool correctly. It lacks details on return values or error conditions, but the output schema likely covers that.

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

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

The schema has 0% description coverage, but the description adds meaning by explaining 'host: WebSocket host (default: localhost)' and 'port: WebSocket port (default: 8765).' This clarifies the purpose of each parameter beyond the schema's defaults and titles.

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

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

The description clearly states the verb 'Connect to' and the resource 'a running MuseScore instance'. It distinguishes from sibling tools like 'connect_to_dorico' and 'connect_to_sibelius' by specifying MuseScore.

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

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

It explicitly states the prerequisite: 'The MuseScore MCP Score Bridge plugin must be running.' This informs when to use the tool. However, it does not explicitly mention when not to use it (e.g., if already connected) or suggest alternatives.

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

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

No annotations, so description carries burden. Mentions WebSocket connection, version requirement, and no plugin needed. Does not describe expected return value, potential errors, or that it is a prerequisite for other Sibelius tools.

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?

Very concise with a brief intro and args section. No wasted words. Purpose 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 connection tool with 2 optional parameters, description covers essential aspects. Lacks details on return value or validation, but output schema may provide that.

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 0% but description explains both parameters: host (default localhost) and port (default 1898, Sibelius Connect default). Adds meaning beyond schema with defaults and typical use.

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 it connects to a running Sibelius instance via Sibelius Connect. Specifies version requirement (2024.3+) and that no plugin is needed. Distinguishes from siblings that connect to different apps (Dorico, MuseScore).

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 context: requires Sibelius Ultimate tier and a WebSocket server. Gives default ports. Does not explicitly state when not to use or alternatives, but sibling tools for other apps make it implicit.

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

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

Without annotations, the description carries the full burden but only mentions 'disconnect,' offering no details about side effects, errors, or state requirements (e.g., must be connected).

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 waste. However, it could be slightly more informative without losing conciseness, e.g., mentioning the need for an active connection.

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 no parameters and an output schema, the description is minimal. It lacks context about the effect on the app state, error handling, or when it is appropriate to 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?

There are no parameters, and schema coverage is 100%, so the description adds no param information. Baseline 4 applies per rubric (0 params).

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 (disconnect) and the target application (Dorico), distinguishing it from sibling tools like disconnect_from_musescore and disconnect_from_sibelius.

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

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

The description provides no guidance on when to use this tool versus alternatives like connect_to_dorico, or any prerequisites such as being currently connected.

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 bears the full burden of disclosing behavioral traits. It only states 'Disconnect' without revealing side effects (e.g., closing connection, potential data loss), authentication requirements, or safety implications. The description is minimally transparent.

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

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

The description is extremely concise at one short sentence. However, it borders on under-specification, as it simply restates the tool name. While efficient, it sacrifices informativeness for 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?

For a zero-parameter tool with an output schema, the description should still explain the effect and context (e.g., 'disconnects the live MuseScore connection'). The current description is incomplete, offering no operational details beyond the action itself, leaving the agent underinformed.

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 schema coverage is 100% by default. According to the calibration, 0 parameters have a baseline of 4. The description adds no param information, but this is acceptable as there are no parameters to document.

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 'Disconnect from MuseScore' is a tautology that simply restates the tool name with spaces and a period. It adds no new information and does not distinguish the tool from siblings like disconnect_from_dorico except by the resource name, which is already evident from the tool name.

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

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

No usage guidelines are provided. The description does not indicate when to use this tool (e.g., when connected to MuseScore) or when not to, nor does it mention alternative tools like connect_to_musescore or other disconnect tools. The agent receives no guidance on context.

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

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

No annotations provided, and the description fails to disclose behavioral traits such as whether the operation is safe, if it affects open files, or if it requires an active connection. The minimal text carries the full burden but omits essential context.

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

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

The description is extremely short (three words). While it is front-loaded, it does not earn its place beyond stating the obvious. For such a simple tool, it is minimally viable but lacks informative content.

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

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

Given the simplicity (no parameters, output schema exists but unspecified), the description should mention what happens after disconnect (e.g., cleanup, return value). It is too minimal to fully inform an agent about the tool's 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 schema coverage is complete. The description does not add meaning beyond the schema, but with zero parameters, baseline is 4. The trivial nature of the tool means no additional parameter info is needed.

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

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

The description 'Disconnect from Sibelius' clearly states the action and resource, distinguishing it from other disconnect tools like disconnect_from_dorico. It is a tautology but effectively communicates the purpose for a simple connection management tool.

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

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

No guidance on when to use this tool versus alternatives like disconnect_from_dorico or disconnect_from_musescore. The description lacks context about prerequisites or typical scenarios.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It states the tool is read-only ('Get information') and depends on an active connection. While not misleading, it lacks explicit statements about side effects, rate limits, or what happens if no connection exists (beyond the prerequisite). The description is adequate but not rich in behavioral detail.

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 long, front-loaded with the purpose and followed by a crucial prerequisite. Every word earns its place; there is 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 simplicity (no parameters, read-only info retrieval) and the presence of an output schema (which covers return values without need for description), the description is complete. It includes the essential prerequisite that an active connection is needed, which is critical 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 input schema has zero parameters and schema coverage is 100% by default. Per the guidelines, 0 parameters yields a baseline of 4. The description adds no param info because none are needed.

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

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

The description clearly states the tool's purpose: 'Get information about the currently open score.' The verb 'Get' and resource 'information about the currently open score' are specific, and the tool is easily distinguished from sibling connect tools (e.g., connect_to_musescore) or other action tools (e.g., add_live_chord_symbol, set_live_tempo).

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 'Requires an active connection — use connect_to_musescore, connect_to_dorico, or connect_to_sibelius first.' This provides clear prerequisite context. However, it does not mention when to use this tool versus other info-gathering siblings like get_measure_content or read_passage, which could have been helpful.

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

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

No annotations provided, so the description carries the burden. It states 'Read' (non-destructive) and mentions limited data for Dorico/Sibelius. However, it does not disclose error behavior, return format, or valid ranges for parameters, leaving gaps.

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

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

The description is concise: two sentences and a parameter list. Every sentence earns its place, and the purpose is front-loaded. 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?

Given the tool has an output schema, return values need not be explained. However, the description lacks information on error handling, valid ranges, or what 'content' constitutes (e.g., notes, rests). For a simple read 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 coverage is 0%, but the description adds indexing conventions: 'measure: Measure number (1-indexed)' and 'staff: Staff index (0-indexed, default: 0)'. This adds meaning beyond the schema types and defaults.

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

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

The description clearly states 'Read the content of a specific measure and staff', which distinguishes it from sibling tools like 'read_passage' or 'get_live_score_info'. The verb 'Read' and resource 'measure and staff' are specific and match the tool name.

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

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

The description mentions compatibility (MuseScore best, others limited) but does not explicitly state when to use this tool vs alternatives like 'read_passage' or 'get_selection_properties'. No when-not or exclusion criteria 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?

Without annotations, the description effectively conveys behavioral traits: it is a read operation that returns app-specific data (cursor info or properties). It discloses the dependency on active connection and the differences between applications. It does not explicitly state side effects (likely none) but adequately covers key behaviors.

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 a few sentences and bullet points to convey key information efficiently. Every sentence adds value, and the structure is well-organized for quick parsing by an agent.

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

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

Given the tool has no parameters, an output schema exists, and the complexity is moderate (app-dependent behavior), the description covers all necessary aspects: purpose, app-specific details, and prerequisites. It is complete for an agent to understand when and how to invoke the tool.

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

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

There are no parameters, so the baseline score is 4. The description does not need to add parameter info. The schema coverage is 100%, and the description's context about connection requirement is sufficient for an agent to understand the tool's invocation needs.

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

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

The description clearly states the tool retrieves properties of the current selection in a connected score application. It specifies the verb 'get' and the resource 'selection properties', and differentiates behavior between MuseScore (cursor position) and Dorico/Sibelius (remote control properties), effectively distinguishing it from sibling tools.

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

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

The description provides clear context for use, noting that it requires an active connection and is the closest the WebSocket API gets to reading score data. However, it does not explicitly mention when not to use this tool or suggest alternatives like get_measure_content or read_passage, slightly reducing clarity for an agent choosing between siblings.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It clearly states that the tool does not auto-connect and will error if not already connected. This is sufficient for a simple ping operation, though it doesn't define what 'responsive' means or indicate timeout 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?

The description is extremely concise with two sentences. The first sentence front-loads the core purpose, and the second provides necessary context. No extraneous information.

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

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

Given that there are no parameters and an output schema exists (as indicated by context signals), the description does not need to explain return values. It covers the key limitation (no auto-connect) and compatibility, making it complete for a simple health-check tool.

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

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

The tool has zero parameters, so the input schema is fully covered (100% coverage). The description adds no parameter information, which is acceptable. Per guidelines, 0 parameters yields a baseline score of 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 uses a specific verb 'Check' and resource 'connected score application' to clarify the tool's purpose. It explicitly states it works with any of the three applications (MuseScore, Dorico, Sibelius), clearly differentiating it from sibling connection and operation tools.

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

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

The description explicitly states when to use (to check responsiveness of a connected app) and when not (if not connected, it returns an error). It provides clear context, though it doesn't name alternative tools for establishing a connection, which are available among 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?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It mentions compatibility limitations but does not state whether the tool is read-only, requires a connection to a score app, or how errors are handled. Key behavioral context is missing.

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 structured as a brief paragraph followed by an Args list. It is concise, front-loaded with purpose, and each sentence contributes meaningful information 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?

The tool has an output schema, so the description does not need to detail return values, though it briefly mentions notes and rests. It covers parameter semantics and software compatibility, but lacks information about prerequisites (e.g., a live connection) or behavioral expectations, making it somewhat incomplete given the 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 0%, so the description must add meaning. It explains the index conventions (1-indexed for measures, 0-indexed for staff) and the default behavior for the staff parameter. This adds significant value beyond the schema, which only provides types and defaults.

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

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

The description clearly states the tool reads musical content from a range of measures in the live score, specifying the verb and resource. It distinguishes the tool by mentioning compatibility with different software, but does not explicitly differentiate from sibling tools like get_measure_content, which may have similar functionality.

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 usage guidance by noting that the tool works best with MuseScore, while Dorico and Sibelius return limited data. However, it does not specify when not to use this tool or mention alternatives among siblings (e.g., get_measure_content for single measures).

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

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

No annotations are provided, and the description does not disclose behavioral traits such as whether the operation is destructive, reversible, or requires specific permissions. It only states the action without 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 concise and front-loaded with the purpose. The Args format provides structured parameter details without verbosity, though it could be slightly tighter.

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

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

For a simple two-parameter tool with an output schema, the description covers the necessary parameter details and action. It is complete enough for this low 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?

With 0% schema description coverage, the description adds value by explaining that measure is 1-indexed and barline_type has enumerated valid values. This goes beyond the schema's bare types.

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 a barline type in the live score, using a specific verb and resource. It distinguishes itself from sibling tools like set_live_key_signature and set_live_tempo.

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

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

The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, 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?

No annotations are provided, so the description carries full burden for behavioral disclosure. It does not mention effects on existing key signatures, playback, constraints on fifths, or output behavior. The description is minimal beyond the basic action.

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 at 4 lines, but the 'Args' block adds some redundancy. The main action is front-loaded. No wasted sentences.

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

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

For a simple two-parameter mutation tool with an output schema, the description covers the purpose and parameter semantics adequately but lacks usage guidelines and behavioral context, leaving some gaps for the agent.

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

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

Schema description coverage is 0%, but the description adds meaning for both parameters: measure is specified as 1-indexed, and fifths is explained with examples (0=C, 2=D, -3=Eb). This significantly enhances understanding beyond the plain 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 starts with 'Set the key signature in the live score', clearly stating a specific verb ('set') and resource ('key signature'), and distinguishes from sibling tools like set_live_tempo or set_live_barline.

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 examples for fifths values and notes that measure is 1-indexed, which offers clear context for usage. However, it does not explicitly state when to use this tool versus alternatives or exclude certain scenarios.

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

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

No annotations provided, so the description must convey behavioral traits. It only states the action without disclosing side effects (e.g., affects playback), permissions needed, or limits. Minimal transparency beyond the basic 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?

Extremely concise: a one-liner plus structured parameter explanations. No wasted words. Information is front-loaded, making it easy to parse.

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

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

Has an output schema (content unknown) so return value explanation is not required. However, the description omits any mention of what happens after setting (e.g., immediate playback change). Adequate but could be more comprehensive about effects.

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

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

Schema description coverage is 0%, so the description carries the burden. It adequately explains each parameter: measure is 1-indexed, bpm is beats per minute, text is optional with examples. Adds meaningful semantics beyond schema titles.

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

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

The description clearly states the tool sets tempo in a live score. The verb 'set' and resource 'tempo' are explicit. It differentiates well from sibling tools like set_live_barline or set_live_key_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?

No guidance on when to use or alternatives. The description only lists parameters without context about prerequisites or when not to use. For a simple tool this may be acceptable, but it lacks explicit usage guidelines.

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

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

No annotations are provided, so the description carries full burden. It indicates mutation ('transpose') and explains semitone direction but does not disclose side effects, undoability, constraints like valid staff indices, or any destructive potential.

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

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

The description is concise and well-structured using an Args list. Every line provides essential information with no superfluous text.

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 parameter semantics adequately given the output schema exists, but it lacks broader context like when to use this tool, prerequisites (e.g., must be connected to a score app), or constraints on values.

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

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

Schema coverage is 0%, so the description provides all parameter details: index bases (1-indexed for measures, 0-indexed for staff) and semitone direction. This adds significant meaning beyond the schema's type-only information.

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 'Transpose a passage by a number of semitones in the live score,' specifying a strong verb and resource. It distinguishes from siblings like 'read_passage' and other operations.

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 context of siblings suggests no other transposition tool, but the description does not provide when 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?

No annotations are provided, so the description carries the full burden. It only states 'undo the last action' without detailing limits, scope, or effects, leaving behavioral traits unclear.

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 wasted words, but it could be slightly more informative without losing conciseness.

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, output schema present), the description is adequate for understanding the core function, though it lacks context on undo stack 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?

There are zero parameters and full schema coverage, so the description does not need to add parameter information. Baseline score of 4 for no 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?

The description clearly states the verb 'Undo' and the resource 'the last action in the connected score application', distinguishing it from sibling tools which focus on connecting or adding elements.

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 for undoing the last action but offers no explicit guidance on when to use it versus alternatives, nor any exclusions or prerequisites.

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