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

Beyond the annotations, the description discloses two meaningful behaviors: change percentages are only shown when statistically confident, and calls record usage and query metadata within POKEKA. This is particularly valuable because readOnlyHint is false, so the side-effect disclosure adds important context the annotations do not provide.

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 two sentences with no filler: the core result is front-loaded, followed by a statistical-confidence caveat and a side-effect note. Every sentence contributes meaningful information.

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 description covers the core scope, time window, confidence condition, and side effects, and an output schema exists so return values need not be enumerated. It lacks an explicit pointer to when a sibling tool would be more appropriate, but that gap is already addressed under usage guidelines.

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 input schema already fully documents card_id and weeks, including defaults and ranges. The description reinforces the 26-week cap and mentions 'representative grade', but it does not need to add parameter-level detail beyond what the schema already provides.

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's resource and behavior: a weekly median price series for one card with up to 26 weeks of history plus change percentages. It differentiates itself from siblings by explicitly scoping to 'one card' and emphasizing price-history and confidence-gated percentages, which is distinct from market-wide sibling tools like get_market_brief or recent_sales.

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 the tool is for single-card historical price analysis, but it does not explicitly state when to prefer it over siblings such as card_price or get_market_brief, nor does it provide exclusions or alternative conditions. Usage context is present only by inference from the data scope.

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