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

The annotations already cover the safety profile (readOnly, idempotent, non-destructive, not open-world), so the description's job is context — and it delivers real operational facts: update cadence ('listings every ~5 minutes', 'updated through the day'), a data availability boundary ('Listing history starts 2026-10-30'), source provenance per bucket (Rust.tm, CS.Deals, DMarket, Mannco.store, RustSkins), and units ('integer USD cents'). What it does not disclose is cost/latency of a wide-range call or behavior when a site has no data for the requested window.

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 core purpose is front-loaded in sentence one and the dense middle section is justified because there is no output schema and the return shape is genuinely non-obvious. It is weakened by run-on formatting (line breaks mid-clause, a bare URL fragment dropped in the middle) that makes the single most important sentence — what the payload looks like — harder to parse than it needs to be.

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 carries the full burden of explaining returns and does so thoroughly: field layout for `listing` and `sales`, bucket naming, pricing units, and per-source provenance. The remaining gap is that `range` semantics and the interaction between requested range and the fixed/rolling series are unaddressed, so an agent cannot fully predict a response for a given range value.

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% and the enum values are already documented in the schema, so the baseline is 3. The description never mentions the `range` parameter or how it interacts with the differently-sourced series (`r1`/`r7`/`r30` versus 'real sales buckets'), which is exactly the semantic an agent would need clarified beyond the schema.

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 first sentence names a specific verb and resource ('Price and sales history for one skin') and the scope 'on each marketplace', immediately followed by 'every marketplace rust.wiki tracks, Steam included', which separates it from single-market siblings like get_skin_price or get_skin_price_history. It never names a sibling directly, so an agent still has to infer which of the ~60 siblings is the near-duplicate, but the scope statement is clear enough to choose correctly.

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?

Usage is only implied by scope ('each marketplace', 'every marketplace rust.wiki tracks, Steam included') rather than stated as a rule. The only explicit routing hint is the trailing 'Steam's own sale history is GET /skins/{itemdefid}/history', which points to an alternative for Steam-native sales but reads as a footnote rather than guidance. There is no statement of when NOT to use it versus get_skin_price_history or compare_market.

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