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

Annotations already declare read-only, idempotent, open-world, non-destructive behavior, but the description adds materially new context: 'Free; no account or tokens required', that automated checks are not listening review, that unkeyed percussion implies audition rather than harmonic fit, that keywords match any term and search_match.missing_terms must be read before claiming a full match, plus attribution/licence obligations. Only pagination/result-size behavior goes unmentioned.

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 the main search facets are front-loaded, and nearly every clause carries operational meaning. The middle section stacks several caveats into dense semicolon chains, which slightly hurts scannability, but there is little pure 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 13-parameter, zero-required search tool with an output schema, the description covers the risky parameters, result-interpretation semantics, cost/auth model, and licence obligations. The missing pieces — pagination via limit/offset and role/pack meaning — are minor since defaults exist and the schema bounds them.

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 schema coverage at only 31% across 13 params, the description compensates well: it explains project_bpm vs bpm_min/max exclusivity, the bpm_tolerance default of 5, include_unkeyed_percussion's audition caveat, key abbreviation acceptance (Am) with 'hard filters stay exact', and that source tags are creator hints. It leaves limit, offset, role and pack semantics unaddressed.

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 and resource — 'Find original synthesis kits and individually auditioned source samples' — and enumerates the facets that define the search space (keyword, pack, BPM, key, role, review_basis, licence). This is clearly a discovery/search tool, readily distinguished from siblings like get_open_loop (fetch by id) and analyze_track.

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: project_bpm with bpm_tolerance returns closest-tempo candidates, and 'do not combine it with bpm_min/max'; project keys need an explicit mode; include_unkeyed_percussion is project-mode only. It does not name sibling alternatives (e.g., fetching a specific loop by id), so it stops short of full routing guidance.

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