Skip to main content
Glama
qso-graph

io.github.qso-graph/cq-zones-mcp

by qso-graph

Cq Zones Codes For

cq_zones_codes_for
Read-onlyIdempotent

Returns the CQ zone codes covering an ADIF DXCC entity or subdivision, including boundary wording where CQ splits an entity, so you can map locations to WAZ zones.

Instructions

Which CQ zones cover an ADIF DXCC entity, or one of its subdivisions.

Where CQ splits an entity (VE2 Quebec at the 50th parallel), each zone is returned with CQ's boundary wording.

Input Schema

NameRequiredDescriptionDefault
dxccYesADIF DXCC entity code (e.g. 291 for the United States, 1 for Canada).
subdivisionNoADIF Primary_Administrative_Subdivision code, e.g. "QC" or "AZ".

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare this as a read-only, idempotent, non-destructive operation, so safety behavior is covered. The description adds useful context beyond annotations by explaining that split entities can return multiple zones with CQ's boundary wording, though it does not cover not-found or error behavior.

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?

The description is two short sentences and front-loads the core purpose. The second sentence earns its place by documenting the important split-entity return behavior.

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

Completeness4/5

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

For a simple two-parameter, read-only lookup with full schema coverage, annotations, and an output schema, the description is largely complete for correct invocation. The main remaining gap is routing guidance relative to the sibling tools.

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 description coverage is 100%, so the schema already explains both dxcc and subdivision parameters. The description reinforces the entity/subdivision concept but does not add syntax, constraints, or examples beyond what the schema provides, making the baseline 3 appropriate.

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

Purpose4/5

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

The description clearly states a specific verb-and-resource query: which CQ zones cover an ADIF DXCC entity or subdivision. It is understandable without opening the schema, but it does not explicitly distinguish this from siblings such as cq_zones_lookup, cq_zones_search, or cq_zones_valid_on.

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?

Usage is implied by the query wording: an agent can infer this is for mapping a DXCC entity or subdivision to CQ zones. However, the description gives no explicit when-to-use guidance, no exclusions, and no named alternatives among the sibling tools.

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