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

Annotations already declare a safe read (readOnlyHint true, destructiveHint false, openWorldHint true), so the bar is lower, and the description still adds real value: it warns that future retirement dates are estimates and that shipping totals and unverified stock are labelled. Those are data-quality caveats an agent could not get from the annotations or schema.

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 tight sentences with zero filler, front-loaded with what the tool returns and followed by the caveats that qualify that data. Every clause earns its place.

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?

An output schema exists, so return structure need not be explained, and the description covers the content scope plus the two data-quality traps (estimated retirements, unverified stock). The only real gap is the unexplained price_basis option, which matters because it changes which price is reported.

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 exactly 50%: market and language carry descriptions, while set_id and price_basis do not. The description adds no parameter meaning at all — notably it never explains what price_basis "item" versus "delivered" changes, which is the one genuinely ambiguous input.

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 uses a specific verb ("look up") with a specific resource (a set) and enumerates the returned content: specifications, retirement information, and monitored offers. It is clearly distinct from list/search siblings like search_sets or list_themes, though the mention of "monitored offers" overlaps with get_set_offers without explaining the difference.

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?

Usage is only implied: an agent can infer this is the detail-lookup tool for a single set, but the description never states when to prefer it over get_set_offers or compare_sets, nor any prerequisites such as needing a known set_id. No when-not guidance is offered.

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