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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the agent knows the tool is safe and non-modifying. The description adds that it checks for specific stock conditions, but does not elaborate on behavioral aspects like return format, pagination (if any), or data freshness. It does not contradict annotations.

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 a single sentence that efficiently conveys core functionality. It is front-loaded with the purpose. No fluff, but could be slightly more structured (e.g., bullet points) for readability. Still, it earns its place.

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 no output schema, the description should clarify what the tool returns (e.g., a list of problematic rows, a summary). It does not. Annotations are rich, but the description lacks coverage of output behavior. With 2 parameters and moderate complexity, the description is incomplete in conveying the tool's full interface.

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?

The schema has 50% description coverage (reorderDays has a description, rows does not). The tool's description gives context by listing the conditions checked, which implies what the rows input should contain (stock data). However, the 'rows' parameter remains under-described: agents need to know required fields (e.g., product ID, current stock, lead time). The description adds some value but leaves significant gaps.

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 identifies the resource (inventory rows) and the actions (checking for low stock, stockout risk, reorder quantities, stale signals). However, the verb 'check' is generic; a more specific verb like 'analyze' or 'evaluate' would enhance clarity. The purpose is distinct from siblings since no other tools explicitly deal with inventory health checks.

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?

No explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, typical scenarios (e.g., before reordering), or when not to use it. Sibling tools exist for product management and catalog validation, but no differentiation is provided.

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