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

No annotations are supplied, so the description carries the full burden. It does add real behavioral color ('warns when it keeps going out of stock'), which is genuinely useful context beyond a plain read, but it says nothing about failure modes for an unknown part number, or that supplying project_id links the call to a project dashboard (a side effect only the schema hints at).

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 front-loaded sentence whose subordinate clauses are all content items rather than filler. Dense but every phrase earns its place; only the parenthetical warning is slightly tacked on.

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?

An output schema exists, so the description did not need to enumerate return fields yet spends its whole length doing so, while omitting routing guidance against five sibling tools and the project_id side effect. Adequate to recognize the tool, incomplete for deciding when to call it.

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 75%, so the baseline is 3. The description's mention of a 'full price ladder' implies quantity-break pricing and therefore gives indirect meaning to the undocumented qty parameter, but it never addresses qty, manufacturer disambiguation, or project linking directly.

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 ('one part') and enumerates the exact payload: specs, offers with price ladder, datasheet, pinout, footprint, stock trend. The singular framing implicitly contrasts with the plural find_parts sibling, but no sibling is named, so differentiation is left to inference.

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: 'one part' plus the required identifier parameter suggests 'call this when you already know which part you want'. There is no explicit when-to-use, when-not, or pointer to find_parts/find_alternatives for discovery or substitution.

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