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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds a genuinely non-obvious behavioral trait beyond them: it is a 'lighter-weight identity attestation that succeeds even when N1MM isn't broadcasting,' which tells the agent this call is reliable in a degraded upstream state. It does not describe cost/latency or caching, so it stops short of 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?

Front-loaded with the verb and resource, then usage, then the sibling disambiguation — a sensible order with no wasted preamble. Slightly padded by 'without going outside the MCP protocol' and a parenthetical listing diagnostics' internals, which is context for a different tool.

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-argument read-only tool with an output schema, the description covers purpose, the two returned version fields, the intended cross-server comparison workflow, and the degraded-upstream behavior. Nothing an agent needs to decide whether and how to call it 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?

Zero parameters, which sets the baseline at 4 per the rubric. The description additionally names the two values the caller will compare (service_version, spec_version), reinforcing what the empty-arg call is for.

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) and resource (service version + upstream UDP contract version), and names the concrete return fields service_version and spec_version. It explicitly separates itself from n1mm_diagnostics, so an agent can pick between them 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 an explicit use case (confirm fleet alignment, compare versions across servers to detect drift) and an explicit exclusions clause: 'n1mm_diagnostics remains the canonical health probe (heartbeat, parse errors, memory).' The when-to-use and when-not-to-use are both stated with the alternative named.

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 description adds genuinely new traits: TTL eviction of spots (ephemeral data, results change between calls) and 'one snapshot' semantics. It omits pagination or size limits, which is a minor gap given the annotation coverage.

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 resource identity front-loaded and the returned contents immediately after. 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?

With an output schema present, the description only needs to convey what the tool is and how it behaves; it covers snapshot semantics and TTL eviction well. The remaining gap is routing versus the multipliers 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 description coverage is 100% and all five filter parameters are documented there. The description only implies that band/mode/callsign filters shape the returned spot set, adding no syntax or interaction detail 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?

States a specific resource (live bandmap) and enumerates its contents: spots, mult targets, activity summary. However, it does not distinguish this from the sibling n1mm_multipliers, despite overlapping output ('unworked multipliers'), so an agent cannot fully separate them from the description alone.

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 word 'Live' implies a real-time usage context, but there is no explicit guidance on when to use this instead of n1mm_multipliers, n1mm_pileup, or n1mm_contacts. No prerequisites or exclusions are stated.

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 this as a read-only, idempotent, non-destructive open-world query. The description only restates the title's concepts ('timing, off-time, and pacing') and adds no behavioral context such as how min_gap_minutes affects off-time calculation, whether results are cached, or what the clock view includes beyond the obvious.

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 short phrase and front-loaded, but it is under-specified rather than genuinely concise. Every word earns its place in the sense that there are no wasted sentences, but the phrase carries too little information for a five-parameter tool.

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?

Although an output schema and annotations exist, the description does not explain the relationship to sibling tools, how to use the pacing targets, or what practical view the clock returns. For a tool with optional configuration parameters and several related status tools, this leaves meaningful gaps.

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 are documented in the schema itself, including target_qsos, target_score, duration_hours, station_name, and min_gap_minutes. The description adds no parameter meaning beyond what the schema provides; 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?

The description names the resource (contest clock) and three concepts (timing, off-time, pacing), which gives a rough idea of what the tool shows. However, it stops short of a specific verb or outcome, and it does not distinguish this from siblings like n1mm_current_state or n1mm_performance that likely overlap with timing/status views.

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 about when to use this clock versus n1mm_current_state, n1mm_performance, or other status-oriented siblings. The phrase 'in one view' hints at a consolidated display but does not state a selection condition or exclusion.

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 openWorld, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond that: the return is a composite snapshot combining last QSO, filtered QSOs, edits and deletes, which prevents misreading 'edits and deletes' as mutations. It says nothing about volume limits or snapshot consistency, though, so it is additive but not rich.

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, front-loaded with the resource label before the detail. There is mild redundancy between 'recent contacts, edits, and deletes' and the expansion that follows, but nothing is wasted enough to hurt.

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 six parameters are documented, so the description needn't explain return shapes. What remains missing for correct selection is routing guidance against the many similarly named n1mm siblings — a meaningful gap for a tool in a crowded cluster.

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, count, since, call_pattern and station_name each documented including the count default and 100 maximum. The description only alludes to filtering in general terms and adds no syntax or interaction semantics (e.g. how since combines with count), 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?

The description names a specific resource (the QSO log) and enumerates exactly what is returned: the last QSO, filtered recent QSOs, recent edits, and recent deletes. It is clear what the tool does, but it never distinguishes itself from adjacent siblings such as n1mm_current_state, which an agent could reasonably assume also surfaces the last QSO.

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 statement of when to reach for this tool versus the other eleven n1mm_* tools, and no exclusions or prerequisites. The only hint is the word 'filtered', which implies the schema filters exist, but an agent must infer the selection criteria entirely on its own.

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, and non-destructive behavior, so the bar is lower. The description adds useful behavioral context by listing what the snapshot contains and noting that Radio 2 state is included only for SO2R.

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 two tight sentences, front-loaded with the core snapshot purpose and followed by return details and session-start guidance. Every sentence contributes materially.

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 the description does not need to fully document return values, and the annotations cover safety behavior. The main remaining gap is that the optional station_name parameter is not explained.

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 0%, and the only parameter, station_name, is never mentioned in the description. The phrase 'station snapshot' weakly implies station scoping, but it does not explain how station_name selects or affects the returned state.

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 framing: it returns a complete station snapshot covering connection, contest, operator, and radios. This clearly distinguishes it from narrower siblings such as n1mm_bandmap, n1mm_clock, or n1mm_so2r.

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 explicitly says this is the first tool any AI session should call, which gives strong usage context. It does not name when to use alternatives instead, but the 'first call' guidance is clear enough for a session-start snapshot tool.

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, open-world, so safety is covered. The description adds the diagnostic-triage framing, but says nothing about cost, whether it touches the network, or scoping behavior. Since an output schema exists, the return shape need not be 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?

Short, front-loaded, and the most actionable line (call this first when something breaks) is emphasized early. "Essential for production debugging" is slightly redundant with the following sentence but does not waste much space.

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?

Annotations plus an output schema carry the safety and return-value burden, so the description only needs to cover purpose and scoping. Purpose is covered; the meaning of the sole optional parameter is left entirely unaddressed, which is a real gap for a scoped diagnostics call.

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 0% and the single parameter is an undescribed nullable string; the description never mentions station_name at all. With low coverage the description is expected to compensate, and it does not — an agent cannot tell whether omitting it means 'all stations' or 'default station'.

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 concrete resource plus the specific facets covered (connection, parse errors, memory), which distinguishes it from siblings like n1mm_network and n1mm_current_state. It is not a forced verb phrase, but the scope is unambiguous.

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?

"First tool to call when something goes wrong during a contest" gives an explicit trigger condition, which is genuinely useful triage routing. It does not, however, say how it differs from n1mm_network, the most plausible alternative when the symptom is connectivity.

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 behavior, so the description need not restate safety. It adds useful context beyond annotations: the trigger event, the inclusion of current band/mode from RadioInfo, and the lookup_age_ms >30000 staleness cutoff.

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 purpose, then the trigger, return context, and staleness rule. Every sentence contributes operational information with no waste.

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?

The output schema and rich annotations reduce the description's burden, and it covers the trigger, return context, and staleness handling well. However, the only input parameter remains unexplained despite 0% schema description coverage, leaving a real gap for callers that need station_name.

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 0% and the description never mentions the sole station_name parameter. Because it adds no meaning for that parameter—and may even make the agent think only callsign context matters—it does not compensate for the low schema 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 states a specific action and context: a pre-log callsign lookup that fires on a callsign plus spacebar in N1MM. It is clearly distinct in practice from siblings like n1mm_current_state or n1mm_contacts, but it does not explicitly name or contrast those 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?

It gives a clear when-to-use trigger: operator types a callsign and presses spacebar in N1MM. It does not state when not to use it or name alternative tools, so it stops short of full routing guidance.

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 handled. The description adds useful detail about what data comes back (worked totals, per-band grid, unworked spotted mults, value analysis), but says nothing about cost, freshness relative to the live N1MM instance, or empty-state 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?

Roughly two sentences, front-loaded with the purpose before the enumeration of outputs, and every clause contributes content. Slightly list-like phrasing but 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 re-describing the return payload is largely redundant; the real gaps are the missing sibling differentiation and usage context for a zero-required-parameter tool. What is present is accurate but doesn't cover everything an agent needs to choose this tool confidently.

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% — band and station_name are each documented in the schema — so the description adds no parameter meaning beyond that baseline. It does not explain, for example, that omitting band yields an all-band grid.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description names a specific resource ('multiplier status') and enumerates the four reports it produces, so an agent knows this is a read-only multiplier-analysis tool rather than a contact or bandmap listing. It never explicitly contrasts itself with siblings like n1mm_contacts or n1mm_bandmap, so it stops short of a 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 statement of when to reach for this tool versus n1mm_contacts, n1mm_bandmap, or n1mm_performance, and no mention of prerequisites such as an active contest or log. Usage must be inferred purely from the resource name.

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 genuinely new context: that data is aggregated across all networked stations and what cross-station relationships (band occupancy, shared band+mode, shared contest score) are computed. It does not address behavior when no network is configured, which is the main remaining gap.

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 key framing is front-loaded, but the bulk is a long enumeration of return fields that largely duplicates what the output schema already documents. It is informative yet padded rather than tight.

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 annotations covering safety, an output schema covering return shape, and zero parameters, the description does more than enough to let an agent call it correctly. Minor omission: no mention of standalone/non-networked behavior or performance cost across many stations.

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 there is no parameter semantics to explain; baseline 4 applies. The description correctly signals the no-argument, whole-network snapshot nature of the 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?

Opening line 'Every networked N1MM station at once (multi-op)' gives a specific resource and scope, distinguishing it implicitly from single-station siblings like n1mm_current_state. However, it never names a sibling explicitly, 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?

The '(multi-op)' tag implies this is the tool for networked/multi-operator setups, which is useful context. But there is no explicit when-to-use statement, no exclusion such as 'for a single local station use n1mm_current_state', and no prerequisites.

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, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description adds domain context — notably that the rate derivative is intended for band-exhaustion detection — but says nothing about cost, latency, or behavior when filters are omitted. Since an output schema exists, its enumeration of returned fields is largely duplicative.

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 sentences, well front-loaded with the summary claim first and details second. The long field enumeration in sentence two overlaps the output schema and is the main trimming candidate, but it is not padded or redundant internally.

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?

The description adequately conveys the aggregate nature of the tool, and the output schema plus rich annotations carry the return shape and safety semantics. The one real gap is default scope: with three optional filters and zero required parameters, it never says what is returned when no band/mode/station is supplied.

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 all three filters (band, mode, station_name) are documented inline, so the description has no compensation burden. It nonetheless never mentions the filters at all and instead presents the tool as 'complete', which slightly obscures that results can be scoped.

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 framing: 'Complete performance snapshot' with an enumeration of what is aggregated (score, rate, bands, run/S&P, timeline). An agent can tell it's an aggregate analytics view rather than a raw-data tool. It does not explicitly differentiate itself from the closest sibling, n1mm_current_state, which an agent could plausibly confuse with a performance/rate snapshot.

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 phrase 'in one coherent view' implies this is the consolidated alternative to calling several narrower tools, but no explicit when-to-use, when-not-to-use, or named alternative is given. With eleven siblings including n1mm_current_state, n1mm_diagnostics and n1mm_contacts, the choice is left 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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds real behavioral context by defining what counts as a dupe (already worked on that band and mode), how dead air is measured (gaps of 2+ minutes), and how split is reported (RX, TX, kHz up). It does not mention ordering, cost, or empty-result behavior, keeping it below 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?

One-line purpose up front, then a single structured sentence enumerating the metrics with the window constraint stated first. Dense but every clause maps to a reported value; 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?

Two optional parameters, full schema coverage, complete annotations, and an output schema mean the description only needs to explain intent and scope, which it does. The remaining gap is the absence of routing guidance against the many sibling analytics 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 coverage is 100%, so the 3 baseline applies; the description goes beyond it by stating the window default (60) and its valid range (5 to 1440), which the schema does not express. station_name is not further explained, so it stops short of full parameter 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?

Lead sentence names a specific view ('DXpedition pileup view') and enumerates the exact dimensions it reports: rate, callers, dupes, split, dead air. This is clearly distinguishable from raw-contact siblings like n1mm_contacts, but no sibling is named explicitly, so the agent must infer which of the other N1MM analytics tools overlaps.

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 framing ('pileup view') and by the window_minutes parameter, but the description never states when to reach for this versus n1mm_performance, n1mm_bandmap, or n1mm_current_state. No exclusions or prerequisites are given.

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 the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds real value beyond them: data provenance (derived from N1MM broadcasts, not rig reads), the measurement window ('RadioInfo packets seen since the MCP server started (or the contest changed)'), and a disclosed blind spot (paddle/PTT transmit time is not reported). It stops short of describing failure behavior when N1MM is disconnected.

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 purpose sentence is well front-loaded, but the body is one dense run-on enumerating every return field, which duplicates the existing output schema and bloats the definition. Several listed metrics could be compressed or left to the output schema.

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?

Since an output schema exists, the lengthy field enumeration is largely redundant, while the genuinely missing pieces — what station_name does, behavior when N1MM is not connected, and routing versus n1mm_current_state — go unaddressed. Adequate but with clear gaps for a complex multi-metric 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 single parameter station_name is entirely undocumented in the schema (0% coverage) and never mentioned in the description, so an agent cannot tell whether it selects a station, filters a multi-station setup, or is purely cosmetic. With such low coverage the description needed to compensate and does not.

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?

Opening sentence names a specific resource and scope ('Two-radio (SO2R) view: both radios now, and how they've been used') plus a concrete field inventory (band, frequency, mode, run/transmit state, focus swaps, QSO counts). This is clearly distinguishable from single-radio siblings like n1mm_current_state or performance-oriented tools such as n1mm_performance.

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: an agent can infer this applies when two radios are in play, and the closing clause 'Read from N1MM's broadcasts; no rig is read' hints at a prerequisite (N1MM must be running). But there is no explicit when-to-use/when-not statement and no named alternative (e.g., 'use n1mm_current_state for a single-radio snapshot').

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