find_sound

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 add real behavioral value: the search spans four heterogeneous sources (library, channel strips, patch files, plug-in names) and matches German and English instrument names. It does not disclose whether results are ranked, how they are ordered or grouped, or what a hit looks like, so the disclosure is partial.

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, front-loaded with the user-facing question followed by the concrete search scope. Almost no waste; the only weakness is that the scope sentence is a comma list rather than prioritized information.

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?

There is no output schema and no annotations, so the description is the only structured guidance available. It adequately covers inputs and sources but leaves the agent guessing about result shape, ranking, and the meaning of 'limit' – material gaps for a discovery tool with no other documentation.

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?

Only the 'query' parameter is documented, and the bilingual matching note largely repeats the schema's own example list ('Flöte', 'flute'). The second parameter, 'limit', is undocumented everywhere – no maximum, no statement of what is being limited or how results are ordered before truncation. With 50% coverage the description should compensate but does not.

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?

Clear verb ('searches') plus an explicit enumeration of the four sources it federates: sound library, concert channel strips, exported patch files, and installed plug-in names. An agent knows exactly what the tool covers. It loses a point because a sibling named 'search_sounds' exists and the description never states how this differs, leaving a plausible ambiguity.

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 framing question 'Where can I find a sound like this?' implies the discovery/lookup use case, but there is no explicit statement of when to pick this over 'search_sounds', nor any exclusion. Given a near-identical sibling name, this is an implied-usage-only situation.

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