Standardise or search Czech RÚIAN addresses (CZ only)

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds important behavioral context: it is powered by ARES's POST endpoint, returns a stav_standardizace field indicating match quality, and supports cache bypass via the fresh parameter. No contradictions 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?

The description is well-structured with a main paragraph, bullet-point use cases, and a standardisation mode section. It is concise but covers essential information. A slight improvement could be moving the 'Other jurisdictions return 501' note to the jurisdiction parameter description, but it's still clear.

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?

Given the presence of an output schema (not shown), descriptions for all 18 parameters, and clear annotations, the description is complete enough. It explains the core functionality, supported modes, response quality indicator, and jurisdiction restriction. No apparent gaps.

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% (all 18 parameters have descriptions). The description adds value by grouping parameters into free-text vs. structured (obec/street/house number) and provides example values like 'Národní 37/38, Nové Město, Praha 1'. However, it does not add significant new meaning beyond the schema, so a 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?

The description clearly states the tool resolves free-text or structured Czech addresses against the RÚIAN register and returns normalised addresses with geographic codes. It distinguishes itself from siblings by clearly being the only address-specific tool among many company/document search tools.

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 explicitly lists three use cases: normalising addresses, resolving to canonical codes, and validating existence. It explains the two standardisation modes and when to use each. It also mentions pricing (free) and jurisdiction restrictions ('CZ only', other jurisdictions return 501). This provides clear guidance on when and how to use the tool.

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