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

With no annotations and no output schema, the description must disclose behavioral traits itself, but it does not. It does not say whether evaluating a pattern replaces the previous pattern on that channel, whether evaluation immediately affects sound, how errors are surfaced, or whether the pattern persists until changed or silenced. 'Evaluate' implies sending a command, but the runtime effects and side effects are undocumented.

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 scope. Every clause earns its place; the 'main way' comment is useful orienting context, not 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?

The tool is relatively simple, but it lacks any behavioral or result context, and there are no annotations or output schema to compensate. An agent is not told what to expect after evaluation, whether the action is additive or replacing, or how to stop or alter the result. The parameter schema is complete, but the overall operational picture is incomplete.

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 tool description adds no meaningful parameter semantics beyond what the schema already states. The channel range and the note that pattern excludes the 'd1 $' prefix are both already present in the schema properties, so the description provides no extra value here.

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

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

The description names a specific verb ('Evaluate'), a clear resource ('a TidalCycles pattern'), and a precise scope ('on a specific channel (d1-d9)'). The statement 'This is the main way to make music with Tidal' distinguishes it from the surrounding utility siblings like tidal_hush and tidal_silence, so an agent can recognize it as the core sound-producing tool.

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

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

The 'main way to make music' phrase implies this is the primary tool for expressing patterns, but the description gives no explicit guidance about when to prefer it over siblings or when to use alternatives like tidal_silence or tidal_solo. The intended usage is clear enough, but exclusions and alternatives are left unstated.

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?

No annotations are provided, so the description carries full behavioral burden. It communicates a read-only intent via 'get' and specifies scope (all channels) and content (patterns, start times), which separates it from mutating siblings. However, it does not explicitly state non-destructiveness, session requirements, or edge-case behavior, leaving the safety profile implicit.

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 verb and resource, with a dash clause that disambiguates what 'state' means (patterns + start times). No filler; every element 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 zero-parameter query tool with no output schema, the description covers the essentials: operation, scope, and return content. Minor gaps — return format and behavior when no channels are active — would require an output schema or one more clause, but they do not jeopardize correct invocation.

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

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

With zero parameters and 100% schema coverage, the baseline is 4. The description adds nothing about parameters because there are none to document; instead it clarifies what the tool returns, which is the relevant semantic content for an agent.

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?

Uses a specific verb 'get' with a specific resource 'current state of all channels' and specifies the return content (patterns and start times). This clearly distinguishes it from sibling query tools like tidal_get_history (past) and tidal_get_samples, and from the mutation tools (tidal_hush, tidal_silence, tidal_solo, tidal_unsolo, tidal_eval).

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 word 'current' implies this is for live-state queries, and the contrast with tidal_get_history (history vs. current) is evident but never made explicit. No alternatives are named and no exclusion criteria are given — the routing guidance is implied 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 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?

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 provided, the description carries the full burden of behavioral disclosure. It explicitly reveals that calling the tool mutes all other channels and that the effect is temporary, which is key behavioral information beyond the schema. It does not mention edge cases like toggling an already-soloed channel, but 'temporarily' signals reversibility sufficiently for a simple 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 is a single sentence with zero wasted words, and it front-loads the primary action ('Solo a specific channel') before the side effect. Every word 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 one-parameter tool with a complete schema and no output schema, the description covers the core behavior and the temporary nature of the effect. It could have explicitly pointed to tidal_unsolo for reverting, but the 'temporarily' phrasing combined with the sibling-tool list gives an agent enough context to select and invoke it correctly.

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

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

The only parameter 'channel' is already fully documented by the schema (enum d1–d9 with description 'The channel to solo'), so schema coverage is 100%. The description's phrase 'a specific channel' aligns with the schema but adds no new semantic detail beyond what the schema already provides, 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?

The description states a specific verb ('Solo a specific channel') and resource ('channel'), and discloses the key side effect ('muting all others temporarily'), which differentiates it from siblings like tidal_unsolo and tidal_hush. This is unambiguous and distinguishes the tool without needing to open 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?

The description conveys the usage context (when you want to isolate one channel) but does not explicitly mention alternatives or conditions that would select tidal_hush or tidal_unsolo. The context is clear, but there is no exclusion or alternative routing, only an implied use case.

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 reveals that all channels are restored, but it does not mention what happens if nothing was soloed, whether the action is idempotent, or how it interacts with previous mute or silence states.

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. For a zero-parameter tool, this length is appropriate and every word contributes to meaning.

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

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

The description is adequate for a simple zero-parameter inverse action: an agent can infer that this undoes the soloed state. However, with no annotations or output schema, some behavioral edge cases remain ambiguous, such as behavior when no channels are soloed.

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

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

The tool has zero parameters and 100% schema description coverage, so no parameter documentation is required. The phrase 'all channels' adds a small amount of semantic clarity about the operation's scope.

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 operation: restore all channels after soloing. It is specific about the action and scope, though it does not explicitly differentiate itself from sibling tools like tidal_solo.

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 when to use the tool, giving some contextual guidance. However, it does not explicitly explain when not to use it or how it compares to alternatives like 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.