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

Beyond the annotations (readOnly, idempotent, openWorld, non-destructive), the description discloses the paid nature with exact pricing (0.005 USDC via x402), a critical operational fact. It also explains the resolution process: uses JAN/EAN-13, manufacturer data, aliases and official-source evidence to collapse ambiguous names into a canonical identity. No contradiction with 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?

Four sentences, front-loaded with the core purpose and followed by evidence-based resolution, pricing, and trigger conditions. Some minor filler like 'for agents that need a reliable product identity' adds limited information, and 'cheapest' is mildly promotional, but overall each sentence contributes to selection or invocation.

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?

For a 3-parameter tool with an output schema, the description covers the main gaps: how to invoke (query or id), what input kinds are accepted, when to choose it, and the cost/payment method. The presence of an output schema means return-value explanation is unnecessary. The anyOf structure in the schema handles the query-vs-id choice, and the description reinforces the intended use.

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 67%: query and id have descriptions, lang has only an enum without a textual description. The description compensates for query semantics by enumerating accepted inputs (product name, character, JAN/EAN-13, model number, series name, ambiguous collectible description) and clarifies the goal of canonical product resolution. It doesn't add anything for id or lang, but those are straightforward from property descriptions and enum values.

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 states a specific action (Identify the exact Japanese anime figure or collectible) and a clear resource (canonical product via JAN/EAN-13, aliases, manufacturer data). It distinguishes itself from siblings logically: says to use it before searching prices or buying, which separates it from search_anime_product and anime_market, and 'cheapest paid entry point for reliable product identity' positions it against full_intelligence.

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?

Provides explicit trigger conditions: 'Use first when the user gives a product name, character, JAN/EAN-13, model number, series name or an ambiguous collectible description.' This gives the agent clear selection criteria. It does not explicitly state when not to use it or name an alternative like search_anime_product, but the 'Use first' ordering and 'before searching prices or buying' strongly imply the routing decision.

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