get_price

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

No annotations exist, so the description carries full weight. It discloses returns (current, low, history) and notes the data powers Monte Carlo simulation. While rate limits and error handling are omitted, the output schema covers return format, making this sufficient.

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 front-loaded with purpose and input options. The Monte Carlo sentence adds context but could be trimmed; it remains acceptable without being overly verbose.

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 has low complexity with an output schema. The description covers main outputs and input options. It does not mention pagination or prerequisites (e.g., using search_cards to find product IDs), but for a straightforward price tool, it is largely 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 coverage is 100%, but the description adds critical context: the exclusive-or relationship between card_name and product_id, and that card_name uses fuzzy search. This goes beyond the schema's individual parameter descriptions.

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 the tool gets 'the latest market price and historical price data for a trading card,' with specific verbs and resources. It distinguishes from siblings like search_cards (search vs get) and simulate_price (simulation), but does not explicitly differentiate from get_market_snapshot.

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 implies use when needing price data for a card and specifies input options (card name or product ID). It does not provide explicit when-not-to-use guidance or alternatives like search_cards for finding product IDs.

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