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

Annotations declare readOnlyHint, openWorldHint, and idempotentHint, so safety profile is covered. The description adds critical x402 payment behavior: returns payment requirements unless payment_signature is given, and notes the price ($0.004 USDC on Base). This dual-mode behavior (challenge vs. paid response) is not evident from annotations or schema. Does not describe rate limits or error modes, but adds substantial value.

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?

Three sentences, each earning its place: purpose, usage scenarios, and payment/return behavior plus sample link. Front-loaded with the core function. No waste.

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?

Complete enough for an agent: purpose, usage context, payment mechanics, and sample path are covered. No output schema exists, so description needn't explain return values beyond the payment-requirements behavior, which it does. Missing only minor details like rate limits or error handling.

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 100%, so the schema documents all five parameters thoroughly. The description mentions payment_signature behavior and implies query/code usage, but adds little beyond what schema already provides. Baseline 3 is appropriate.

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 verb (find) and resource (HS/commodity code and import duty) with clear scope (goods shipped into UK or US). Distinguishes itself from siblings like screen_export_control and check_eori by focusing on tariff lookups rather than compliance screening.

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?

Explicitly names when to use it: 'when quoting landed cost or preparing a UK or US customs entry'. This gives concrete scenarios that differentiate it from other trade tools. No exclusions listed, but the scenarios are specific enough.

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