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

Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses that Workers AI performs the split (implying non-determinism, with the explicit warning 'check the parts'), that postcodes are validated against 18 country rule sets and a mismatch is dropped and reported, that geocoding comes from OpenStreetMap Nominatim, and that pricing is $0.002 USDC per successful call via x402 with failed calls uncharged.

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?

Purpose and output fields are front-loaded, followed by the validation caveat, the reliability warning, and pricing. Every sentence carries information, though the density (four packed clauses covering parsing, validation, geocoding, and payment) makes it slightly heavy for a single paragraph.

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?

With an output schema present, return format need not be explained, and the description still covers the failure mode (postcode mismatch omitted and reported), the reliability caveat, the geocoding side effect, and the x402 payment terms. Nothing an agent needs to call this correctly is missing.

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 baseline is 3. The description largely restates the schema (geocode pulls OSM coordinates, country improves the postcode check) and adds only the incidental detail that 18 countries are covered and that the geocode source is Nominatim.

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 ('splits') and resource ('free-text postal address') and enumerates the exact output components (house number, street, unit, postcode, city, district, region, country plus a normalised one-line form). This clearly separates it from the geocode, us_geocode, and postcode 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?

Usage is implied rather than stated: 'geocode=1 adds coordinates' lets an agent infer it can substitute for the geocode tool, and 'country ... improves the postcode check' hints at when to supply the optional field. But there is no explicit when-to-use/when-not statement or direct comparison with the geocode, postcode, or us_geocode siblings.

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