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

No annotations are provided, so the description carries the burden. It usefully discloses the ordering (newest first) and the full event taxonomy returned, implying a read-only operation. It omits any statement of read-only semantics, permission requirements, pagination/default page size, or truncation behavior at the 500 cap.

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?

A single well-formed sentence that front-loads the resource and scope, then enumerates return content. No filler, nothing redundant.

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?

Output schema presumably documents the returned event records, so the description needn't explain return shape — and its event enumeration is a helpful complement. But with zero annotation coverage and 0% schema description coverage, the undocumented limit parameter and absent read-only/pagination context leave real gaps for a two-parameter tool.

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 must compensate and largely does not. 'One tracked material' conveys that pricebook_item_id targets a single item, but the UUID format, the existence and meaning of the limit parameter, and its 1–500 range/default are entirely absent from the description.

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?

States a specific resource (stock history) with a precise scope: one tracked material, newest first, and enumerates the event types covered (count, receipt, use, return, loss, adjustment). This distinguishes it semantically from stock_list and stock_adjust without naming them explicitly.

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 implied by 'stock history for one tracked material' — an agent can infer this is the audit-log read versus stock_list (current levels) or stock_adjust (mutation). However, no explicit when-to-use/when-not guidance or sibling routing is offered, which matters in a toolset with three other stock-prefixed tools.

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