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

With no annotations, the description carries the full burden and does well: it discloses the mutation side effect of task=jam (merges into the current pattern then auto-plays), that suggest output is not auto-executed, that audio analysis is opt-in via includeAudio, and that all three modes share Gemini auth plus rate limiting. It stops short of covering failure behavior and how a jam merge interacts with existing layers of the same type, which matters for a tool that mutates state.

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

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

The content is front-loaded and dense: capability, then per-task behavior, then auth, then alternatives. Minor waste in the trailing issue references (#252) and the inline example, but nothing is buried and no sentence restates the tool name.

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

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

For an 8-parameter, three-mode tool with no annotations and no output schema, the description covers purpose, mode semantics, auth prerequisites, side effects, and alternatives — enough to invoke it correctly. The remaining gap is return-value shape for feedback/suggest (what 'creative critique' or 'pattern as text' concretely contains), which has no output schema to fall back on.

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% and every parameter already documents its task binding and defaults, so the schema does the heavy lifting. The description reinforces the task-to-behavior mapping and adds one concrete call example, but supplies no syntax or format detail beyond what the schema already states.

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

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

The description names a specific capability (Gemini-backed pattern assistance) and decomposes it into three clearly distinguished modes: feedback returns critique, suggest returns a suggested Strudel pattern as text, jam generates and merges a layer then auto-plays. It also explicitly separates itself from siblings generate_part (non-AI generation) and compose (full compositions), so an agent can route correctly without opening any schema.

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

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

Each task variant is given an explicit use condition, including the scope of what it produces and whether it is auto-executed. The closing sentence names two alternative tools and the situations that select them (non-AI generation, full compositions), which is exactly the when-to-use/when-not guidance needed.

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?

Describes return structures for each include option, explains combining behavior, and mentions pre-consolidation behavior for 'all'. Lacks explicit read-only statement but overall 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?

Description is comprehensive but slightly lengthy; each sentence adds value and structure is clear. Could be more concise but still effective.

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?

No output schema, but description explains return values for each category. Covers main use cases and alternatives. Missing error handling but sufficient for most scenarios.

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

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

Schema coverage is 100% (baseline 3). Description adds meaning with explanations of enum values, default behavior, and examples of combining categories.

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

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

Description clearly states 'Audio analysis on the currently-playing pattern' with specific analysis categories (tempo, key, spectrum, rhythm, all). Distinguishes from siblings analyze_pattern_local and validate_pattern_runtime.

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 provides when to use each include value, demonstrates with examples, and names alternatives: 'For static pattern analysis (no browser) use analyze_pattern_local; for runtime validation use validate_pattern_runtime.'

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 description must disclose behavior fully. It only states static analysis without browser playback, but omits whether it is read-only, output format, or any side effects. Insufficient for a tool with zero annotation coverage.

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

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

Single sentence efficiently communicates the core purpose and key differentiator (no browser playback). 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?

With one parameter and no output schema, the description is minimal but covers the basics. However, it does not explain what the analysis returns or provide usage context (e.g., costs, limitations), leaving gaps for a full understanding.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds context about the analysis type but no additional meaning for the 'pattern' parameter beyond the schema. Adequate but not improved.

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 specifies static analysis of events/cycle, complexity, and optional BPM, and explicitly excludes browser playback. This makes the purpose clear, though it does not explicitly state it is for patterns (implied by parameter 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 explicit guidance on when to use this tool vs alternatives like 'analyze' or 'validate_pattern_local'. The mention of 'without browser playback' hints at a scenario but does not name sibling tools or provide criteria.

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

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

With no annotations, the description itself discloses the streaming start/stop lifecycle, base64 output on stop, fixed-window sampling, the playback prerequisite, and per-session recorder isolation. This is strong operational context, although raw base64 versus a data URI and behavior for invalid recorder states are not specified.

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

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

The description is front-loaded and dense with usable operational detail, including a compact example. Repeated defaults and ranges already present in the schema, plus internal issue markers such as (#180), add slight noise.

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?

Together with the fully described schema, it covers the three invocation modes, output encoding, preconditions, limits and defaults, and concurrent-session behavior sufficiently for most calls. The base64 statement partly compensates for the absent output schema, but export_audio selection guidance and recorder-state or error behavior remain uncovered.

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 100%, the action schema only says "Capture action"; the description adds the meaningful start/stop/sample workflow and a concrete sample invocation. Much of the format, duration, and session detail repeats the schema, and maxDuration is left entirely to the schema, so this is above baseline rather than exhaustive.

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

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

The opening sentence gives a specific verb, resource, and live-session scope, while the action breakdown makes the tool's role clear. It distinguishes the tool from export_midi and diagnostics but not from export_audio, the closest sibling for audio-related selection.

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 gives concrete guidance for start, stop, and sample, states that audio must be playing, and routes MIDI export and runtime diagnostics to named alternatives. It does not explain when live capture is preferable to export_audio, leaving the most likely sibling-selection ambiguity unresolved.

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, but description discloses that 'show brings window to foreground' and 'screenshot captures editor view to disk.' It also explains session_id behavior regarding compose auto-init. Minor omission: no mention of error states or file overwrite 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?

Concise, four sentences: purpose, two actions with brief explanation, example, and cross-reference to siblings. No fluff.

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

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

Given no output schema and three parameters with one required, description covers main use cases. Includes example and alternatives. Could mention what happens on failure (e.g., screenshot to existing file) but overall 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?

Input schema has 100% coverage of parameters with descriptions. The description adds minimal value beyond schema with an example for filename, but no additional semantic explanation for action or session_id that isn't already 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?

Description clearly states it interacts with the Strudel browser window and lists two specific actions (show, screenshot). It distinguishes from sibling tools by referencing diagnostics and edit_pattern.

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 explicit alternatives: 'For diagnostics use diagnostics; for the editor itself use edit_pattern.' Also includes an example and clarifies when to use session_id.

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

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

There are no annotations, so the description carries the full disclosure burden. It does reveal two side effects: playback is triggered and a default browser is auto-initialized if needed. It does not say whether an existing pattern is overwritten, whether audio output requires a browser session, or how slow or expensive the composite operation is, so a mutation/playback tool remains under-disclosed.

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

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

Two short sentences, front-loaded with the core action and followed by the one non-obvious side effect. No filler and nothing restated from 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?

With six parameters, no annotations, and no output schema, the description should say more about what a successful call returns (pattern handle/session id, feedback payload when get_feedback is true) and what state it mutates. As it stands, an agent can pick the tool but cannot predict its results or side effects beyond browser init.

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% (style genres, key default, tempo default, auto_play, session_id, get_feedback), so the schema already handles parameter meaning. The description adds nothing about any parameter and doesn't explain the interplay between auto_play and get_feedback. The baseline score of 3 is appropriate.

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

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

The description uses concrete verbs (generate, write, play) on a specific resource (a complete pattern) and highlights the composite 'in one step' nature, which distinguishes it from the granular siblings (generate_part, init, playback, edit_pattern). It stops short of naming which siblings it replaces, but the action is unambiguous.

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

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

'In one step' only implies that this tool is the shortcut alternative to initializing, generating, and playing separately; neither a when-to-use condition nor an excluded case is stated. The important precondition — that auto-init applies only to the default session and named sessions must already exist — appears in the schema's session_id description, not in the description itself.

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 supplied, the description carries the full burden and does well: it discloses a <15ms SLA for status, that config.json provenance and warnings are surfaced, and that session_id is ignored for perf/memory because those are server-wide metrics. It stops short of stating that the tool is read-only and side-effect free, which has to be inferred from "Inspect".

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?

Front-loaded with the verb and the cheapest level first, then the heavier surfaces, then the redirects, then the example. Dense but nearly every clause carries information; the level enumeration is long but functional. Minor redundancy between the opening scope statement and the per-level list.

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

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

For a two-param, no-output-schema tool, the description adequately fills the return-value gap by naming what each level yields (snapshots, caches, errors, timing metrics, memory). Return shapes remain coarse, but that is acceptable for a diagnostics surface where the caller inspects the payload anyway.

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 already 100%, so the baseline is 3, but the description adds real meaning beyond the enum by explaining what each level actually returns and by scoping session_id's applicability (status/full/errors) versus perf/memory. That is semantic information the schema's terse "Which diagnostic surface to read" does not provide.

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

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

The description opens with a specific verb+resource pair ("Inspect server and browser state") and then enumerates all five level values with what each one returns, so an agent can distinguish this from siblings like session or browser_window without opening the schema. The scope (server-side vs browser-side surfaces) is made explicit per level.

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 default (level=full preserves pre-consolidation behaviour) and gives an explicit example call for the cheap path, plus routes two adjacent needs elsewhere ("For screenshots use browser_window; for tool listings use the strudel://docs/tools resource"). It does not contrast against diagnostic-adjacent siblings like session or history, so the routing is useful but not exhaustive.

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 well: it discloses that the default mode replaces editor contents entirely, that write mirrors the old write tool including validation and auto_play, that replace touches only the first occurrence unless replace_all, that the response reports matched/replaced/remaining counts, and that clear wipes the editor. What is missing is whether mutations are undoable/recoverable via history and whether a session must exist first, so it falls short of 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?

Front-loaded with the core purpose, then one sentence per mode, then alternatives and an example. Every sentence maps to a distinct behavior, though the mode enumeration partially duplicates the enum documentation in the schema and 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 10-parameter, five-mode mutation tool with no output schema, the description covers mode behavior, defaults, the shape of the response counts, and routing to sibling tools. The remaining gap is side-effect and recoverability context (does an overwrite lose prior work, is there an undo path through history), which matters for a destructive-capable 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 coverage is 100% and each parameter already carries a mode-scoped description, so the baseline is 3. The description adds cross-parameter meaning the schema cannot express — which parameter pairs are active for which mode — plus a concrete example call combining mode, pattern, and auto_play, which is real added value but largely restates mode semantics.

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

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

States a specific verb and resource ("Mutate the current session pattern") and then enumerates all five modes, each with its precise effect. It explicitly differentiates itself from siblings get_pattern (read) and pattern_store (on-disk catalog), so an agent can tell exactly which tool owns editor mutation.

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?

Gives per-mode conditions of use (write replaces, append concatenates with newline, insert at position, replace uses search/replace, clear empties) and names the alternatives plus the condition that selects them: get_pattern when reading without mutating, pattern_store for the disk catalog. Nothing about tool selection is left to inference.

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

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

With no annotations, the description usefully discloses that adding appends syntax to the session pattern and that removal is potentially broad, stripping every matching effect call rather than only the last. It does not explain error handling, removal of a nonexistent effect, or whether changes affect playback immediately.

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

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

The description is compact and front-loaded with purpose, followed by exact mutation semantics, an important removal warning, an example, and sibling routing. Every sentence contributes practical selection or invocation information without 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 simple four-parameter session-pattern mutation, this supplies nearly everything needed to select and invoke the tool correctly, with the schema covering the remaining session parameter. The main omissions are result feedback and edge-case behavior, which matter somewhat more because there is no output schema.

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 already 100%, and the description adds meaningful semantics by showing how action, effect, and params combine into `.<effect>(<params>)`. The lpf example makes the expected string parameters concrete, while session_id remains adequately documented by 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 opening sentence gives specific actions, resource, and scope: adding or removing a Strudel effect on the current session pattern. The final sentence also distinguishes it from shape for effect bundles and transform for raw transforms.

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 explains how action=add and action=remove differ and provides a concrete add invocation. Explicit routing to shape for mood/energy/refine bundles and transform for raw transforms gives clear sibling-selection 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 carries the full burden and does well: it discloses the return shape (a path plus capture metadata, not inline bytes), the failure mode ('Reports silent captures instead of writing a silent file and claiming success'), and the required precondition of active playback. It does not discuss overwrite behavior, export directory location, or duration limits, 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?

Front-loaded with purpose, then alternative routing, then format semantics, then precondition, then an example — a sensible order. A few phrases are stylistically loose ('not a wall of base64', 'claiming success') but they carry behavioral information rather than padding.

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 five-parameter, zero-required capture tool with no output schema, the description covers return values, format tradeoffs, the silent-capture edge case, and the playback precondition. Remaining gaps — where files land, overwrite behavior, and session routing — are either minor or already handled by the schema's parameter descriptions.

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, but the description adds real meaning beyond the schema: 'format=wav (default) decodes to 16-bit PCM a DAW will open; format=webm writes the raw Opus recording' explains the consequence of each enum value rather than restating it. It also demonstrates filename usage in the example call, though it says nothing extra about output=base64 or session_id 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?

States a concrete verb and resource — 'Record a window of live Strudel audio and write it to a file' — and immediately differentiates itself from the sibling audio_capture by saying it is preferred 'when you want the audio to exist somewhere.' An agent can pick between the two without opening either schema.

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

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

Gives an explicit alternative ('prefer this over audio_capture') with the condition that selects it, plus a hard prerequisite: 'Audio must already be playing: call playback({ action: "play" }) first.' That is when-to-use, when-to-use-something-else, and ordering guidance in two sentences.

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 supplied, so the description carries the full burden. It does disclose that only note(), n(), and chord() calls are parsed, which is a real behavioral constraint (other event types may not be exported), but it omits failure behavior with no loaded pattern, where a 'file' output is written, and how sessions affect the capture despite a session_id parameter.

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

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

Two short sentences with the action front-loaded and no filler. Every clause carries information; nothing needs trimming.

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 export tool with a fully documented schema this is close to adequate, but with no annotations and no output schema the description should at least say what 'current pattern' means when multiple sessions exist and what a 'file' export produces. As written it leaves those operational questions unanswered.

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% with five documented parameters, so the schema already explains bpm defaults, the file/base64 enum, duration in bars, filename, and session routing. The description adds nothing about any parameter, so baseline 3 applies — not the zero-parameter baseline of 4, since five parameters exist.

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

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

States a specific verb+resource ('Export current pattern to MIDI file') and adds what it parses (note(), n(), chord()), which tells an agent what content is captured. It never names or distinguishes itself from the closest siblings (import_midi, export_audio), so sibling differentiation is left to inference.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no mention of the obvious alternatives (import_midi for the reverse direction, export_audio for non-MIDI output). Usage is only implied by the 'current pattern' scoping phrase.

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

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

Description discloses mutation ('append it to the current session pattern') but lacks details on reversibility, error handling, or session management beyond session_id. No annotations provided to offset; would benefit from noting side effects more fully.

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 well-structured with role-specific paragraphs, an example, and a final line for sibling differentiation. Every sentence is informative, no fluff.

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

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

Covers all roles, defaults, and examples. Lacks return value description (no output schema), which would aid agent understanding of what to expect. Otherwise thorough for a generative 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 coverage is 100%, baseline 3. Description adds conditional per-role parameter usage (e.g., role=drums takes style, complexity; role=melody takes root/scale), which significantly aids parameter selection beyond schema's flat listing.

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 uses specific verb 'Generate' and distinct resource 'single instrumental layer' appended to session pattern. It clearly differentiates from siblings by naming alternatives (compose, generate_rhythm, 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?

Explicitly states when to use this tool vs alternatives: 'For full compositions use compose; for rhythmic patterns use generate_rhythm; for music-theory queries use music_theory.' Also provides an example call.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the two modes and that the pattern is appended (state mutation). However, it does not detail side effects (e.g., overwriting, error handling) or prerequisites like session existence. This is adequate but not thorough.

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 (4 sentences) and well-structured: purpose first, then type explanations with example, then sibling alternatives. Every sentence adds value 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 tool with 7 parameters and mutation behavior, the description covers types, parameters, and alternatives. However, it lacks details on return value or error conditions. With no output schema, a note on what the tool returns would improve completeness.

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

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

Schema description coverage is 100%, baseline 3. The description adds meaning by linking parameters to types (e.g., 'hits evenly distributed across steps') and stating defaults (sound default 'bd'). This enriches understanding 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 generates a rhythmic pattern and appends it to the current session. It specifies two types (euclidean, polyrhythm) and distinguishes itself from generate_part and compose, making the purpose unambiguous and differentiating it from siblings.

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

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

Explicit guidance is provided: use generate_part for complete patterns and compose for whole compositions. The example demonstrates correct invocation, and the parameter descriptions clarify when each type applies.

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 any behavioral traits. It does not state whether the operation is read-only, has side effects, or requires specific permissions.

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

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

The description is extremely concise but at the cost of missing important context. It is not verbose, but it does not add value beyond the bare minimum.

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 lack of output schema and the presence of many sibling tools, the description fails to provide enough context to understand what 'pattern code' is, what the tool returns, or how it relates to other pattern tools.

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% with a clear description for the session_id parameter. The description adds no further value beyond the schema, but the schema itself is adequate, so the baseline score of 3 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 the tool gets the current pattern code, identifying the verb and resource. However, 'pattern code' is somewhat vague without further context, and the description does not differentiate from similar sibling tools like 'query_pattern_events' or 'analyze_pattern'.

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 context, prerequisites, or exclusion criteria, leaving the agent to guess.

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 discloses key behaviors: undo reverts, redo replays, restore pushes current onto undo stack, compare diffs with defaults. It lacks details on side effects (e.g., idempotency) but covers the main behavioral traits.

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

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

The description is two short paragraphs, front-loaded with the purpose and actions, followed by an example and sibling distinction. Every sentence is informative, with no redundancy.

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

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

Given six parameters and no output schema or annotations, the description covers all actions, parameters, defaults, and an example. It omits error scenarios but is otherwise sufficient for an agent to use the tool correctly.

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

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

Schema coverage is 100%, but the description adds context beyond schema: it explains default limit (10), default id2 (current pattern), and the undo-stack effect of restore. This additional behavioral information enhances parameter meaning.

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 tool navigates or inspects the pattern edit history, listing all five actions with clear verb-resource pairs. It explicitly contrasts with sibling tool pattern_store (in-memory vs on-disk), fully distinguishing its purpose.

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

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

The description explains when to use each action and provides an example. It explicitly directs users to pattern_store for on-disk patterns, though it does not cover all sibling tools or edge cases.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses the Phase 1 literal-transcription scope, channel-10 drum lane splitting, note("...").s("piano") emission for pitched tracks, chord-token merging, and that path traversal is blocked. What it omits is the shape of the return value (the schema mentions a 'result summary' but the description never says what is returned on 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?

Front-loaded with the core purpose, then modes, then emission semantics, then the alternative tool — a sensible ordering. The Phase 2+ roadmap sentence and the '#201' issue reference are internal noise that an agent gains nothing from, though they cost only one sentence.

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 converter with five parameters (including a nested drum_map) and no output schema, the description covers the important behavioral questions: how drums vs pitched tracks are rendered and what limits path input. The remaining gap is the return contract — whether the tool returns a pattern string, an object, or a summary with unmapped drums — which the agent must discover empirically.

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 genuine meaning by tying source values to concrete data semantics ('data=<base64 string>' vs 'data=<basename>') and by showing steps_per_cycle in a realistic call. The drum_map override and bars cap are left entirely to the schema, which is acceptable given full 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?

States a specific verb and resource ('Convert a .mid file into a playable Strudel pattern') and immediately distinguishes itself from the sibling export_midi by naming the reverse-direction tool. An agent can tell what this does and what it does not do without opening the schema.

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

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

Gives explicit conditional guidance for the two source modes (base64 for inline bytes, path for files under patterns/midi/) and names the alternative tool for the opposite direction. The inline example with source="path" anchors the intended invocation pattern.

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 side effects, required permissions, or state changes. 'Initialize' implies setup but lacks specifics.

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

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

The description is a single, concise sentence that is front-loaded. It avoids verbosity, but could benefit from a bit more context without sacrificing 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 no parameters, the description is minimally complete. However, the absence of output schema and annotations means the agent gains little insight into what initialization entails, which is a gap for a potentially impactful action.

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, so schema coverage is 100%. The description adds no parameter information but is not required to; baseline of 4 is appropriate.

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

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

The description clearly states the verb 'Initialize' and the resource 'Strudel', indicating it sets up the Strudel environment. However, it does not differentiate from sibling tools like 'session' or 'browser_window' which might have overlapping 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?

No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites or typical usage 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?

With no annotations, the description carries full burden. It discloses that chord_progression writes into the current session (side effect) and explains the output format for scale queries. However, it does not detail the chord progression output format or any error conditions.

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 (4 sentences) and front-loaded with the core purpose. Each sentence adds distinct value, including an example and sibling tool references.

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 6 parameters, no output schema, and a moderate complexity domain, the description is fairly complete. It covers both query types, inputs, side effects, and alternatives. Missing the exact output format for chord_progression prevents a 5.

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% but description adds value: it explains that root also serves as key for chord_progression, gives an example usage, and illustrates the scale output format. This goes beyond the schema's parameter 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 clearly states the tool is for music-theory queries, detailing two query types (scale and chord_progression) with specific outputs. It distinguishes from sibling tools (generate_part, generate_rhythm) by explicitly stating their use cases.

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 explicit guidance on when to use alternatives: 'For pattern generation (drums/bass/melody) use generate_part; for rhythmic patterns use generate_rhythm.' It also includes a concrete example.

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 behavioral burden. It discloses that load mutates the current session and that the catalog is on-disk, but it omits the riskiest trait — the overwrite/collision behavior and irreversibility — which appears only in the schema's overwrite field rather than in the description. It also says nothing about return content or error behavior, so the safety profile is only partially surfaced.

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?

Front-loaded with purpose, then actions, then an example, then a sibling redirect — a sensible information hierarchy with no filler sentences. The example is slightly redundant with the enumerated actions, but it earns its place by showing the argument shape.

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?

No output schema exists, so the description ideally would say what save/load/list return (e.g., catalog entry shape), and it does not. Otherwise it is sufficiently complete for a 6-parameter persistence tool: operation semantics, tag filtering, and tool boundaries are all covered.

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, but the description adds meaning beyond the field docs by explaining how each action value interacts with session state (save reads the current session pattern; load replaces it) and by clarifying the tag filter only applies to list. The collision/overwrite semantics and session_id scoping are left entirely to 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?

Opens with a specific verb pair and resource: "Persist patterns to disk and read them back," then enumerates the three operations (save/load/list) with what each does. It also explicitly scopes itself as the on-disk tool versus the runtime 'session' sibling, so an agent can separate it from the rest of the list without opening schemas.

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

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

States the selection rule for each action (save = write current session pattern under a name; load = restore a named pattern; list = enumerate catalog, optionally tag-filtered) and gives a concrete call example. It also names the alternative tool and the condition that selects it: session lifecycle goes to the session tool, not here.

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

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

No annotations are provided, so the description carries the behavioral burden. It usefully discloses that pause halts the clock and play resumes mid-cycle, which is meaningful state behavior beyond the schema, though it omits whether stop resets position and what happens on errors.

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

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

The description is front-loaded with the core purpose, then explains action semantics and sibling routing. The example is short and the text contains no filler.

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

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

For a two-parameter transport tool with no output schema and no annotations, the core behavior and alternatives are adequately covered. Additional detail on session selection and stop/reset behavior would make it fully self-contained.

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 value by explaining what play, pause, and stop actually do, going beyond the schema's brief 'Transport action' enum 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 names a specific verb and resource: 'Control transport on the current session.' It also defines each enum action and distinguishes playback from edit_pattern and set_tempo, so an agent can identify its role without opening the schema.

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

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

It gives concrete routing guidance: use edit_pattern for pattern editing and set_tempo for tempo. The required action parameter makes invocation clear, but it does not fully explain when to supply session_id or when playback should not be used.

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 discloses the max cycle range (16 cycles) and the action (enumerate events), but omits behavioral details such as whether the tool is read-only, side effects, or error handling. Some transparency is present but incomplete.

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 filler. Every word contributes to understanding the tool's purpose and constraints.

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 and low complexity (3 params), the description adequately covers the core functionality. It states the action, range constraint, and max cycles. However, it could mention prerequisites (e.g., pattern existence) or return format.

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

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

Input schema has 100% description coverage, so the schema already defines parameters. The description adds no extra semantic context beyond the schema's descriptions. 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 uses the specific verb 'enumerate' and clearly states the resource ('events') and scope ('between two cycle indices, max 16 cycles'). It differentiates from siblings like 'get_pattern' by focusing on emitted events rather than the pattern itself.

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

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

The description does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention scenarios where it should not be used. The usage context is implied only through the tool's name and description.

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

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

With no annotations, the description discloses key behaviors: sessions share a browser but have isolated contexts, destroy releases resources, switch changes routing for subsequent calls. However, it omits potential error conditions (e.g., invalid session_id).

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 efficiently structured, starting with a clear one-line summary, then breaking down each action in bullet-like format, and ending with a contrast to a sibling tool. 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?

Despite lacking annotations and output schema, the description covers all actions, explains the shared-browser-but-isolated-context behavior, and distinguishes from a sibling tool. It provides an example and sufficient detail for an agent to use the tool correctly.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds context for each action value but does not significantly extend the schema's semantic detail beyond the provided enum and parameter 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 clearly identifies the tool as managing isolated browser sessions, explicitly differentiates from the sibling pattern_store by contrasting runtime sessions vs. on-disk patterns, and uses specific verb-resource pairs for each action (e.g., 'starts a new named session').

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 explicit guidance for each action (create, destroy, list, switch) and directly advises when to use the sibling pattern_store instead, establishing clear usage boundaries.

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 does disclose one genuinely non-obvious behavior: the tool writes setcpm(bpm/4), assuming a bar of 4/4 per cycle. That conversion is invisible from the schema and valuable. However, it omits whether the change is global or session-scoped, whether it persists, and whether it affects currently playing audio, which are important for a mutation tool.

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

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

Two short sentences, front-loaded with the primary action, zero filler. Every clause carries information the caller could not get from structured fields.

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

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

For a mutation tool with no annotations and no output schema, the description is on the thin side. It explains the internal mapping but not the scope of effect, persistence, or whether the caller must supply session_id to target a specific session.

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 exceeds that by explaining the underlying transformation of the bpm value (bpm/4 into setcpm), giving the parameter meaning beyond 'Tempo in BPM.' The optional session_id is left to 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 and resource: 'Set BPM.' An agent immediately knows this changes the tempo. It doesn't differentiate itself from siblings like playback or compose, but 'Set BPM' is unambiguous enough that confusion is unlikely.

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

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

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of when not to use it. The session_id parameter's behavior (default session fallback) is documented only in the schema, not the description.

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

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

No annotations are provided, so the description carries the full burden. It discloses that all dimensions auto-play by default and mentions optional intensity with a default of 0.5. However, it does not explicitly state whether the shape operation is non-destructive or what the return value is, leaving some 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 a single paragraph that front-loads the main action and then details each dimension. All sentences are informative, but it could be slightly more concise by grouping the dimension descriptions more tightly. Still, it is well-structured and avoids 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?

Given the tool has 7 parameters and no output schema, the description covers the core functionality well, including usage context and sibling differentiation. However, it lacks details on the return value or confirmation of success/failure, which would be helpful for an agent to fully understand the tool's effect.

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 all parameters described. The description adds significant value beyond the schema by explaining the meaning of each dimension, providing the example with target_mood and intensity, clarifying default values (intensity 0.5, auto_play true), and listing valid options for each dimension. This greatly aids parameter selection.

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: 'Shape the current pattern along one of three high-level dimensions.' It lists the three dimensions (mood, energy, refine) with specific examples and distinguishes itself from sibling tools by explicitly directing users to 'transform' for raw transforms and 'effect' for explicit effects.

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 explicit guidance on when to use each dimension (mood, energy, refine) with their respective parameters. It also tells users when not to use this tool, directing them to 'transform' for raw operations and 'effect' for effects. An example usage is included, making the expected call pattern 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?

Describes behavioral traits for each op, including side effects like appending '.rev' for reverse and mutating the session pattern. No annotations provided, so description carries burden well, though it could mention whether changes are reversible.

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

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

The description is a single paragraph but is well-organized and front-loaded with the purpose. It efficiently covers all ops without excessive length. Could be slightly more structured with bullets, but still 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?

Given the complexity (9 parameters, 8 ops) and absence of output schema, the description covers all necessary details, including an example and differentiation from siblings. No gaps identified.

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 descriptions, but the description adds significant meaning by explaining each op's effect and parameter usage. Includes an example for transpose, which goes beyond schema bare 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 clearly states it applies a single transform operation to the current session pattern. It lists all eight ops and their effects, and differentiates from sibling tools like effect, shape, and set_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?

Explicitly tells when to use this tool vs alternatives: 'For effects (add/remove) use effect; for mood/energy/refine use shape; for tempo use set_tempo.' Provides clear context and exclusions.

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

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

No annotations are provided, so the description carries the full burden. It only mentions it returns transpiled code or a syntax error, but does not disclose side effects, safety (read-only or destructive), or any behavioral traits beyond the basic purpose. The agent is left uninformed about whether this modifies state or has prerequisites.

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

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

The description is a single sentence that efficiently states the action, engine, and result. No unnecessary words; every part 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 single-param read tool, the description covers the basic purpose, but without annotations or output schema, it lacks detail on return value format and precise behavior. It is minimally adequate but could benefit from explaining what 'transpiled code' looks like or when errors occur.

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 100% coverage with a description for the single 'pattern' parameter: 'Pattern code to transpile'. The description does not add further meaning beyond what the schema already provides (e.g., format, constraints, examples). Baseline 3 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 verb 'transpile', the resource 'pattern source via StrudelEngine', and the outcome ('returns transpiled code or syntax error'). This distinguishes it from sibling tools like 'validate_pattern_local' or 'analyze_pattern_local', though it could be more specific about what transpilation entails.

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. No when-to-use, when-not-to-use, or comparison with siblings is given.

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 supplied, the description carries the full behavioral burden. It usefully discloses the execution model (sandboxed child process, no browser), but says nothing about what happens on invalid syntax, whether errors are thrown or returned, side effects, or resource/timeout limits for the spawned process.

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

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

A single front-loaded sentence with no filler; the core action comes first and the environment qualifier follows. It is terse to the point of leaving gaps, but no sentence is wasted.

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

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

For a one-parameter validation tool with no output schema, the description should at least indicate the shape of a validation result (error list, boolean, line/column info). It instead covers only the execution environment, leaving the agent to discover return semantics by calling it.

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

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

There is a single required parameter with 100% schema description coverage ('Pattern code to validate'), so the schema already does the work. The description adds only the word 'syntax,' which slightly narrows the meaning but provides no format or example detail.

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

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

States a specific verb and resource ('Validate pattern syntax') plus the execution target ('local StrudelEngine'), which implicitly separates it from the sibling validate_pattern_runtime. It does not name that sibling outright, so the differentiation is inferential rather than explicit.

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

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

The parenthetical 'no browser required' hints at when this is preferred (headless/local contexts), but there is no explicit when-to-use, when-not-to-use, or named alternative such as validate_pattern_runtime. The agent must infer the routing decision from the environment note.

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?

Discloses that it monitors the Strudel console for errors, but does not mention side effects of executing the pattern or any required permissions.

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

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

Efficient single sentence with no waste.

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

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

Lacks details about return format, error behavior, and potential for pattern execution side effects; adequate but not 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%, description adds no additional meaning to parameters beyond schema definitions.

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 validates a pattern with runtime error checking, distinguishing it from siblings like validate_pattern_local (static) and analyze (general).

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 vs alternatives like validate_pattern_local; usage implied but not stated.

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