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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the equivalence to a filtered directory_list_works call and the 'work(s)' plural hinting that one ISRC can map to multiple works. It stops short of stating what happens on no match or how results are ordered, which would be the remaining behavioral gap.

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-loaded with the trigger condition, then the shortcut definition, then the chained next tool using an arrow marker — the structure mirrors how an agent reads it. The three quoted example utterances are mildly redundant with the verbatim purpose statement and the description is somewhat denser than needed, but nothing is 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 single-parameter, read-only lookup with no output schema, the description covers what it returns (the matched work(s)) and where to go for full details. Only the not-found / multiple-match outcome is unaddressed, a minor gap given the tool's simplicity.

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 schema documents the ISRC format with an example, so the baseline is 3. The description adds real meaning by framing ISRC as a recording identifier used for recording-first discovery, which disambiguates it from the work identifier expected by directory_lookup_work.

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 (look up the work(s) for an ISRC) and explicitly distinguishes itself from siblings: equivalent to directory_list_works with an isrc filter, pinned for recording-first discovery. An agent can tell why this exists alongside directory_list_works and directory_lookup_work 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 concrete user phrasings that should trigger it ('lookup ISRC X', 'find the work for this recording'), states the alternative it wraps (directory_list_works with an isrc filter), and names the follow-up tool. When-to-use, the alternative, and the next step are all explicit.

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