Skip to main content
Glama
qso-graph

itu-zones-mcp

by qso-graph

Itu Zones Lookup

itu_zones_lookup

Look up an ITU zone by number (1-90) to get its IARU-listed prefixes, subdivisions, boundaries, ADIF codes, and source citation.

Instructions

One ITU zone: every prefix, subdivision and boundary the IARU lists for it, with ADIF codes and the citation. Zones 76-77 and 79-89 have no entry in this edition.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesAn ITU zone number, 1 to 90.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses a significant behavioral trait: coverage gaps (zones 76-77 and 79-89 return no entry), which is important for an agent to know. However, it doesn't state whether a missing zone returns an empty result or an error, nor does it cover rate limits or auth. Partial credit for the coverage disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences, front-loaded with purpose followed by the coverage caveat. No wasted words; each clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained. For a simple single-parameter lookup, the description covers purpose and coverage gaps adequately, but it omits error behavior (what happens for zones 76-77/79-89) and any routing to sibling tools, leaving a gap in an otherwise complete definition.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single 'code' parameter is documented as 'An ITU zone number, 1 to 90.' The description adds the important cross-reference that certain codes have no entry, but this is schema-adjacent rather than adding syntax or format beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('One ITU zone') and enumerates exactly what is retrieved: prefixes, subdivisions, boundaries, ADIF codes, and citation. This clearly distinguishes it from siblings like itu_zones_search or itu_zones_codes_for.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (retrieve full details for a single zone), and the coverage caveat (zones 76-77, 79-89 have no entry) is useful, but it doesn't explicitly say when to use this versus itu_zones_search or itu_zones_codes_for. No explicit alternatives named.

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