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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable context beyond this: it states prices are live from the official API, describes the return payload (buy order, sell offer, quantity, spread, copper and readable strings, item metadata). This exceeds the minimal annotation info, though it omits details like rate limits or how 'include_listings' alters the output, which prevents a 5.

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 a single, well-organized paragraph with front-loaded purpose and concrete examples. Every sentence adds information: lookup methods, example queries, return fields, and data source. It is slightly long but not wasteful, so a 4 is appropriate.

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 lookup tool with no output schema, the description thoroughly explains the return values (buy/sell orders, quantities, spread, copper and gold/silver/copper strings, item name/rarity/type/icon) and the live nature of data. It also covers all three parameters via schema and adds precedence notes. Given the tool's simplicity, this description is effectively 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% with each parameter described. The description adds explicit precedence (item_id takes precedence over name) and includes real-world examples (e.g., 'Mystic Coin', 19721). It also clarifies the default behavior of include_listings by example. This extra clarification merits a 4 above the schema-only baseline.

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 has a specific verb ('price') and resource ('Guild Wars 2 Trading Post item'), with clear lookup methods (by name or item_id) and concrete query examples. It unambiguously distinguishes itself from generic commerce tools by focusing on a single item's prices and listing the exact output fields.

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 provides clear context for when to use the tool ('what is X selling for', 'how much is X worth right now') and includes example inputs. It does not explicitly mention alternatives (e.g., commerce_prices) or when not to use it, but the use cases are unmistakable, so it earns a strong 4 rather than a 5.

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