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

The annotations already declare this as a safe, read-only, idempotent, non-destructive operation. The description adds useful behavioral context by explaining that it returns the running PyPI version and the QRZ XML/Logbook API contract in use, which supports drift detection beyond what annotations provide.

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 front-loaded with the core purpose, followed by return details and then the operational use case. All three sentences earn their place and there is no redundant or filler text.

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?

For a zero-parameter, read-only version tool with rich annotations and an output schema, the description provides everything an agent needs: what version data is returned and why it matters. No additional authentication, pagination, or side-effect details are necessary for this tool.

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 has zero parameters, so the baseline is 4. The description correctly does not invent parameter semantics, and the empty schema is sufficient for a no-argument version-info 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: it gets the qrz-mcp service version and upstream QRZ API version. It also explicitly states the two returned values, service_version and spec_version, making the tool's output distinguishable from all QRZ data lookup 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?

It gives a clear usage context: confirm fleet alignment across MCP deployments by comparing service_version and spec_version across servers to detect drift. It does not name when not to use the tool or alternatives, but no sibling appears relevant for version comparison, so the guidance is clear without exclusions.

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral facts beyond that: it transparently paginates internally, it is rate-limited to avoid API bans, and the return value is a .adi file body rather than structured records. The one omission is whether filtering narrows the export or whether the whole logbook always comes back.

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?

Three short sentences, front-loaded with what the tool returns, followed by the actionable instruction and then the behavioral caveats. No boilerplate and every sentence carries information the agent needs.

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 values need not be spelled out, and all five parameters are documented in schema. What remains missing is the sibling differentiation against qrz_logbook_fetch and any note on how filters affect the exported content, which matters for a tool that otherwise implies an unfiltered full dump.

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 band, mode, start_date and end_date each documented inline, so the baseline of 3 applies. The description contributes nothing about the parameters and in fact calls the result a 'complete' logbook, without clarifying how band/mode/date filters interact with that completeness.

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 and resource: 'Download your complete QRZ logbook as raw ADIF text,' which tells an agent this yields raw file content rather than parsed records. It does not explicitly contrast with the sibling qrz_logbook_fetch, so the agent must infer the difference between a full raw export and a fetch call.

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?

'save to disk for import into your logger' implies the intended downstream use, which nudges toward this tool when a portable file is needed. However, it never names an alternative or states when not to use it, and the presence of qrz_logbook_fetch and qrz_logbook_status in the sibling list makes the choice ambiguous.

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 and openWorldHint, so the safety profile is covered by structured data. The description adds nothing beyond that — no note on failure for unknown callsigns, no indication that resolution may hit the QRZ network, no coverage of the persona requirement.

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 padding; the resource and both input forms come through immediately.

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 and both parameters are fully documented, so the minimal description is almost sufficient to invoke the tool. What is missing is positioning relative to qrz_lookup and any failure-mode context, which matters for an agent choosing among five QRZ siblings.

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 schema itself gives the format for both accepted query forms (callsign example VP8PJ, code example 291). The description restates that duality but contributes no additional semantics such as case sensitivity or prefix handling.

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 ('Resolve') and resource ('DXCC entity') plus the accepted input forms, which clearly distinguishes it from a generic callsign lookup like qrz_lookup. It stops short of explicitly naming that sibling, so an agent must infer the split.

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 purpose implies when to use it (you have a callsign or a numeric DXCC code and need the entity), but there is no explicit when/when-not guidance and no mention of the closest alternative, qrz_lookup.

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?

With annotations already covering readOnly/idempotent/non-destructive, the description still adds a non-obvious trait that would otherwise cause silently wrong answers: QRZ returns oldest first, so the default limit keeps the OLDEST matches, and it transparently paginates. It does not mention rate limits or auth requirements, keeping it short of a 5.

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?

Three short sentences, front-loaded with the purpose, then the two behaviors most likely to trip up an agent. Every sentence carries information that changes how the tool is called.

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?

Output shape is covered by the output schema, and the description handles pagination, ordering, and limit semantics for a 10-parameter tool. Filter composition (AND vs OR) and persona resolution failure modes remain undocumented, a minor but real gap.

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 the baseline is 3, but the description adds meaning beyond the schema: the interaction between limit and newest_first determines WHICH records are kept, not just how many. It adds nothing about how band/mode/dxcc/callsign/date filters combine, so it is not fully additive.

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 and resource ('Query QSOs from a QRZ logbook') plus the fact that filters are optional, which is enough to distinguish it from qrz_logbook_status and qrz_download. It never names a sibling explicitly, so the differentiation is inferred rather than stated.

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?

Gives a concrete usage scenario ('my last 10 contacts' is limit=10 with newest_first=true), which tells the agent how to satisfy a common intent. It does not say when to prefer qrz_download or qrz_lookup over this tool, so context is clear but exclusions are absent.

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, openWorldHint and destructiveHint=false, so safety and network behavior are covered by structured data. The description adds only the output shape in prose (a summary of counts and a date range), which the output schema likely covers anyway; no rate-limit, auth, or error behavior is mentioned.

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 the resource first and the returned metrics in parentheses. Zero filler, nothing to trim.

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 and annotations cover the safety profile, so the description needn't explain return values or side effects. What it plausibly lacks is a pointer to the sibling that returns actual QSO records, but for a one-parameter status call it is close to complete.

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?

With one parameter at 100% schema description coverage, the schema fully documents `persona` as a configured persona name. The description adds nothing about how the persona scopes the queried logbook, 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?

Specific verb + resource ("Get QRZ logbook statistics") with an inline enumeration of the metrics returned (QSO count, DXCC total, date range). It is distinguishable in practice from qrz_logbook_fetch, but the description never names that sibling, so the differentiation is inferred rather than stated.

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 word "statistics" – an agent can guess this is the read-only summary call versus qrz_logbook_fetch for actual records. There is no explicit when-to-use, when-not-to-use, or named alternative among the five sibling tools, so no routing guidance is provided.

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, open-world, non-destructive behavior, so the safety profile is covered. The description adds genuine context beyond that: the external service dependency and the subscription gate that can limit returned fields, which an agent needs to interpret thin responses. It doesn't detail rate limits or error behavior, keeping it short of a 5.

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 tight sentences: the action and returned fields come first, the subscription caveat second. The field enumeration slightly duplicates what the output schema already conveys, but it still aids quick scanning.

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 values needn't be explained, annotations cover the safety profile, and both parameters are fully documented in-schema. The description's remaining job — external dependency and subscription caveat — is handled, leaving nothing an agent needs 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 coverage is 100%, with both 'persona' and 'callsign' documented in-schema including an example callsign. The description adds no further parameter meaning, so the baseline 3 is 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?

States a specific verb and resource ('Look up a callsign on QRZ.com') and enumerates the returned fields (name, grid, DXCC, license class, QSL info, image), so an agent knows exactly what this returns. It does not explicitly contrast itself with siblings like qrz_dxcc or qrz_logbook_fetch, but the resource is distinct enough to infer separation.

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 an important prerequisite — a paid QRZ XML Subscription is required for full fields — which tells the agent when results may be degraded. However, it never says when to prefer this over sibling tools (qrz_dxcc, qrz_logbook_fetch) or what happens without a subscription beyond 'full fields' being unavailable.

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