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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description goes further with what an agent actually needs: prices are live catalogue prices, in AUD, ex-GST, unit price steps down with quantity, and every tier is covered by the Best Price Guarantee. It also discloses the paging contract (default 100, max 200, total/returned/offset/hasMore/nextOffset), which is behavior the annotations do not express.

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?

Front-loaded with the core claim, and each following sentence adds a distinct fact (semantics, guidance, paging). The mid-length category enumeration is purposeful for retrieval but borders on padding, and the all-caps 'PAGED' block at the tail would read better adjacent to the tool's core statement.

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 still covers the return envelope (total, returned, offset, hasMore, nextOffset) and the pricing conventions an agent must not misreport. For a 3-parameter, zero-required read tool, nothing needed to call it correctly is missing.

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%, so baseline is 3; the description still adds meaning by explaining the pagination loop ('call again with offset=nextOffset') as a single connected behavior rather than three separate parameters, and by noting that locale 'gates AU-only offers and localises the FAQs' — a consequence not visible in the schema. It stops short of saying how currency behaves under non-AU locales.

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?

Opens with a specific resource and scope: 'Entry (From) prices for 100 promotional product categories', then backs it with the concrete category list (pens, keyrings, tote bags…) so an agent can pattern-match a product query immediately. It also pins down the exact semantics of the returned figure ('the From price is the ladder's lowest unit price, reached at volume — it is not the price at MOQ'), which is the single most confusable point in this tool.

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?

Gives explicit activation phrases ('how much do promotional X cost', 'cheapest promotional X Australia', budget planning, supplier price comparisons) and an explicit handoff: 'Use this FIRST … then get_quote for an exact quantity.' The first-step/second-step ordering removes any ambiguity about which tool to call first.

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