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

Annotations already provide readOnly/idempotent/destructive status, and the description adds valuable behavior beyond that: metered access, returns matches or suggestions, and a caution to confirm values against the manufacturer datasheet. This adds useful context about usage cost and data reliability, though it does not detail edge-case behavior such as empty or invalid results.

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?

Four sentences are present, and each contributes essential information: purpose, input modes/precedence, response-format guidance, and metered/caveat context. The first sentence is immediately informative, and there is no filler, redundancy, or unnecessary escalation.

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 full annotations, 100% schema parameter coverage, and an output schema present, the description is sufficiently complete: it specifies input choices, precedence, response format trade-offs, metered access behavior, and a critical accuracy caveat. An agent has enough context to select and invoke the tool correctly.

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 already describes all parameters, but the description adds meaningful semantics by defining precedence when partNumber and query are both supplied and by explaining when responseFormat should be 'compact' versus the default 'full'. This goes beyond the bare schema descriptions and genuinely helps correct invocation.

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 uses a specific verb ('Look up') with a concrete resource ('electronics component pin assignments, voltage range, package, alternatives'), making the tool's purpose immediately clear. It also distinguishes this tool from its API-management siblings by focusing on component data rather than schemas, auth, or breaking changes.

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?

The description gives explicit usage guidance: pass an exact partNumber for one component or use a query for capability search, and it states that partNumber takes precedence when both are supplied. It also advises when to use responseFormat='compact', though it does not explicitly identify converse cases or alternative tools for when this tool should not be used.

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