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

The annotations already include readOnlyHint=true, openWorldHint=true, and idempotentHint=true, indicating a safe read operation. The description adds value beyond that by disclosing that track lengths are converted from milliseconds to m:ss format, a behavioral detail not in annotations, and noting a 'cover-art availability stub' (not actual images), which sets expectations. No contradictions.

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 concise and front-loaded: it opens with a clear purpose, lists key data items in a parenthetical, and ends with a specific redirect to a sibling tool. Every sentence serves a purpose (purpose, data details, format note, alternative usage), with no fluff or repetition.

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 simple (one parameter) with strong annotations and an output schema present. The description covers all essential aspects: what data is returned, units conversion, and how to get cover art. It is complete for the tool's complexity, and the output schema handles return value details, so nothing essential 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?

The schema already covers 100% of the single parameter with a clear description ('Release MBID (36-character UUID).'). The description adds context by referencing 'this release MBID' in the cover art instruction, reinforcing the parameter's role. Since schema coverage is high and description adds minimal but useful context, a 4 is appropriate; it exceeds the baseline 3 by clarifying the parameter's usage.

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 what the tool does: 'One edition's full detail by MBID' and enumerates the specific data returned (tracklist, label, catalog number, barcode, etc.). It distinguishes itself from siblings by explicitly pointing to musicbrainz_get_cover_art for actual cover images, and is distinct from other get_* tools by focusing on release-specific data.

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 explicitly includes usage guidance: 'For the actual cover image URLs, call musicbrainz_get_cover_art with this release MBID.' This tells the agent when to use a different tool, which is clear and helpful. It also implies use when a specific release's full details are needed, and the covered fields set a clear scope.

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