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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the cost ($0.01 USDC via x402) and the 'advanced AI-powered' nature, which are useful behavioral/operational details beyond the annotations. It does not describe output format or failure modes, but for a read-only key-generation tool, the added cost and scope context justify a 4.

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?

Two sentences with no filler. The core purpose is front-loaded, followed by the handled cases and the cost. Every sentence earns its place, and the description is appropriately sized for a simple 3-parameter tool.

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 read-only, idempotent key-generation tool with 100% schema coverage and no output schema, the description is nearly complete. It covers purpose, scope, handled cases, and cost. The only minor gap is not describing the output format (e.g., what the similarity key looks like), but the annotations and schema already provide enough for an agent to invoke it 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?

Schema description coverage is 100%, so the schema already documents all three parameters (address, zip, algorithm). The description adds that zip is 'optional but recommended for precision' and that algorithm is a variant, but these are minor additions. Baseline 3 is appropriate because the schema carries the parameter documentation burden and the description does not meaningfully extend it.

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 verb ('Generate'), a specific resource ('US street address matching'), and the key mechanism ('AI-powered similarity key'). It also lists handled cases (unit numbers, directionals, abbreviations), which distinguishes it from generic address tools. The title 'US Street Address Match Key' reinforces the purpose, and the sibling list shows it is distinct from interzoid_global_address_match and interzoid_address_parse.

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 implies when to use this tool: when you need a similarity key for US street addresses, especially with unit numbers, directionals, and abbreviations. It does not explicitly state when not to use it or name alternatives, but the sibling list and the 'US' qualifier provide clear context. The optional zip recommendation gives a usage hint, but no explicit exclusion of global addresses or parsing use cases.

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