steward_audio_match

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

With no annotations, the description carries the full burden and delivers substantial behavioral context: cost ($0.01 USDC on Base), the 402 quote rail, quote verification criteria, spend-cap refusal, and payer-key locality. It omits failure/no-match behavior and does not explicitly state the operation is read-only, which an agent must otherwise infer.

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 and sibling routing are front-loaded in the first two sentences; the payment paragraph is dense but each clause (price, rail, verification, caps, key safety) is load-bearing for a paid tool. Slightly long overall, but nothing is redundant.

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 selection, cost, and payment mechanics thoroughly. With no output schema, the return is only sketched as "a matching track recommendation", so structure of the result is left undescribed, which is the one meaningful gap for a single-param discovery 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%, so the baseline is 3, but the description adds example inputs ("a quiet rainy evening", "pre-workout energy") that widen the intended semantic range beyond the schema's single example and clarify that moments and occasions are valid, not just emotions.

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 ("Recommend") and resource ("Brian Booms track") plus the input dimension (emotion, moment, occasion), and explicitly contrasts itself with two named siblings. An agent can differentiate this from steward_audio_rest and steward_audio_focus 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?

Gives an explicit when-to-use condition ("use it when you don't know which track fits") and routes to alternatives with their own conditions ("ready-made listening lanes use steward_audio_rest (wind-down) or steward_audio_focus (deep work)"). Selection between the three tools is fully determined by the description.

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