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

With no annotations, the description carries the burden and does reasonably well: it discloses that this is a lightweight, non-health-probe identity read that succeeds even when N1MM isn't broadcasting, implying no dependency on upstream state. It does not explicitly state read-only/no-side-effect behavior, but 'Get' plus 'identity attestation' make a write highly implausible.

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 purpose in the first sentence, then usage, then the sibling distinction. The 'Returns:' block slightly duplicates the existing output schema, but the content is dense and each section adds value; only minor redundancy keeps it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter identity tool with an output schema present, the description covers purpose, when-to-use, sibling differentiation, and upstream-independence semantics. Nothing an agent needs in order to invoke 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?

Zero parameters, so per the rubric the baseline is 4; the description goes beyond by naming the returned fields (service_name, service_version, spec_version), which adds useful meaning despite the empty input schema. This exceeds the zero-parameter baseline.

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+resource ('Get n1mm-mcp service version and upstream UDP contract version') and explicitly distinguishes itself from the sibling n1mm_diagnostics by calling itself a 'lighter-weight identity attestation.' An agent can tell exactly what this returns and how it differs from the health probe without opening the 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 across MCP deployments — compare service_version and spec_version across servers to detect drift') and names the alternative ('n1mm_diagnostics remains the canonical health probe'), including the condition that selects this tool instead: it 'succeeds even when N1MM isn't broadcasting.'

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?

No annotations are provided, so the description carries the full behavioral burden. It does add genuine value by disclosing TTL eviction on spots and the single-snapshot semantics, but it never states that this is a read-only query, whether it requires a running N1MM instance, or any refresh/latency characteristics.

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 the resource and payload front-loaded; nothing is buried. There is mild redundancy between the headline list in sentence one and the re-enumeration in sentence two, which keeps it just short of a 5.

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 explained, and the description adequately covers what the snapshot contains for a parameterized read tool. It falls short only on the missing read-only/safety framing that would normally be supplied by annotations.

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?

All five parameters are documented in the schema at 100% coverage, so the schema already does the heavy lifting and a baseline of 3 applies. The description only indirectly touches parameters — 'mult targets' gestures at mults_only, 'per-band' at band — without adding format, matching semantics, or interaction rules between filters.

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 concrete resource (live bandmap) and enumerates its contents — active spots, unworked multipliers, per-band activity counts — so the agent knows exactly what this returns. It does not, however, differentiate itself from close siblings like n1mm_multipliers or n1mm_current_state, which overlap in the multiplier/state space.

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 contesting snapshot, which hints at when to reach for it, but there is no explicit when-to-use, when-not-to-use, or alternative routing. Given the sibling n1mm_multipliers covers similar multiplier territory, the absence of any disambiguation is a real 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?

No annotations are provided, so the description carries the full burden, and it discloses nothing behavioral: no hint that it is a read-only view, no mention of what pacing assumes, no note on how off-time is computed from min_gap_minutes. An output schema exists, which relieves some return-value burden, but the behavioral profile is essentially absent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short clause with no wasted words and the core resource front-loaded. It is arguably too terse to be useful rather than padded, so it sits at 4 rather than 5.

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 tool with five parameters, an output schema, and eight siblings, one sentence is not enough. The description never says the tool works with zero arguments (all params optional), nor distinguishes the pacing view from other state-reporting tools, leaving the agent to guess when to call it.

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 each of the five optional parameters is documented in the schema itself, so the baseline of 3 applies. The description adds no extra meaning about how target_qsos/target_score/duration_hours interact or what happens when they are omitted.

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?

Names the resource (contest clock) and three facets it covers: timing, off-time, pacing. But it uses no verb (get/return) and 'in one view' is filler that doesn't tell the agent what it actually receives. It is distinguishable from n1mm_performance or n1mm_current_state only by 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 indication of when to use this versus the other eight N1MM siblings, several of which (n1mm_current_state, n1mm_performance) plausibly overlap with timing/pacing. No prerequisites, exclusions, or contest-session context 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?

With no annotations, the description carries the full burden, and it does disclose a real behavioral trait: the response bundles the last QSO plus recent edits and deletes into one snapshot. It is silent on safety profile, read-only nature, and any volume/rate limits, but the return-value behavior is partially conveyed.

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 identity and then the return content; no filler or repetition. Slightly terse, but every clause 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 the description need not explain return values, and all six parameters are schema-documented. For a read-only, zero-required-parameter query tool the description is nearly complete; only explicit usage routing 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 all six optional filters (band, mode, count, since, call_pattern, station_name) are already fully documented in the schema. The description only gestures at 'filtered recent QSOs' without adding syntax, defaults, or interactions, so baseline 3 applies.

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

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

States a specific verb+resource ('QSO log — recent contacts, edits, and deletes') and enumerates exactly what the snapshot contains (last QSO, filtered recent QSOs, edits, deletes). It is clearly distinguishable from siblings like n1mm_lookup and n1mm_current_state by being the log/history view, though it never names an alternative explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use statement, no prerequisite, and no alternative tool named. An agent can loosely infer it is for inspecting recent QSO activity, but the description gives no explicit routing guidance against the eight sibling tools.

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?

No annotations are provided, so the description carries the full disclosure burden. It implies a read-only snapshot through wording ('Complete station snapshot', 'Returns ...') and lists the categories of state returned, but never explicitly declares it side-effect-free, nor mentions permissions, rate limits, or behavior when no station is connected.

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 opening snapshot line is well front-loaded, but the second sentence largely restates the same contents ('connection, contest, operator, radios' vs 'connection status, contest info, operator callsign, and full radio state'), which is redundant given an output schema already exists.

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 re-explained, and the description's restatement of them is wasted space. What is missing is any meaning for the station_name parameter and any behavioral framing (read-only, no-station case) for a tool with no annotations.

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 sole parameter, station_name, is never mentioned in the description. With one optional parameter and no schema documentation, the description should explain what station_name selects and what the null default means; it does none of that, so it fails to compensate for the coverage gap.

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 concrete resource and scope: 'Complete station snapshot — connection, contest, operator, radios,' and enumerates the returned components. This clearly separates it from narrower siblings like n1mm_contacts, n1mm_bandmap, and n1mm_performance, though no sibling is named explicitly, keeping it 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?

'This is the first tool any AI session should call' is explicit when-to-use guidance that tells the agent to invoke it at session start. It stops short of naming alternatives or stating when NOT to use it, so it does not reach 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?

No annotations are provided, so the description carries the full burden. It discloses the diagnostic domains it inspects (connection, parse errors, memory), which is useful context, but never states that it is a non-mutating/read-only operation or whether it incurs load on the server. For a no-annotation tool this leaves a notable gap, though 'diagnostics' strongly implies a safe read.

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 tool's function and facets before the usage advice. Slightly redundant — 'Essential for production debugging' and 'First tool to call when something goes wrong' make the same point — so it is efficient but not maximally 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?

An output schema exists, so return-value detail is correctly omitted, and the purpose/usage coverage is adequate. The gap is the undocumented optional station_name parameter, which is the one piece of invocation information an agent needs and cannot get from either the schema or the description.

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 has 0% schema description coverage and is never mentioned in the description. The description does not explain what the parameter scopes, nor what happens when it is omitted (the default is null), so an agent must guess whether a missing value means 'all stations' or 'current 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 specific verb/resource ('Server health and diagnostics') and enumerates the facets covered — connection, parse errors, memory — which clearly separates it from the data-retrieval siblings like n1mm_contacts and n1mm_bandmap. It stops short of naming any sibling explicitly, so it is clear but not fully differentiated.

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 trigger condition ('First tool to call when something goes wrong during a contest') plus a context ('essential for production debugging'), which is genuine when-to-use guidance. It does not state when NOT to use it or point to an alternative diagnostic/fallback tool, 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?

With no annotations, the description carries the full burden, and it does substantive work: it discloses the trigger condition, the payload contents, and a freshness guard (lookup_age_ms > 30000 means the advice window has closed). It does not cover permissions, latency, or error behavior, but the freshness disclosure is genuinely non-obvious 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?

Three short sentences, no filler, with the trigger and return contents front-loaded. The only slightly wasteful element is the promotional 'THE Contest-Copilot trigger' phrase, which adds tone rather than 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?

An output schema exists, so return fields need not be enumerated and the age-window hint is a bonus. The gap is on the input side: the single parameter is undocumented in both schema and description, so an agent has no guidance on what to supply for 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?

There is one parameter (station_name, nullable with default null) and schema description coverage is 0%, so the description must compensate — and it never mentions station_name at all. It also names a return field (lookup_age_ms) rather than clarifying the input, leaving the agent to infer why a station name would be passed.

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+resource ('pre-log callsign lookup') and specifies what comes back (lookup data plus current band/mode from RadioInfo). It is distinguishable from siblings like n1mm_contacts or n1mm_current_state, though the 'THE Contest-Copilot trigger' framing is editorial rather than informative.

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 names the triggering event in N1MM (operator types a callsign and presses spacebar), which implies when the lookup is relevant. However, it never says when an agent should call this versus n1mm_current_state, n1mm_contacts, or the other siblings, and no exclusions 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?

No annotations are provided, so the description carries the full behavioral burden, yet it only restates return contents that the output schema already defines. It says nothing about read-only nature, data freshness, auth, or rate limits — no behavioral traits beyond structured data.

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 summary line followed by an enumeration of outputs. Efficient, with only mild redundancy against 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?

For a simple read query with an output schema and fully documented optional params, the description is largely sufficient. The gap is the absence of any behavioral or safety context, which matters because there are no annotations to cover it.

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 two optional, well-described filters (band, station_name), so the schema does the heavy lifting. The description adds no semantics about these filters, which is the expected baseline.

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 (contest multipliers) and enumerates what it surfaces — total mults worked, per-band mult grid, spotted unworked mults, value analysis. It is clearly distinguishable from siblings like n1mm_contacts or n1mm_bandmap by resource, though it never names them 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 description conveys what the tool reports but gives no conditions, prerequisites, or alternatives — no hint about when to prefer it over n1mm_bandmap or n1mm_performance. Usage is only implied by 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?

With no annotations, the description carries the full burden, and it does disclose return content plus a useful interpretive note ('rate derivative for band exhaustion detection'). However, it never states that this is a read-only operation, whether the band/mode filters narrow only the rate/breakdown sections or the whole snapshot, or any cost/latency characteristics.

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 headline sentence front-loads the scope, and the second paragraph enumerates contents efficiently. There is mild redundancy ('score' and 'bands' appear in both sentences), but overall it is tight and well-ordered.

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 detailed return-value enumeration is largely duplicative; the description's marginal value is the snapshot framing and the band-exhaustion hint. What is missing is the decision context — when an agent should prefer this consolidated view over n1mm_current_state or n1mm_contacts.

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 schema already documents band, mode, and station_name. The description adds nothing about parameter behavior, including the important question of how filtering interacts with the reported aggregates; 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 the resource clearly ('complete performance snapshot') and enumerates the dimensions it covers (score, rate, bands, run/S&P, timeline), so an agent knows what it retrieves. It does not, however, differentiate itself from siblings like n1mm_current_state or n1mm_multipliers, which could plausibly overlap.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no statement of prerequisites, and no reference to an alternative tool. The intended context ('use this when you want a consolidated performance view rather than individual stat tools') is left entirely to inference.

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