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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new context: it reports the *running* PyPI version rather than the latest published one, and it exposes the API contract in use, which explains why cross-server comparison is meaningful. It stops short of saying whether the lookup is cached or whether it ever hits the network for the upstream spec.

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 sentences, front-loaded with what is returned before the rationale. The trailing clause 'without going outside the MCP protocol' is slightly promotional but does encode the practical point that no external call or dashboard is needed.

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 and no parameters, the description need not enumerate return fields, and it still names the two key ones. For a trivial introspection tool this is essentially complete; only the freshness/caching semantics of the reported versions are left unspecified.

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?

Zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. It wisely spends no words on arguments and instead describes the returned values.

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 two precise resources: the hamqth-mcp service version and the upstream HamQTH API contract version, naming the actual fields (service_version, spec_version). No sibling tool in the list deals with versioning or introspection, so an agent can rule out the hamqth_lookup/dxcc/bio family without opening a schema.

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 an explicit use case — confirming fleet alignment and detecting version drift across deployments by comparing service_version and spec_version. It lacks an explicit 'do not use this for X' exclusion, but there is no plausible competing tool for this purpose, so the guidance is functionally complete.

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?

The annotations already declare read-only, idempotent, open-world, and non-destructive behavior, so the safety profile is covered. The description adds useful context by identifying the three activity sources and recency, but "recent" is vague and no time window or aggregation behavior is described.

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 a single front-loaded sentence with no wasted words. It states the tool's action, sources, and scope efficiently.

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 complete input schema, an output schema, and rich annotations, the description is largely sufficient for calling the tool. A clearer definition of "recent" and a brief distinction from the source-specific sibling tools would make it fully 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?

Schema description coverage is 100%, so both parameters are documented in the input schema. The description references the callsign parameter but adds no meaning beyond the schema, which is acceptable given full coverage.

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 ("Get") and resource ("recent DX cluster, RBN, and logbook activity") scoped to a callsign. It names the data sources clearly, but does not explicitly distinguish the tool from overlapping siblings such as hamqth_dx_spots or hamqth_rbn.

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 broadly implies when the tool is useful by specifying recent activity for a callsign, but gives no explicit guidance on when to use it instead of the more specific DX spot or RBN sibling tools. No exclusions or alternatives are mentioned.

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=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that: no mention of network dependency, HamQTH credentials/rate limits, or behavior when a callsign is unknown.

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 compact sentence with the resource front-loaded and no filler. It is efficient, though its brevity is part of why differentiation and context are missing.

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-value explanation is not needed, and the two simple string params are covered by the schema. The gap is routing context: nothing explains how this differs from hamqth_lookup or what 'persona' configuration means in practice.

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 ('persona' and 'callsign') are documented in the schema itself. The description only implies the callsign is the lookup key and says nothing about how 'persona' selection affects the request, so 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 verb ('Fetch') and resource ('operator's biography from HamQTH'), clearly readable as a read of biographical data. However, it does not differentiate from the sibling hamqth_lookup, which plausibly also returns operator information for a callsign, leaving the agent to infer the 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?

No guidance on when to use this rather than hamqth_lookup or hamqth_dxcc, and no prerequisites mentioned (e.g. that a valid persona must be configured). The agent must guess which HamQTH endpoint fits its need.

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, non-destructive and open-world, so the safety profile is fully covered elsewhere. The description adds one genuinely useful operational detail — no authentication needed — but says nothing about rate limits, failure modes for unresolvable callsigns, or result caching.

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, zero filler, and the core action is front-loaded before the operational note. Nothing could be cut without losing 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?

With an output schema, rich annotations, and a fully documented single parameter, little more is strictly required. Still, an agent choosing among seven hamqth tools gets no disambiguation here, which is the one real gap for a resolver tool that overlaps heavily with hamqth_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 coverage is 100% and the single parameter's description already gives examples for both accepted forms (callsign and ADIF entity code). The description reinforces the dual-input nature but adds no format or validation detail beyond the schema, so 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 ("Resolve") plus specific resource ("DXCC entity") with the two accepted input forms stated, so the tool's function is unambiguous. It does not distinguish itself from hamqth_lookup or hamqth_bio, which an agent will likely hesitate between when it has a callsign in hand.

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 second sentence ("Public endpoint — no authentication required") is an operational fact, not usage guidance. Nothing says when to prefer this over hamqth_lookup, or when an agent should already have an entity code versus a callsign.

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 and open-world behavior, so the safety profile is covered. The description adds useful operational context beyond that: no authentication is required and the data refreshes roughly every 15 seconds, which matters for a live feed. It does not mention 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?

Three short sentences, front-loaded with what the tool returns, followed by freshness and volume constraints. Every sentence carries information an agent would use, with 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?

An output schema exists, so return formatting need not be explained, and annotations carry the safety profile. The description covers source, auth, refresh cadence and result ceiling, which is nearly everything needed to call it correctly; only rate-limit or failure behavior is absent.

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, call and limit each documented including the client-side filtering caveat for call. The description only restates the 200-spot ceiling already present in the limit parameter, so it adds little beyond the schema; 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?

The description states a specific verb and resource ('Live DX cluster spots from HamQTH') and adds the source and auth model, so the agent knows exactly what data it returns. It does not distinguish itself from the spot-like sibling hamqth_rbn, which is the only missing differentiator.

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 supplies clear context (public, no auth, ~15s refresh) that implies when the tool is appropriate, but it never says when to prefer hamqth_rbn or another sibling, nor does it state any exclusions. Usage is inferable rather than explicit.

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?

The annotations already establish that this is a read-only, idempotent, open-world, non-destructive lookup. The description adds useful context beyond that: no subscription is required, and field availability depends on what the operator has published. It still does not mention possible failure behavior or rate limits, but with annotations covering safety it is appropriately informative.

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 three short sentences and front-loads the main action before the return-data summary and the field-availability caveat. Every sentence contributes useful information without repetition or 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?

An output schema exists and annotations cover the safety profile, so the description need not explain return values in detail. It does enough by naming the lookup target, summarizing returned fields, and noting that field availability varies, though it could more explicitly position this tool relative to the other HamQTH 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 description coverage is 100%, so both the persona and callsign parameters are already documented in the input schema, including an example callsign. The description does not add parameter-level meaning beyond what the schema provides, so the baseline score of 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?

The description states a specific verb and resource: 'Look up a callsign on HamQTH.' It also clarifies the service is free and lists the kind of data returned. However, it does not distinguish this general lookup from narrower sibling tools such as hamqth_bio or hamqth_dxcc, even though their names suggest possible overlap.

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 name and the phrase 'Look up a callsign on HamQTH,' and the free/no-subscription note is helpful context. But the description does not explicitly say when to choose this tool over alternatives like hamqth_bio, hamqth_dxcc, or hamqth_verify_qso.

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, open-world behavior, so the safety profile is covered. The description adds one useful behavioral fact – the endpoint is public and requires no auth – but says nothing about rate limits, result volume, or spot freshness (which the 'age' param hints at).

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. It is efficient, though its brevity borders on under-specification rather than pure conciseness.

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 and full annotations, the description needn't explain return values. However, for a tool with six filtering dimensions and a same-domain sibling that also returns spots, it omits routing guidance and any hint about defaults or result limits.

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 all six optional parameters are documented in the schema, including the note that 'call' is filtered client-side. The description adds no parameter meaning beyond that, so the baseline of 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 resource – Reverse Beacon Network spots – and its source (HamQTH), which distinguishes it from hamqth_dx_spots and the other siblings. It implies retrieval rather than naming a verb, so it stops short of a full 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?

There is no guidance on when to call this versus hamqth_dx_spots or hamqth_activity, and no stated preconditions. The agent must infer usage entirely from the name and source.

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, non-destructive and open-world, so the safety profile is covered. The description adds genuine context by disclosing the auth model (public, no credentials needed) and naming the SAVP protocol, but says nothing about rate limits, failure modes, or what a negative verification looks like.

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 compact sentences with the core action front-loaded and no filler. The second sentence carries real information (bilateral existence check) rather than restating the first.

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, rich annotations, and full schema coverage, the description only needs to convey purpose and calling context, which it does. Minor gap: it doesn't state what happens on a failed/negative verification or any caveats about SAVP data freshness.

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% and every parameter (mycall, hiscall, date, band) carries its own format example, so the schema does the heavy lifting. The description adds no parameter-level meaning beyond noting both parties' callsigns are involved.

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 ('Verify a QSO via HamQTH SAVP protocol') and clarifies the check is bilateral ('for both parties'). It is clearly distinguishable from the lookup/bio/spot siblings, though it never names an alternative explicitly.

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: the description notes it is 'public, no auth required', which tells the agent it can be called unconditionally. There is no explicit when-to-use vs when-not guidance or comparison to the other hamqth_* tools.

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