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

No annotations are supplied, so the description carries the full burden. 'Show' implies a non-mutating read and there are no parameters, so risk is minimal, but it never explicitly states side-effect freedom or anything about the freshness/latency of the reported state. It does add value by enumerating the returned content in place of a missing output schema.

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 that lists what is retrieved with no filler or redundancy. Every clause 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?

With zero parameters and no output schema, the description does the necessary work by naming the returned fields (program, blocks, page count, address). It is close to complete; only the absence of explicit read-only confirmation and any sibling disambiguation keeps it short of full.

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

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

The input schema is an empty object with zero parameters, so there is nothing for the description to clarify. Baseline for a no-parameter tool is 4.

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

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

The description gives a specific verb ('Show') and names concrete resources: the Strudel program, its blocks, page count, and address. It clearly reads as a read/query tool, though it never distinguishes itself from the sibling 'tidal_get_state', which an agent could easily confuse it with.

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 statement of when to use this tool versus alternatives, nor any prerequisites. With a sibling literally named 'tidal_get_state', the omission of any routing guidance is a real gap, leaving the agent to infer the choice from the tool name alone.

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 it does disclose the key mutation: it stops playback and clears blocks (a destructive global effect). However, it says nothing about reversibility, whether other state (tempo, layers) survives, or permissions, leaving gaps a mutation tool would ideally fill.

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 that states the effect and scope with zero filler or redundancy.

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

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

For a zero-parameter, no-output-schema tool, the description communicates what happens (global stop plus block clearing) sufficiently to invoke it. It stops short of noting state persistence or side effects on other Strudel subsystems.

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 takes zero parameters, so there are no parameter semantics to document; the baseline for a no-parameter tool 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 a specific verb pair (stop, clear) and names the resource (Strudel and its blocks), clearly scoping a global stop rather than a single-block edit. It does not explicitly name siblings like strudel_remove_block, so differentiation is implied by 'everything' rather than stated.

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?

Usage is only implied: 'stop everything' suggests a global halt, contrasted against the sibling tidal_hush or per-block tools, but no explicit when-to-use/when-not guidance or alternative routing 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, the description carries the full burden. It usefully discloses a key side effect ('Removing the last one hushes Strudel'), which an agent could not infer from the schema. However, it omits error behavior (unknown name), reversibility, and any permission requirements.

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 most important behavioral caveat. 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?

For a one-parameter removal tool with no annotations and no output schema, the description is close to adequate but leaves gaps: what happens when the named block does not exist, and how the hush side effect interacts with other state.

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

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

Schema description coverage is 0%, so the description must compensate. It implies the single 'name' parameter identifies the block to remove, adding marginal meaning, but gives no format, naming convention, or matching semantics (e.g., whether it must match a block set earlier).

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 ('Remove') and resource ('named block from the Strudel program'), which clearly positions it as the counterpart to strudel_set_block. It does not explicitly name a sibling to differentiate from, but the purpose 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?

No guidance on when to use this versus alternatives like strudel_hush (which silences everything) or strudel_set_block. The note about removing the last block hushing Strudel is a side-effect fact, not a when-to-use condition.

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 atomic failure behavior ('if Strudel rejects the code... nothing changes'), the environment prerequisite (needs TIDAL_UI_PORT), and that effects apply to all open pages. It omits success/return behavior and any concurrency or rate-limit notes, keeping it 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?

Purpose is front-loaded in the first clause, and each sentence adds distinct information (scope, block format, interaction, failure mode). The inline example is somewhat bulky but earns its place by demonstrating syntax.

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 mutation tool with no annotations and no output schema, the description covers purpose, format, prerequisite, side effects, and failure behavior. It is nearly complete, lacking only detail on the success/return signal.

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 concrete example patterns (s("bd*2 [~ sd]").bank("RolandTR909")) that illustrate valid `code` syntax and reinforce the replace-on-name-reuse semantics for `name`. This extra illustrative value lifts it above the schema-only baseline.

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 pair ('Add or replace') and resource ('a named block in the Strudel program'), and clarifies the scope ('plays on every open Strudel page'). An agent can distinguish this from strudel_remove_block or strudel_hush 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?

The description explains the add-vs-replace semantics (reusing a name replaces that block) and that blocks play together, which implies usage. However, it never names the sibling alternatives (strudel_remove_block, strudel_hush, strudel_get_state) or states when to prefer this tool over them, so guidance is inferred rather than explicit.

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 does disclose the underlying mapping (setcpm(bpm/4), four beats per cycle), which is genuinely useful behavioral context beyond the schema, but it says nothing about immediacy, whether it applies to already-running patterns, or how it interacts with block-level settings.

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

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

One sentence, front-loaded with the action and unit, with the technical mapping parenthetically appended. Nothing is wasted and the essential information comes first.

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-parameter setter with full schema coverage and no output schema, the description is minimally adequate. It omits scope of effect (live patterns vs. future ones) and any relationship to the sibling tidal_set_tempo, which an agent selecting between them would want.

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 the bpm range (20–999) is documented in the schema itself. The description adds the semantic conversion to cycles per minute, which is a modest value-add but largely complements rather than replaces schema content, so baseline 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?

States a specific verb (Set) and resource (Strudel's tempo) with the unit (beats per minute), and naming 'Strudel's' distinguishes it from the sibling tidal_set_tempo. It stops short of explicitly contrasting the two tempo tools, but the resource 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?

There is no guidance on when to use this versus tidal_set_tempo or any other sibling, no prerequisites, and no note on whether it affects currently playing patterns. Usage must be inferred entirely from the name.

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

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

With no annotations, the description carries the full burden and does solid work: it discloses the non-obvious background behavior (each layer auto-switches variants on its own random timer, transform layers sometimes lay out), and clarifies the destructive-ish difference between pause ('keep playing') and stop ('hush everything'). It omits permission/auth needs and return shape details, but the core behavioral traits are well conveyed.

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?

Purpose is front-loaded in the first sentence, the mechanism follows, and each action is labeled with a colon in a compact list. It is dense but every clause contributes; minor tightening is possible but nothing 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 tool with no output schema and no annotations, the description covers the mechanic and all four actions, including what status reports ('settings and how many layers are moving'). An agent has enough to call it correctly; only the exact return payload and any permission requirements remain unstated.

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 75%, with the three numeric params already documented in the schema, so the field-level burden is mostly met by structured data. The description earns credit by explaining the required 'action' enum values that the schema leaves undescribed, but it does not clarify the units/ranges of maxSeconds, minSeconds, or layOutChance. 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 opening sentence 'Keep layered channels evolving between turns' gives a specific verb-like behavior and resource (layered channels), and the mechanic is explained precisely. It does not name or contrast against siblings like tidal_status or tidal_hush, so an agent must infer differentiation, but the concept itself 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?

The description defines what each action (start/pause/stop/status) means, which functions as implicit usage guidance for the modes. However, it never states when to reach for this tool versus tidal_hush, tidal_status, or tidal_eval, nor any prerequisites/exclusions, so the routing guidance is only implied.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses destructive semantics, namely that the call replaces everything on the channel including its layers, but says nothing about session prerequisites, error behavior for occupied channels, or what is returned.

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

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

Two sentences, zero filler, and the replacement consequence is front-loaded before the routing pointer to the sibling tool. Every clause 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 two-parameter mutation tool with no output schema and no annotations, the description covers the critical unknown (full replacement of the channel) but omits return/state feedback and any prerequisite about a running Tidal session, leaving a modest gap.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema, including the enum and the 'without d1 $ prefix' note. The description restates the channel range but adds no syntax or format detail beyond the schema, so the baseline 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?

States a specific verb (evaluate) and resource (a TidalCycles pattern on channel d1-d9), plus the scope of the effect. It explicitly names and contrasts with the sibling tidal_set_layer, so an agent can distinguish it 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?

Gives an explicit alternative (tidal_set_layer) and the condition that selects it: when you want to build a channel piece by piece. The implied counterpart, use this tool when you want whole-channel replacement, follows directly.

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. The verb 'Get' implies a read-only operation, and the phrase 'evaluated in this session' adds scoping context. However, it does not disclose the return format, ordering, or explicitly state that no state is modified, which is only minimally adequate for a simple getter.

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

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

The description is a single, front-loaded sentence with no unnecessary words. Every word contributes to understanding the tool's purpose and scope, making it highly efficient.

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

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

This is a simple tool with one optional parameter and no output schema. The description plus schema is sufficient for basic invocation, but the return format of the history is not described, leaving some ambiguity about what an agent should expect in the response.

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%, as the only parameter 'limit' is fully described with its default value and meaning. The description adds no additional parameter information, so the baseline score of 3 applies.

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

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

The description clearly states a specific verb ('Get') and resource ('history of patterns evaluated in this session'). It distinguishes itself from sibling getter tools like tidal_get_state and tidal_get_samples by scoping to session-evaluated patterns, making the purpose unambiguous.

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

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

No guidance is provided on when to use this tool versus alternatives. It does not mention any conditions, exclusions, or sibling tools, so an agent must infer appropriate usage solely from the 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 carries the full burden. It discloses the shape of the return (per-channel patterns plus start times), which is genuinely useful, but says nothing about side effects, whether the call mutates anything, or the logging behavior implied by the schema's 'quiet' flag.

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

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

One sentence, front-loaded with the verb and scope, with the return-content detail appended where it is useful. Nothing 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 read-only state getter with no output schema, the description adequately conveys what comes back, so an agent knows what to expect. It falls short only in not clarifying the boundary with tidal_status or tidal_get_history.

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 optional parameter and schema coverage is 100%, so the schema already fully documents 'quiet'. The description adds no meaning beyond it, which is the baseline-3 case for fully-covered schemas.

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 gives a specific verb+resource ('Get the current state of all channels') and even characterizes the payload ('what patterns are playing and when they started'). It does not, however, differentiate itself from close siblings like tidal_status, tidal_get_history, or strudel_get_state, which is what a 5 would require.

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?

Usage is implied by 'current state' — an agent can infer this is the polling/read tool — but there is no explicit when-to-use guidance, no statement of when not to use it, and no routing to alternatives such as tidal_get_history for past state.

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 clearly discloses the core behavior (stops all currently playing patterns) and the urgency ('immediately'), but it does not explain side effects, reversibility, or what 'clear everything' means for the Tidal state beyond stopping patterns. This is a moderate gap for a mutating 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?

The description consists of two short sentences that are front-loaded with the action. Every word earns its place, and there is no redundant or filler content.

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

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

For a zero-parameter, no-output-schema tool, the description covers the essential action and the intended usage context. It could be more complete by noting whether the stop is reversible or what happens to the pattern definitions afterwards, but for a simple stop-all command it is largely sufficient.

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

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

The input schema has zero parameters, so the baseline 4 applies. There is no parameter meaning to add, and the description correctly avoids referencing nonexistent arguments.

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

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

The description states a specific verb ('Stop'), a specific resource ('all currently playing patterns'), and a timing qualifier ('immediately'). The phrase 'clear everything' reinforces the scope. It does not explicitly distinguish from siblings like tidal_silence, 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?

Gives a direct instruction: 'Use this to clear everything.' This tells an agent when the tool is the right choice. It does not mention when not to use it or name alternatives such as tidal_silence, so falls short of an explicit routing guide.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that unrecognized names are silently ignored ('any other name is silent'), which is real behavioral value beyond structured fields, but it says nothing about the return shape, ordering, or whether the call has any side effects.

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

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

Three short sentences with no filler, and the core action is front-loaded in the first sentence. Slightly more terse than necessary but everything present 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 two-parameter read-only listing tool with no output schema, the description covers what it returns (names usable with s/sound) and when to use it. Only the absence of return-format or refresh-cost detail keeps it from 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 description coverage is 100%, so both the 'filter' and 'refresh' parameters are already fully documented in the schema. The description adds no parameter-level detail (e.g., substring vs. exact match, cost of refresh), so the baseline 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?

States a specific verb (List) and resource (sample banks and synths installed in SuperDirt), plus the scope qualifier 'SuperDirt has installed'. It is clearly separable from the sibling tools, which are all about tempo, layers, hush, or evaluation rather than sample discovery.

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 concrete usage context: 'Use these names with s or sound' and 'Check here before using a sample you aren't sure exists', which tells the agent exactly when to call it. It does not name a competing tool or state exclusions, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden, and it does disclose the return shape at a high level (grouped by layer kind). It does not state that this is a static/read-only reference lookup with no side effects, nor whether results are cached or context-dependent. Adequate, but thin 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?

A single front-loaded sentence with the verb and resource first and no filler. Every clause earns its place by naming the three categories (transforms, sources, controls) and the grouping dimension.

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

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

With no output schema and no annotations, the description should do more to describe what an entry looks like or how the result feeds into sibling tools such as tidal_set_layer or tidal_set_control. The grouping key is mentioned, but the shape and intended downstream use of the returned entries are left implicit.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. No misleading parameter language is present.

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 ("Get") and a clearly named resource (a reference list of Tidal transforms, sources and controls grouped by layer kind). This is distinguishable from siblings like tidal_list_samples or tidal_get_state, which retrieve different resources. It stops short of 5 only because it doesn't contrast itself with any sibling by name.

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

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

The phrase "that combine well" implies the use case (consulting this while building a layer), but there is no explicit when-to-use, when-not-to-use, or named alternative. Usage is inferable from the description rather than stated.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose two useful traits: removal triggers a re-evaluation, and removing the last layer silences the channel. It is silent on the failure mode for a nonexistent layer name, whether removal is reversible/undoable, and any permission requirements.

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, front-loaded sentences with zero waste. The primary action comes first and the consequential side effect (last layer silences the channel) follows as a distinct, earned clause.

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

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

For a simple two-parameter tool with no output schema, the description covers the core operation and its main side effect. However, with no annotations marking this as a destructive mutation, the description should more clearly convey reversibility and the no-op/error case for an unknown layer.

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 two parameters are self-describing (name, channel with d1-d9 enum), so the schema does the heavy lifting and baseline 3 applies. The description adds only 'named layer' and 'channel' framing, no format or matching semantics 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 specific verb+resource: 'Remove a named layer from a channel'. An agent can immediately tell this is the inverse of tidal_set_layer. It does not explicitly name that sibling or distinguish itself from silence-oriented tools like tidal_hush/tidal_silence, so it misses the top tier.

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?

Usage is implied by the operation ('remove a layer') but there is no explicit when-to-use, when-not-to-use, or alternative routing. With siblings like tidal_hush, tidal_silence, and tidal_set_layer, a sentence such as 'use tidal_hush to clear all layers, use tidal_set_layer to modify one' would have closed the gap.

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 it delivers: it explains the control-port mechanism, that patterns are not re-evaluated, and that a number glides over the given seconds for sweeps/fades. It omits failure behavior (e.g., setting an unknown control name) and persistence, but the core behavioral traits are well covered.

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

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

Front-loads the core action in the first clause, then adds mechanism and an example that each earn their place. Slightly dense with two long sentences, but there's 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 3-parameter control setter with no annotations or output schema, the description is largely self-sufficient: mechanism, usage example, and glide behavior are all present. Only edge cases like invalid names or persistence are left unaddressed.

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 schema: the example ties the "name" parameter to the cF/cS lookup ("cutoff") and expands on the "seconds" parameter's glide semantics beyond the schema's brief note.

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 ("Change a named value in Tidal") and clarifies the mechanism (the control port, without re-evaluating a pattern), which distinguishes it from tidal_eval. It doesn't explicitly separate itself from the more specific setters like tidal_set_tempo, but the named-value/control-port scope is clear.

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

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

Gives the concrete workflow: patterns read the value with cF/cS, then you set it here, backed by a runnable example. It establishes when to use this tool clearly, though it stops short of naming explicit alternatives or 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?

With no annotations, the description carries the full burden and does well: it discloses add-or-replace semantics, that each channel has one source and a new one replaces the old, transform ordering ('outermost first'), and the re-evaluation side effect. It omits failure behavior and permissions, but the mutation semantics are unusually well 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?

The core action is front-loaded and no sentence is pure filler; the pattern-grammar sentence and sibling pointers each earn their place. It is dense, but the density is justified by the tool's complexity.

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 5-param mutation tool with no annotations and no output schema, the description covers action, side effects, composition rules, and sibling routing. It leaves the response/return behavior and error cases unstated, which keeps it from the top score.

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: it explains the pattern grammar that code slots into, clarifies transform ordering, and reinforces why variants exist. That is genuine value over the field-level docs.

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

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

The description states a specific verb+resource ('Add or replace one named layer of a channel') plus a concrete side effect ('then re-evaluate that channel'). This clearly separates it from siblings like tidal_remove_layer, tidal_set_control, and tidal_palette.

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 clear guidance on using variants ('Give variants to let tidal_autopilot switch between them') and points to a sibling for valid idioms ('Call tidal_palette for idioms that work'). It stops short of explicit when-not/exclusion rules, so it lands below the top tier.

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 it does disclose the interpretational model (four beats per cycle, setcps (bpm/60/4)). However it says nothing about whether the change applies live to currently playing patterns, persistence, or any session requirements.

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 economical sentence with the core action front-loaded and no filler. The parenthetical formula is arguably dense but earns its place by clarifying units.

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 trivial one-parameter setter with no output schema and no annotations, the description covers the action, unit, and semantics adequately. Only the missing sibling routing context keeps it from being fully complete.

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

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

Schema coverage is 100% and the bpm parameter is already documented in the schema with its 20-999 range. The description adds the beat-cycle interpretation, but that meaning is marginal beyond what the schema provides.

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 ('Set the tempo in beats per minute') and even exposes the underlying conversion, so the action is unambiguous. It does not differentiate itself from the sibling strudel_set_tempo, which is the main gap.

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

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

No guidance on when to use this versus alternatives like strudel_set_tempo or tidal_set_control, and no prerequisites or context about a running session. The agent must infer usage entirely.

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 states the core behavior (stop/silence) and adds a graceful-vs-hush nuance. However, it does not clarify whether stop is reversible, what state changes occur, or whether any side effects affect playback.

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

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

One short sentence with two clauses, front-loaded action, no filler. Every word contributes either the action or the sibling comparison.

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 a single required enum parameter and no output schema, the description is nearly complete for invocation. It could be slightly stronger by saying explicitly what the resulting channel state is or how this differs from hush behaviorally, but the tool is simple enough that little is missing.

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 channel parameter is fully enumerated (d1-d9), so the schema already carries the parameter meaning. The description adds little beyond the singular 'specific channel' notion, which is consistent with 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?

Description uses a specific verb 'Stop' with a specific resource 'a specific channel' and the required channel parameter is documented via enum. It also explicitly distinguishes itself from sibling tidal_hush by positioning itself as 'more graceful' for one channel, so an agent can tell them apart.

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 clear comparative guidance: use this over tidal_hush for single channels. It does not spell out exclusions or mention other sibling tools like tidal_solo/tidal_unsolo, but the context is sufficient for basic routing.

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 it does disclose two non-obvious traits: the tool mutes all other channels, and the state persists until tidal_unsolo is called (i.e., it is reversible and stateful). It omits edge cases such as soloing an already-soloed channel or whether inactive/empty channels can be soloed, 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?

A single sentence, front-loaded with the action and followed by the scope and lifecycle constraint. Every clause earns its place with 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 simple one-parameter tool with no output schema and no annotations, the description covers the effect, scope, and reversibility, which is most of what an agent needs. Minor gaps remain around interaction with other mute tools and behavior on inactive channels.

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 single channel parameter has a documented enum plus a description, so the baseline is 3. The description's "a specific channel" adds no format or semantic detail beyond what the schema already provides.

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

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

Specific verb+resource ("Solo a specific channel") with the effect spelled out ("muting all others"), and it names the sibling tidal_unsolo that reverses it. It does not explicitly distinguish itself from other mute-family siblings like tidal_hush or tidal_silence, so it stops short of a 5.

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 phrase "until tidal_unsolo is called" implies the lifecycle and points at the paired undo tool, which is useful implied usage guidance. There is no explicit when-to-use/when-not statement or comparison against mute alternatives such as tidal_hush or tidal_silence.

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 it discloses a critical non-obvious side effect: in GHCi mode the call starts Tidal if it isn't running, making this not a pure read. It also says the report reflects whether Tidal actually starts. Missing are auth requirements, blocking/timeout behavior, and failure modes, which keeps it 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-loads the core purpose and the returned-fields list, then adds the side-effect caveat and usage cue. Dense and mostly waste-free, though the long comma-separated enumeration reads like a field dump rather than prose.

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

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

For a zero-param tool with no output schema and no annotations, the description covers the returned information and the important side effect, which is what an agent needs to decide to call it. It stops short of describing error/response shape or what a healthy vs unhealthy report looks like.

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 takes zero parameters, so per the rubric the baseline is 4. There is nothing parameter-related for the description to clarify or omit.

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 ('Check') and resource ('the server's setup') and then enumerates the exact facets inspected: mode, ghci/boot file as resolved, Tidal running state and version, control port, last error, log location. That enumeration clearly separates it from siblings like tidal_get_state (musical/pattern state) without needing to name them.

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

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

Provides one usage cue — 'Use it when something doesn't work' — which implies a diagnostic role, but names no alternative tools (e.g. tidal_get_state, tidal_eval) and gives no when-not condition. Usage is implied rather than scoped.

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 does disclose the key behavioral fact that ALL soloed channels are affected, not one, but says nothing about permissions, whether it is a no-op when nothing is soloed, or any side effects.

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

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

One short sentence, front-loaded with the action. The parenthetical is mildly redundant with the main clause but does clarify that all channels are affected.

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, zero-parameter state toggle with no output schema, the description supplies what an agent needs to call it correctly. Deeper behavioral detail (no-op behavior, error conditions) is absent but not critical here.

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 takes zero parameters, so there is no parameter semantics to document. Baseline 4 applies for a 0-param tool.

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 action and resource: restoring all channels that were soloed. The inverse relationship to tidal_solo is evident, though it never names the sibling. The parenthetical is largely a restatement of the tool name.

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

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

The phrase 'after soloing' implies the context of use (undoing a prior tidal_solo). There is no explicit when-to-use/when-not guidance or named alternative beyond the obvious inverse relationship.

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