Summarize Price History

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

Annotations already declare readOnlyHint=true, so the description only needs to add behavioral context. It does so by clarifying the output type (compact summary), naming the returned metrics, and stating that either itemId or name can be used. It does not cover edge cases like missing identifiers or what happens if both are provided, but given the annotation coverage, this is 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 only two sentences, front-loaded with the purpose and output, and the second sentence provides the alternative tool. Every word adds value; there is no fluff or repetition.

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 no output schema, the description compensates by explicitly listing the summary metrics and contrasting with get_item_graph. It does not explain behavior for invalid or omitted identifiers, but for a read-only tool with well-documented parameters, the description 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 descriptions cover 100% of parameters, so the baseline is 3. The description repeats 'by itemId or name' but adds no new parameter-specific details. It also does not clarify that exactly one of itemId or name must be supplied, even though the schema lacks required fields. This is a notable gap, but the schema already provides basic parameter meaning.

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 states a specific action ('Summarize recent Grand Exchange price trends for an item') and lists concrete output components (min/max/average price, change, average daily volume). It explicitly differentiates from the sibling tool get_item_graph by noting it returns a compact summary instead of raw data points.

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 gives an explicit alternative: 'use get_item_graph when you need the full price series.' It also implies when not to use this tool ('instead of raw data points'), making the choice clear and actionable.

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