price_check

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

With no annotations provided, the description carries the burden of behavioral disclosure. It reveals that the tool relies on locally accumulated price history and that its value grows over time. It implies a read-only action with no side effects. While it doesn't detail the output format or how 'good' is computed, the mention of data source and temporal dependency adds meaningful context beyond a simple 'check price'.

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 concise and well-structured. The first sentence front-loads the purpose, followed by a brief limitation note and a clear parameter list. Every sentence earns its place—no filler words or redundant phrases.

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?

Given the tool's low complexity (two params, no annotations) and the presence of an output schema, the description is remarkably complete. It covers what the tool does, how it works (history accumulation), parameter semantics, and even a practical consideration (usefulness over time). There is no missing critical information for an agent to invoke it correctly.

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 0%, so the description fully compensates. It explains both parameters: 'item' with an example ('boneless chicken breast') and 'zip_code' with format ('5-digit US ZIP code') and optionality condition (optional if GROCERY_ZIP is set). This adds critical meaning beyond the bare schema, which only provides types and a default.

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 verb and resource: 'Judge whether a current price is actually good, using the price history this server accumulates.' This specific purpose distinguishes it from sibling tools like search_deals or store_circular, which are about finding deals, not evaluating a price's quality.

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 clear context for when to use the tool: when you have a current price and want to assess it against historical data. It doesn't explicitly name alternatives or exclusions, but the uniqueness of the use case (price judgment vs. searching deals) makes the usage implied. The note about accumulating history also hints at when it may be less useful (recently started server).

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