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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: the index is chain-linked with base 100, includes time windows (7/30/90 days), and aggregates across a game or set rather than a single card. It does not describe the exact return envelope, but the listed output metrics partially compensate given no output 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?

The description is compact but information-dense, with the core meaning front-loaded, followed by usage guidance and an explicit anti-pattern with alternatives. Every sentence earns its place, and the exclusion is stated directly without 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?

For a read-only trend tool with full schema coverage, the description is substantively complete: it explains what data is shown, how to use it, how to compare scopes, and when not to use it. It doesn't explain edge cases like basis behavior during multi-scope comparisons, but the schema already covers that and the tool has no output schema requiring return-value documentation.

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 parameters are already well documented in the schema. The description reinforces that `scope` is a game or set and that `vs` compares scopes with a cap of 3, but it does not materially add parameter-level details beyond what the input schema 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 opens with a specific verb and resource ('Shows the cross-market price trend for a whole game or a single set') and enumerates the exact metrics returned: chain-linked base-100 index, 7/30/90-day movement, total market value, median price, and product count. It also explicitly distinguishes itself from single-card tools by naming price_card and list_printings as alternatives.

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?

It states direct usage triggers ('Use this for "how is Pokemon / this set trending" questions') and gives a clear exclusion: 'This is trend data across a set, NOT a single card's price — use price_card or list_printings for one card.' It also explains how to do comparisons via a comma-separated `vs` list, giving an agent actionable selection guidance.

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