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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds real substance by naming the two values returned (PyPI version and schema revision) and the drift-detection workflow they enable. It adds value but doesn't go beyond what the output schema already carries.

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?

Front-loaded with the core purpose in the first sentence, followed by the return contents and then the use case. The trailing 'without going outside the MCP protocol' clause is slightly padded but does convey a real constraint.

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 zero params, rich annotations and an output schema, the description covers everything an agent needs: what it returns, what the values mean, and why it would call it. Nothing material is left to inference.

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 takes zero parameters, so the baseline is 4 and no parameter explanation is needed. The description correctly doesn't waste space on inputs.

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 pair: retrieves the running PyPI version of wspr-mcp plus the wspr.live ClickHouse schema revision. That is clearly distinct from the sibling wspr_* analytics tools, which all query spot data.

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?

Explicitly says to use it 'to confirm fleet alignment across MCP deployments' and to compare service_version and spec_version across servers to detect drift. There's no alternative tool it could be confused with, so the missing explicit exclusion costs little.

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 non-destructive, so the safety profile is fully covered. The description adds real value beyond that by naming the exact aggregated metrics and the recency semantics ('open right now'), which tells the agent the output is a current snapshot. It stops short of noting aggregation or rate-limit behavior.

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 returned metrics, then the interpretive use case. No filler and no repetition of schema or annotation data.

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 schema exists, so return values needn't be enumerated in detail; annotations cover safety. The description is nonetheless complete enough to know what the tool returns and when to reach for it. A minor gap: it doesn't connect the 'open right now' framing to the configurable hours window.

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%: the single 'hours' parameter is documented in the schema with its range and default. The description mentions 'right now' but does not add syntax or guidance about widening the window. Baseline 3 is appropriate since the schema does the heavy lifting.

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 and resource: 'Get per-band WSPR activity summary,' and it enumerates the metrics returned (spot counts, TX/RX station counts, distances, SNR). It distinguishes itself implicitly from siblings like wspr_top_beacons or wspr_snr_trend by being the aggregate per-band view, though it doesn't name an alternative.

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?

Clear positive guidance: 'The best indicator of which bands are open right now' tells the agent exactly what question this tool answers. There is no explicit when-not-to-use or named alternative (e.g., 'for a single band, use wspr_propagation'), so it falls short of a 5.

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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context by stating that the tool returns summary statistics plus recent spots and that grid granularity controls geographic scope.

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 short and front-loaded with the tool's purpose in the first sentence. The remaining sentences efficiently explain the return content and grid-size behavior, though the phrase 'in or out of' is slightly ambiguous and could be clearer.

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?

Given an output schema exists and the input schema has full parameter descriptions, the description does not need to explain return values in detail. It is complete enough for an agent to understand the query's geographic scope and return content, with only minor room to clarify tool selection versus 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 all four parameters are already documented in the schema. The description reinforces the grid 2-character vs 4-character distinction but does not add syntax or meaning for band, hours, or limit 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.

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

The description states a specific verb and resource — 'Get all WSPR activity in or out of a Maidenhead grid square' — and clarifies that it returns summary stats and recent spots. It does not explicitly distinguish itself from siblings like wspr_band_activity or wspr_spots, so an agent must 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?

It gives useful parameter-level guidance: use a 2-character grid for a wide area and a 4-character grid for a specific region. However, it does not say when to choose this tool over siblings such as wspr_band_activity or wspr_spots, nor does it state any 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 safety is covered. The description adds genuine domain context — that WSPR's precise timing/low power makes long paths meaningful evidence of band openness — which helps interpretation. It says nothing about ordering (presumably descending distance), limits, or empty-result behavior, so it adds only modest value.

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 operative instruction is front-loaded in the first sentence, and the second sentence is short interpretive context rather than repetition. The wording is slightly padded ('gold standard for detecting marginal propagation') but it earns its place as domain rationale.

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 unnecessary, and annotations cover the read-only profile. For a simple four-optional-parameter query tool the description is nearly sufficient; the only real gap is disambiguation from sibling propagation tools.

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, hours, limit and min_distance all documented in-schema including ranges and an example (15000 km near-antipodal). The description adds no meaning beyond that; at best 'given time window' loosely echoes the hours parameter. Baseline 3 applies when the schema carries the full parameter burden.

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 — retrieve the longest WSPR paths within a time window — which is immediately understandable. However, it does not distinguish this from the semantically adjacent sibling wspr_propagation (or wspr_top_beacons/wspr_top_spotters), so an agent must guess which 'path/ranking' query it wants.

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?

'Get the longest WSPR paths in the given time window' plus 'Long paths here prove the band is open' implies the use case (assessing marginal band openings), but usage is only implied. There is no explicit when-to-use, when-not-to-use, or pointer to a sibling such as wspr_propagation for a different propagation view.

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 cover read-only, idempotent, open-world, non-destructive semantics, so the bar is lower. The description still adds real behavioral value by disclosing that both directions are searched automatically (saving a redundant reversed call) and by summarizing the returned aggregation (spot counts, SNR statistics, hours of opening). It does not mention rate limits or data-recency caveats.

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?

Four short sentences, front-loaded with the core action and scope, then output contents, then input flexibility, then the bidirectional behavior. No filler; everything earns its place.

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 no exposition, and annotations fully carry the safety profile. The description is complete for correct invocation, with the only gap being selection guidance relative to the eight sibling tools.

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%, including the callsign-or-grid flexibility for tx and rx, so the schema carries the parameter burden. The description re-states that flexibility and adds the directional-searching nuance, but contributes little beyond the structured fields — 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?

States a specific verb ('Get'), a specific resource ('WSPR-derived propagation'), and the exact scope ('between two locations'), plus what the result contains (bands open, spot counts, SNR, hours of opening). It is distinguishable from siblings like wspr_grid_activity by being point-to-point, though no sibling is named 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 implied — you call it when you want band-opening data between two endpoints — and it explains that callsigns, grids, or a mix are accepted and both directions are searched. However, it never says when to prefer wspr_band_activity, wspr_grid_activity, or wspr_longest_paths instead, and gives no exclusions or preconditions.

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 tool. Beyond that, the description adds useful behavioral context by disclosing that the output is an hourly SNR bucket series for a specific path, which helps the agent understand result granularity.

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 short and front-loaded with the core action and resource. There is minor repetition of 'over time' and 'specific path,' but every sentence contributes useful information and nothing is bloated.

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 read-only query tool with complete parameter descriptions, rich annotations, and an output schema, the description provides enough context to understand what is returned and when it is useful. No critical calling information is 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 description coverage is 100%, so the tx, rx, band, and hours parameters are already fully documented in the schema. The description implies path endpoints and time variation but does not add syntax or filtering details beyond what the schema provides, making the baseline score 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?

The description states a specific verb and resource: 'Get SNR trend over time for a specific WSPR path,' and clarifies that it shows hourly SNR buckets between two endpoints. It is clear what the tool does, but it does not explicitly distinguish itself from the related sibling wspr_propagation.

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 a use case: seeing when a band opens and closes on a specific path and how signal strength varies over time. However, it does not say when to choose this tool over alternatives such as wspr_propagation, nor does it state any exclusions or preconditions.

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, non-destructive, and openWorldHint, so safety is covered. The description adds genuinely useful interpretation — that each spot is a 2-minute integration and represents an actual propagation path — but says nothing about data freshness ('recent' is unquantified), result ordering, or pagination beyond the schema's limit.

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 with the core action front-loaded and zero filler. The two domain sentences earn their place by explaining what a spot means, though they could have been spent on sibling differentiation instead.

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 8 optional params, 100% schema coverage, an output schema, and full annotations, the structured data carries most of the load. The remaining gap is selection: in a family of eight WSPR tools, the description never tells the agent why to pick this one for raw spot retrieval.

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 every filter (band, grid, hours, limit, SNR bounds, callsign, distance) is already documented with examples and ranges. The description adds no parameter-level meaning, 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?

States a specific verb and resource ('Get recent WSPR spots'), so the agent knows it retrieves spot records. However, it never distinguishes this from the seven sibling wspr_* tools (wspr_band_activity, wspr_propagation, wspr_longest_paths), which likely also return spot-derived data — an agent must open schemas to choose.

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 provides only domain background ('beacons transmit every 2 minutes', 'proves a propagation path exists') and no when-to-use guidance. It never says when to prefer this raw spot list over wspr_band_activity, wspr_propagation, or wspr_top_beacons, nor does it state prerequisites or rate limits.

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 readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond that — nothing about result ordering guarantees, tie-breaking, or what empty results mean — so it earns baseline credit only.

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 with the core purpose front-loaded and no wasted clauses. 'Most active or most far-reaching' mildly restates the first sentence's ranking criteria, but the overall length is appropriate.

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 fully documented four-parameter schema, an output schema present, and annotations carrying the safety profile, the description covers enough for an agent to call this correctly. The only gap is lack of guidance versus the closely related wspr_top_spotters and wspr_longest_paths tools.

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 band, hours, limit, and sort_by are all documented in the schema already. The phrase 'ranked by spot count or max distance' loosely mirrors the sort_by enum values but adds no syntax or semantics beyond what the schema 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 gives a specific verb and resource ('Get top WSPR transmitters ranked by spot count or max distance') and implicitly separates itself from wspr_top_spotters by focusing on beacon operators/transmitters rather than listeners. It doesn't name the sibling explicitly, so the distinction 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?

'Useful for finding who's putting out a big signal on a band' implies a use case but gives no when-not conditions and never references the sibling tools (wspr_top_spotters, wspr_longest_paths) that overlap with this ranking behavior. Usage is suggested, not routed.

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 and destructiveHint=false, so the safety profile is covered. The description adds that results are a ranking (implying ordered output) but says nothing about empty results, ordering stability, or the openWorld data source.

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 core action. The second sentence largely restates the first ('most prolific or most sensitive' vs 'spot count or max distance'), making it slightly redundant.

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 full output schema, complete parameter descriptions, and rich annotations, the definition covers what an agent needs to invoke it. The only gap is the missing contrast with wspr_top_beacons, a nearly adjacent sibling with the same 'top' shape.

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 all four parameters are documented with defaults and ranges, so the schema does the heavy lifting. The description's phrase 'ranked by spot count or max distance' loosely mirrors sort_by but adds no syntax or edge-case detail beyond it.

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 first sentence gives a specific verb (rank) and resource (WSPR receivers) plus the two ranking criteria, so purpose is unambiguous. It implicitly distinguishes from siblings like wspr_top_beacons by naming receivers, but never explicitly contrasts the two.

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 final sentence offers a use case ('finding good receivers to monitor for propagation'), which implies when to call it. However, no alternative is named and no when-not guidance is given, so the agent must infer whether wspr_top_beacons or wspr_band_activity is the better fit.

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