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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is fully covered structurally. The description adds the useful content detail that the edition of the IARU list is part of the payload, but nothing further about freshness, caching, or provenance. Modest value on top of rich 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?

A single sentence, front-loaded with the primary return value and with zero filler. Nothing could be removed without losing meaning.

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?

An output schema exists, so the description need not enumerate return fields; it just frames the two headline values, which it does. For a trivial, no-argument metadata tool this is essentially sufficient, with only the sibling overlap unresolved.

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 tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate. The description correctly implies a parameter-free call.

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 uses a specific verb and resource ('Get itu-zones-mcp's version') and names a second return value ('the edition of the IARU's list it serves'), so an agent knows exactly what this returns. It does not explicitly distinguish itself from the similarly purposed sibling itu_zones_source_info, which is the one remaining ambiguity.

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 only implied: an agent can infer this is a diagnostic/metadata call, but the description never states when to use it versus itu_zones_source_info or the lookup siblings. No exclusions or prerequisites are given, leaving routing to inference.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful behavioral context by explaining that split entities return each zone with the IARU's boundary wording, which goes beyond the annotations and helps an agent understand the shape of the result.

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 two sentences, front-loads the core purpose, and uses the second sentence to clarify a meaningful edge case. Every sentence earns its place without repetition.

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 complete schema coverage, strong annotations, and an output schema, the description supplies enough context for an agent to call the tool correctly. It could be slightly more complete by routing the agent away from sibling tools, but that omission is minor for this simple lookup.

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 both parameters are already documented structurally. The description reinforces that the input is an ADIF DXCC entity or one of its subdivisions but does not add syntax or format details beyond the schema, making the baseline score 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 that the tool returns ITU zones covering an ADIF DXCC entity or one of its subdivisions. It is specific about the resource and input scope, though it does not explicitly differentiate itself from sibling tools such as itu_zones_lookup or itu_zones_search.

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 by the phrase 'Which ITU zones cover an ADIF DXCC entity, or one of its subdivisions,' but there is no explicit statement of when to use this tool rather than its siblings or when not to use it. No alternatives or exclusions are named.

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

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

Annotations already declare the safe read-only, idempotent, closed-world profile, so the description is free to add real substance: it discloses that zones 76-77 and 79-89 have no entry in this edition, which prevents a false negative from being read as a bug. It still doesn't say whether a missing zone raises an error or returns empty.

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, no filler, payload front-loaded (what one record contains) followed immediately by the caveat. Both sentences earn their place.

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 a single param, full annotations and an output schema, the description carries enough: content of the record plus the coverage gap. The one unresolved point is the failure mode for the excluded zones, which an agent must guess.

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% and the code param is documented as 1-90, so the baseline is 3. The description earns above that by naming the specific codes in that range which yield no entry, giving the agent information the schema does not carry.

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 resource and scope: a single ITU zone with every prefix, subdivision, boundary, ADIF code and citation the IARU lists. That reads clearly against the plural/search siblings (itu_zones_search, itu_zones_codes_for). No verb is used ("One ITU zone: ..."), and it never explicitly names which sibling to use instead, so it stops short of a 5.

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 only implied by the singular framing ("One ITU zone") contrasted with the search/codes_for siblings; it never says when to prefer this over itu_zones_search or itu_zones_valid_on. No prerequisites or exclusions beyond the missing-zones note.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is covered. The description adds real value beyond that by disclosing the matching semantics: conjunction across multiple fields, not a single-field exact match. It omits case sensitivity and result ordering, which are minor given the 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?

A single sentence with no filler, front-loading the verb and the fields searched. It is efficient rather than padded, though extremely terse for a tool with several near-name siblings.

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?

An output schema and rich annotations carry most of the load, and the parameter schema is fully described, so little is strictly required of the description. Still, for a search tool it leaves unclear whether matching is case-insensitive or substring-based, which affects how an agent phrases the query.

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 both parameters are already documented with examples and a limit range, establishing the baseline of 3. The description's 'every word of text' adds a conjunctive-matching nuance beyond the schema example, but nothing about how words are tokenized.

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 verb 'Find' plus the resource 'codes' is specific, and the description goes further by naming the searchable fields (name, prefixes, area wording, attributes). It does not explicitly contrast itself with the close siblings itu_zones_lookup or itu_zones_codes_for, so an agent must infer that this is the free-text search variant.

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 matching rule ('contain every word of text') implies the tool is for multi-word/fuzzy discovery rather than exact lookup, which implicitly routes it against itu_zones_lookup. However, no when-to-use or when-not-to-use statement is given, and no alternative is named.

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

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior. The description adds the returned provenance fields but no further behavioral context such as caching, freshness, or how the source files are validated.

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?

It is a single efficient sentence that front-loads ownership and then enumerates edition, terms, URLs, and hashes. There is no filler.

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, the description need not explain return structure, and it summarizes the key contents well for a zero-parameter metadata tool. The only notable gap is routing versus the similar-sounding get_version_info sibling.

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?

This tool has zero parameters, so there is no parameter semantics burden. The empty schema is clear, and the description appropriately does not invent parameter behavior.

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 metadata returned: ownership, served edition, terms, file URLs, and SHA-256 hashes. It distinguishes this from lookup/search-style siblings by focusing on provenance and source details, though it does not explicitly name alternatives such as get_version_info.

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 gives no explicit guidance on when to use this tool versus get_version_info or the lookup/search tools. An agent can infer it is for source/provenance metadata, but that inference is not stated.

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

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

Annotations already cover the safe-read profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds a genuinely useful behavioral fact: because the source chapter defines no validity window, any listed zone is valid, so the answer will essentially always be affirmative. That pre-empts an agent over-interpreting a 'true' result.

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 short sentences with the core question front-loaded. The 'chapter' framing is slightly lore-dependent but still earns its place by explaining why every zone is valid.

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?

A low-complexity boolean query with a full output schema, so return values need no explanation; the description supplies the one non-obvious fact (validity is effectively universal for listed zones). Only missing piece is a pointer to sibling tools for lookup/search.

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%, with both code (ITU zone number 1-90) and on_date (YYYY-MM-DD) fully documented in the schema. The description adds no further parameter semantics beyond what the schema supplies, so the baseline 3 applies.

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 question the tool answers (whether an ITU zone was valid on a date) plus the required inputs implicitly. It does not name or contrast against siblings like itu_zones_lookup or itu_zones_search, so differentiation is left to inference.

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 — call it when you need a validity verdict for a zone code on a date — but there is no explicit when-to-use/when-not or named alternative such as itu_zones_lookup. The closing clause about consistent answers across servers hints at context without giving routing guidance.

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