Music Studio

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

Annotations already declare readOnlyHint and idempotentHint, so the description adds detail on what content is returned (e.g., instrument lists, patterns, templates). 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?

The description is a single, efficient paragraph that front-loads the core purpose and uses parentheticals for details. Could be more structured (e.g., bullet list) but remains clear and not verbose.

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

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

For a reference tool with a single enum parameter and safe annotations, the description covers all topics comprehensively. No output schema is needed as the return type is implied.

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%, and the description enriches each enum topic with specific examples (e.g., 'instruments (GM instrument list + combos)'), going beyond the schema's basic description.

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

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

The description clearly states it returns detailed reference material for music composition and enumerates all sub-topics, distinguishing it from sibling tools like get-strudel-guide (different domain) and playback 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 enum parameter description provides valuable guidance on where to start ('Start with 'genres'...'), but does not explicitly state when to use this tool over its siblings like play-live-pattern or search-music-docs.

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

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

Annotations already indicate read-only and idempotent behavior. The description adds no further behavioral context beyond confirming it is reference material. 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?

Description is a single, dense paragraph that efficiently lists all topics and subtopics without redundancy. Every sentence earns its place.

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

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

For a simple one-parameter reference tool, the description is thorough. It covers all possible topics with detail. No output schema is needed; the return is likely text, which is obvious.

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 baseline is 3. The description enriches the meaning of each enum value with specific sub-topics, adding value beyond the schema's brief description.

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

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

The description clearly states it's a reference guide for Strudel live coding, listing specific topics. It distinguishes from sibling tools like 'get-music-guide' which likely covers general music theory.

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

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

The description does not explicitly guide when to use this tool over siblings. While the input schema description advises on topic selection, there is no tool-level usage guidance.

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

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

Annotations already indicate read-only and idempotent behavior. The description adds useful behavioral details beyond annotations: it mentions that patterns play in a REPL the user can edit, that autoplay may require a user click due to browser policy, and that visualizations like .pianoroll() can be added. No contradictions with annotations.

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

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

The description is well-structured, starting with the main purpose and then detailing capabilities. It is slightly verbose but packs significant information without redundancy. Every sentence adds value, though minor trimming could improve 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 complexity of live-coding music with multiple instruments and visuals, the description covers key aspects: code editing, playback, visualizations, and tempo control. It lacks explicit mention of return values or side effects beyond the REPL output, but the tool's nature (real-time audio) makes this acceptable.

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

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

Schema coverage is 100%, and the description adds meaning beyond the schema: it explains that bpm converts to setcps(), describes how to layer patterns with stack(), and notes the autoplay browser policy constraint. This provides context not available from the schema alone.

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

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

The description clearly states the tool is for live-coding music patterns using TidalCycles mini-notation, specifying exact actions (live-code, layer, add visuals) and resources (drums, synths, bass, effects). It distinguishes itself from sibling tools like get-music-guide and play-sheet-music by focusing on interactive pattern generation.

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

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

The description provides clear guidance on when to use this tool, e.g., for live-coding patterns, and directs users to get-strudel-guide for templates and advanced features. However, it does not explicitly state when not to use it or contraindications relative to alternatives like play-sheet-music.

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

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

Annotations already indicate readOnly, idempotent, non-destructive. The description adds key context: it does not return raw audio, only renders an inline player with interactive controls. The verb 'compose' could imply creation, but the tool is essentially a renderer; annotations confirm no state changes, so no contradiction.

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

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

Two paragraphs, front-loaded with purpose and key usage. No wasted words; each sentence adds value. Efficiently conveys when to use and what to expect.

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 main aspects: purpose, input (ABC notation), options (style, tempo, instrument), return behavior (parse, render, no raw audio), and reference to get-music-guide. Could mention error handling or limitations of ABC syntax, but overall adequate for a tool with well-documented schema and no required parameters.

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% with detailed descriptions for each parameter. The description text does not add parameter-specific details beyond the schema, so baseline score is appropriate.

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

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

The description clearly states the tool composes and plays sheet music with visual notation, multi-instrument audio, and style presets. It distinguishes from sibling tools by referencing get-music-guide for reference and contrasting with non-ABC 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?

Provides clear guidance on writing ABC notation, using style presets, and understanding return behavior. Suggests get-music-guide for templates and syntax, which helps with proper usage. However, it does not explicitly compare with play-live-pattern or state when not to use this tool.

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

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

Annotations already indicate read-only, non-destructive, open-world. Description adds context: returns code examples and explanations, powered by semantic search. 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 valuable. First explains purpose, second differentiates from siblings, third gives usage context. 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 2 params, no output schema, and annotations covering safety, the description is complete. It states what the tool returns and the domain. Could mention result format or lack of pagination, but not critical.

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% with detailed parameter descriptions including good/bad query examples and enum for library. Description echoes this but doesn't add new semantic info beyond what's in schema.

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

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

Clearly states the tool searches documentation for Strudel live coding and ABC/ABCJS notation, focusing on code examples and explanations. Differentiates itself from sibling tools by positioning itself as a fallback when curated guides don't suffice.

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 tells when to use this tool (when curated guides don't cover, for specific functions, advanced techniques, unsure syntax). Names alternatives (get-strudel-guide, get-music-guide). Lacks explicit 'do not use' scenarios, but implied by contrast.

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