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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description adds context on top: it returns the running PyPI version plus the POTA API revision in use, and can be compared across servers. It does not discuss failure modes, but for a zero-parameter version readout little else is needed.

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 statement, then the rationale. Mostly economical, though "detect drift without going outside the MCP protocol" is slightly padded relative to the informational content.

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 parameters, rich annotations, and an output schema present, the description covers what the tool returns and why an agent would call it. Nothing needed for correct invocation 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?

The tool takes no parameters, so the baseline is 4. The description names the response fields (service_version, spec_version), which is a small bonus beyond the empty schema without being parameter semantics per se.

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 pota-mcp service version and upstream spec version") and immediately enumerates the two returned fields, service_version and spec_version. This is clearly distinguishable from all siblings, which are POTA park/user data tools.

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 this to confirm fleet alignment across MCP deployments" gives an explicit when-to-use condition (cross-server drift detection). No exclusions or named alternatives are given, but no sibling plausibly substitutes for this tool, so the gap is minor.

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 the safety profile is fully covered without help from the description. The description adds only the word 'all', which hints at potentially unbounded result sets but never states pagination, result size, or truncation behavior — useful context that is missing.

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?

One sentence, front-loaded with the verb and resource, ending with the scope. Nothing redundant and nothing buried.

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 shape need not be explained, and the single required parameter is fully documented in the schema. The description is nearly complete for this simple tool; the only real gap is not distinguishing region-based listing from the proximity-based sibling.

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 own description gives example codes (US-ID, CA-ON, G). The description adds a small amount by confirming country-level codes are valid and not just state/province, but it provides no format rules, delimiters, or case sensitivity. Baseline 3 applies when the schema does the work.

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 (List), resource (POTA parks), and scope (state, province, or country), so an agent knows exactly what it returns. It does not, however, differentiate itself from the sibling pota_nearby_parks, which is the obvious alternative when the user's criterion is proximity rather than a named region.

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: call this when you have a location code and want the parks in that region. There is no explicit when-not guidance and no mention of pota_nearby_parks for geographic-radius searches, leaving the agent to infer which of the two location-based tools to pick.

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 behavior, so the bar is lower. The description still adds genuinely useful mechanics: it fetches all parks in the location first and then filters by distance, which signals a potentially expensive fetch-then-filter operation rather than a server-side spatial query.

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 lines with the core action front-loaded and zero filler. Slight redundancy between the first and second sentences ('near a geographic point' vs. 'filters by distance'), but the second earns its place by explaining the mechanism.

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?

Five parameters, full schema coverage, an output schema, and complete annotations mean the description only needs to establish purpose and use case, which it does. The one remaining gap is not clarifying how this differs from the nearest sibling, pota_location_parks.

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 every parameter carries a description with examples, defaults, and maxima, so the schema does all the work. The description adds no parameter-level meaning beyond what is already documented.

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 with geographic scope: 'Find POTA parks near a geographic point.' The addition that it fetches all parks in a location then filters by distance distinguishes it from siblings like pota_location_parks, though the differentiation is implicit 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?

Offers one concrete use case ('finding 2-fer candidates near an activation site'), which implies the when-to-use context. However, it names no alternatives and gives no exclusions, so an agent must infer how this differs from pota_location_parks or pota_rare_parks_near.

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 only the ordering guarantee ('most recent first'), which is genuinely useful but stops short of noting whether inactive parks return an empty list, how stale the data is, or what an 'activation' record contains.

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 with no filler; the core action and sort order come first and the intent questions follow. Nothing could be removed 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 present, return values need not be described, and annotations cover safety, so the definition is essentially sufficient. The only residual gap is what an empty result or a never-activated park looks like, which an agent may want before reporting to a user.

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 'reference' (example US-0062) and 'count' (default 10, max 50) fully documented in the schema. The description adds no parameter-level meaning beyond that, 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 ('List recent activations of a POTA park') plus the ordering ('most recent first'), which is far more precise than the bare name. It implicitly separates itself from pota_park_info (park metadata) and pota_spots (live spots), but never names those siblings 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?

The two framing questions ('when was this park last activated?' and 'is it often on the air?') give a clear trigger for calling the tool. There is no explicit when-not guidance or pointer to pota_park_info / pota_park_stats for the related questions an agent might confuse with this one.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered. The description adds nothing beyond that — it does not say whether unknown reference codes error or return empty, whether results are cached, or what the 'detailed' fields comprise.

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?

One front-loaded sentence with zero filler. It is efficient but so terse that it borders on under-specification relative to the six park-related siblings.

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 explanation) and the lone parameter is fully documented, leaving the tool callable as described. What is missing is disambiguation from pota_park_stats and pota_park_activations, which is the main risk for an agent choosing among these 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% and the single parameter already documents the reference format with three examples (US-0001, CA-5580, G-0001). The description adds no meaning 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?

A specific verb (Get) plus resource (detailed park information) keyed by POTA reference code, so the agent knows exactly what comes back in kind. However, it never distinguishes 'park information' from the closely named siblings pota_park_stats, pota_park_activations, and pota_park_leaderboard, which all also take a park reference.

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 when-to-use statement, no prerequisites, and no named alternatives among the several park-scoped siblings. The only implied guidance is that a reference code is required, which the schema already makes mandatory.

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, openWorld, so the safety profile is covered. The description adds genuinely new context: there are exactly three boards and each row contains only a callsign and a count, which tells the agent not to expect dates, modes, or per-QSO detail.

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 board breakdown, then the row shape. No filler and nothing buried.

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?

A simple read tool with an output schema, full annotation coverage, and 100% parameter documentation; the description supplies the one thing structured fields don't convey — the three-board structure and minimal row fields. Nothing an agent needs to call it correctly 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%, with both reference and limit documented in the schema (including the max 25 and the note that POTA publishes only five per board). The description adds nothing about parameters, 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 resource (POTA park leaderboard) and enumerates exactly what it returns: three boards keyed by activation count, activator QSOs, and hunter QSOs, with rows of callsign+count only. That row-shape statement cleanly separates it from raw-list siblings like pota_park_activations or pota_park_stats.

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 content (ask for rankings of a park), but the description never states when to prefer this over pota_park_stats or pota_park_activations, nor any prerequisite such as needing a valid park reference first. Adequate but with a clear gap.

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 behavior, so the safety profile is covered. The description adds that aggregation over activations and QSOs is what's returned, but says nothing about whether the response is a lifetime total, a per-year breakdown, or how caching/freshness works.

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?

One tight sentence with no filler and the resource front-loaded. It is efficient but so terse that the scope of 'counts' is left ambiguous.

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 described. But in a dense sibling cluster of park-scoped tools, the description should have stated what set this apart from pota_park_info and pota_park_activations; that routing 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 coverage is 100% and the sole parameter is documented with a concrete example format (US-0001), so the schema carries the load. The description adds nothing about reference semantics, which is acceptable at baseline 3.

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 activation and QSO counts for a POTA park'), which is clearly a statistics/aggregate operation, distinct from map-listing tools like pota_spots. However, it never names or contrasts the closest siblings (pota_park_info, pota_park_activations), so the differentiation is left to inference.

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 versus pota_park_info (park metadata) or pota_park_activations (raw activations). The agent must guess whether counts come from this tool or can be derived from the activations list.

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 safety (readOnly, idempotent, non-destructive, openWorld) and an output schema exists, so the description's added value is the result ordering: 'least activated first, nearest first among equals.' That is genuinely useful behavior not expressed in structured fields. It says nothing about limits or result size control beyond what the schema states.

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, followed by the user-facing question and the sort order. The middle question sentence is slightly redundant with the first but earns its place by conveying intent.

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 and 100% parameter coverage, the description only needs to convey purpose, ranking, and selection context — all present. It stops short of noting the required location/coordinate combination or the cap on results behavior, but those live in the schema.

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 five parameters (limit, radius_km, location, latitude, longitude) are already documented with defaults and maxima. The description adds no parameter-level detail, 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 ('Find the least-activated POTA parks near a point') plus the ranking rule, which distinguishes it from the sibling pota_nearby_parks. An agent can select it without opening either 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 two concrete use cases an activator/hunter would recognize ('which parks near me have never, or rarely, been activated?'), which is clear conditional context. It does not name the alternative (pota_nearby_parks) or say when NOT to use this, 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 cover read-only, idempotent and open-world behavior, so the bar is lower; the description still adds the non-obvious AND-combination rule and the default 'return whole schedule' behavior. The trailing 'as before' adds no information for an agent without prior context.

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 with the core purpose front-loaded and no wasted preamble. The parenthetical 'as before' is the only baggy fragment.

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 all four parameters are fully documented, so the description needn't explain returns. It supplies the filter-combination and empty-filter default, leaving only result ordering and typical result size unstated.

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; the description earns one more by documenting cross-parameter semantics (filters AND together) that the per-field schema descriptions do not express.

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 upcoming scheduled POTA activations'), which is clearly distinct from stats/leaderboard siblings. It does not explicitly distinguish itself from the closest sibling, pota_spots (reports current activations), leaving that contrast only in a parameter description.

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 explains the filtering model ('all optional, combine with AND, omit for everything'), which implies usage. But it never says when to prefer this over pota_spots or pota_park_activations, so routing guidance is left implicit.

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 behavior, so the safety profile is covered. The description adds the important nuance that results are a live, currently-changing feed, which usefully signals that repeated calls may return different spots despite idempotentHint. It does not mention freshness latency, caching, or rate limits.

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, purpose front-loaded, with return-shape and optionality following in order of decision relevance. No filler or redundancy.

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 need no explanation, and annotations carry the safety profile. With fully documented parameters, the description covers what an agent needs to call it correctly; only cross-tool routing guidance 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%; each of band, mode, program, and location already has an example and an empty-string default documented. The description only contributes the general 'all filters optional' behavior, which the schema's defaults and zero required params already convey. 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 current POTA activator spots') and the second sentence clarifies the payload ('live spot feed with park details, grid squares, and coordinates'). It implicitly separates itself from pota_scheduled by emphasizing 'current'/'live', but never names that or any other sibling 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?

The line 'All filters are optional — omit to get all active spots' tells the agent how to call it with no arguments, which is genuinely useful. But there is no guidance on when to prefer this over pota_scheduled (upcoming activations) or pota_park_activations (per-park history), leaving routing to inference.

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 this as a read-only, idempotent, non-destructive, open-world lookup. The description adds only that the result covers activator and hunter statistics, with no extra behavioral detail such as data freshness or error behavior; the output schema likely covers return structure.

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 definition is a single front-loaded sentence with no wasted words. It states the action and scope 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?

For a one-parameter read-only lookup with rich annotations, full schema coverage, and an output schema, the description is nearly sufficient to call the tool correctly. It could be stronger only by briefly clarifying when to prefer it over sibling statistics 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 the callsign parameter is already well documented with examples. The description mentions the callsign context but adds no format, validation, or lookup semantics beyond the schema.

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 POTA activator and hunter statistics for a callsign. This clearly distinguishes it from park-oriented siblings such as pota_park_stats and pota_park_activations, though it does not explicitly name alternatives.

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 'for a callsign,' but the description gives no explicit when-to-use guidance, prerequisites, or comparisons with sibling tools. An agent can infer the context but is not routed between this and related lookups.

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