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

Annotations already establish read-only, idempotent, non-destructive behavior, so the bar is lower. The description still adds genuinely useful behavioral context that annotations cannot carry: limits vary per field, some violations are refused while others are merely flagged, and the blocking rules are external and mutable. It does not describe output shape or pagination, but for a small spec lookup that is minor.

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?

Four tight sentences, front-loaded with what is returned and then the imperative to call it first. Every sentence contributes, including the caveat about differing and mutable limits. No filler or redundancy, though the list-like first sentence is dense.

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?

No output schema exists, so the description must stand in for it, and it does so by describing the kinds of data returned (field limits, closed lists, file formats and sizes). Combined with a fully documented two-parameter schema, an agent has enough to invoke and interpret this correctly. A brief note on scoping behavior when entity/release_type are combined would make it complete.

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 description coverage is 100% and both enum parameters carry clear explanations ("Omit for everything", "An album needs more than a single"). The description itself says nothing about entity or release_type, so it adds no meaning beyond the schema. Baseline 3 applies.

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 names a specific resource and enumerates the exact content returned: per-field limits in characters or words, closed value lists, accepted file formats and sizes. It is far more specific than a restatement of the name. It does not, however, differentiate itself from the nearby sibling get_limits, which an agent could plausibly confuse with this tool.

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?

"Call this BEFORE filling anything in" gives explicit, actionable timing guidance that tells the agent where this fits in the workflow relative to the create/update tools. It stops short of naming alternatives or stating when this tool is not the right choice (e.g. versus get_limits or check_readiness).

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