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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false. The description adds substantial behavioral context beyond that: it specifies the returned price types (latest daily TCGplayer market, lowest listed per printing), date and currency, page URL, and the raw/ungraded limitation.

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 tightly written sentences, front-loaded with the usage condition, then the return summary, limitation, and input prerequisite. Each sentence contributes actionable information with no 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?

With an output schema present, annotations covering safety, and one fully documented parameter, the description still provides complete invocation context: when to use it, what it returns, its limitations, and the required input source. 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?

Schema description coverage is 100% and the single parameter is fully documented in the schema as a TickerMint product_id from search_cards. The description merely repeats this prerequisite without adding syntax, format, or constraint details beyond the schema.

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 resource and scope: latest daily TCGplayer market price and lowest listed price per printing for one card or sealed product. However, it does not explicitly differentiate from siblings like sealed_prices or price_history; search_cards is named only as an input dependency, not as an alternative.

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 a clear usage trigger (user asks what one specific card or sealed product is worth today), an exclusion (raw only; not an appraisal of a particular copy), and a prerequisite (needs product_id from search_cards). It does not name alternative tools such as price_history or all_time_highs for related queries.

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