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

Adds crucial non-obvious behavior beyond the annotations: each call consumes a Loqate credit, the result is reference data not verification, and IDs can become stale. These details are not captured by readOnlyHint or openWorldHint, so the description carries meaningful extra weight. 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 carry routing, cost, and semantics without filler, and the first sentence front-loads the core action. The closing 'Requires a Loqate API key' is slightly redundant with the schema's key parameter, so it is not a perfect 5.

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 two-parameter tool with a fully documented schema, the description covers what it returns, when to use it, cost side effects, and verification semantics. The absent output schema is partially compensated by the explicit component list; the only minor gap is not clarifying the key-configuration exception mentioned in the schema.

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 input schema already describes both parameters with 100% coverage, including key optionality and suggestion_id staleness. The main description mostly restates that suggestion_id comes from address.suggestions and mentions the API key, so it adds little beyond the schema; a baseline of 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 'Resolve' plus the exact resource ('suggestion id from address.suggestions') and enumerates the returned components. It also explicitly contrasts itself with verify_address, making it easy to distinguish from siblings.

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 says 'Use this when you need the address itself — to fill a form or show a confirmation — rather than a decision' and tells the agent to pass 'suggestion_id' to verify_address instead. It also instructs to resolve only the one chosen suggestion because of the credit cost.

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