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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds real substance beyond them: the response includes every tracked variant and condition with USD market price, a price_updated_at timestamp, and 7d/30d changes, so the agent knows what data freshness and granularity to expect.

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 core action and payload, then the lookup prerequisite. No filler and nothing repeated from the schema.

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?

With an output schema, full parameter descriptions, and rich annotations, the description only needs to convey purpose and routing, which it does. The one gap is that it never distinguishes this tool from the price_history/price_stats siblings, which matters for an agent choosing among price-related reads.

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%, so the schema already documents both parameters, including the concise/detailed enum. The description confirms that id may be a slug as well as an id, but says nothing about response_format or when the detailed mode is worth the extra size, so it adds little 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?

States a specific verb and resource ('Get full detail for one BinderDex card') and names the accepted identifiers (id or slug), plus what the payload contains (variants, conditions, prices, deltas). This cleanly separates it from the sibling search tool, which returns lists rather than one card's detail.

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?

Explicitly routes the agent: 'Call binderdex_search_cards first to find the id if you only have a card name.' That is a clear precondition and names the alternative tool. It does not cover when an agent should prefer binderdex_get_price_history or binderdex_get_price_stats instead, so sibling routing is only partially addressed.

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