cq_zones_searchSearch CQ zones by name, prefix, area wording, or attributes to find matching zone codes for locations or callsigns.
Find codes whose name, prefixes, area wording or attributes contain every word of text.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Words to look for, e.g. "Quebec", "VE2" or "Antarctic". | |
| limit | No | Most records to return (1 to 200, default 50). |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds one genuine behavioral detail — all words must match (conjunctive matching) across multiple fields — but says nothing about result ordering, truncation behavior, or empty-result handling.
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 front-loaded sentence with no filler. The matching semantics arrive before any caveats, and every clause carries information.
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 return-shape explanation is correctly omitted, and the AND-matching rule plus searched-field list cover the core invocation decision. The only gap is what happens when matches are numerous — ordering or truncation hints — which is minor given limit is schema-documented.
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%, with 'text' and 'limit' both documented including bounds and default, so the baseline is 3. The description contributes the extra semantic of which fields 'text' is matched against, but adds nothing for 'limit' beyond what the schema already states.
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 names a specific verb (find) and resource (codes) and pins down the matching scope: name, prefixes, area wording and attributes. That is more precise than 'search zones', but it never names or contrasts itself with siblings like cq_zones_lookup or cq_zones_codes_for, leaving the agent to infer the search-vs-lookup boundary.
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?
Use is only implied by the verb 'Find'; there is no explicit when-to-use or when-not-to-use guidance and no routing to the alternative tools in the sibling list. The 'every word' clause does at least signal AND-style querying rather than exact-code retrieval, which nudges it above a bare 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.