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

Annotations already declare readOnly, idempotent, closed-world, non-destructive, so the safety profile is fully covered. The description adds only the substance of what is reported (binary version, layout version, record version) — useful context, but no auth, rate-limit, or output-shape detail beyond that.

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 the three values returned, with zero filler. 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?

An output schema exists, so return values need not be enumerated in prose, and the annotations fully cover behavior for a zero-param read. The description is adequate for this simple tool; only the lack of stated use case keeps it from a 5.

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, which sets the baseline at 4. There is no parameter semantics to add, and the description correctly does not invent any.

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 ('Get') with three explicitly named resources: the server's version, the omiss.net layout version it reads, and the record version it returns. This is clearly distinguishable in kind from every sibling, which are all domain-data lookups, though the description never says so 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?

No explicit when-to-use or when-not-to-use guidance. Usage is only implied by content — an agent can infer this is for version/compatibility introspection, but nothing states prerequisites, caching advice, or that no other tool needs to be called first.

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

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

The annotations already establish read-only, idempotent, non-destructive behavior, so the description does not need to repeat safety properties. It adds useful context about certificate ordering and member filtering, but says nothing about pagination or the default limit behavior.

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

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

A single efficient sentence with no wasted words. The primary listing purpose is front-loaded, and the alternate 'check one member' mode follows naturally.

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, a 100% documented schema, and an output schema, the description is nearly sufficient for correct invocation. The only minor gap is that it does not mention the limit/pagination aspect, though the schema does document that parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all four parameters are already documented in the schema. The description slightly reinforces award and member filtering but adds no new syntax, default, or constraint details 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?

States a specific verb ('List') and resource ('who holds an OMISS award'), plus an alternate mode ('check one member'). It is clearly distinct from the sibling omiss_awards, which appears to list the awards themselves, but it does not explicitly name that sibling.

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 'or check one member' implies that callsign/om_number filters can narrow results, and 'newest certificates first' gives ordering context. However, it does not explicitly say when to use this tool versus omiss_awards, omiss_member_lookup, or omiss_award_rules.

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 read-only, idempotent, open-world and non-destructive, so the safety profile is covered. The description adds mode-dependent behavior, but it does not add much beyond that, and output-schema details are already available separately.

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 compact sentence with no wasted words. The primary behavior and the omitted-award_id fallback are front-loaded and easy to parse.

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 one-parameter read tool with an output schema and rich annotations, the description covers the key calling modes and parameter omission behavior. The main remaining gap is the lack of explicit sibling differentiation from omiss_awards.

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 award_id parameter is already documented in the schema. The description adds useful meaning by explaining what happens when award_id is omitted: the tool returns a summary listing rather than rules.

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 an OMISS award's rules. It also explains the overloaded mode when award_id is omitted, but it does not explicitly distinguish this tool from the sibling omiss_awards tool.

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 clearly explains the two usage modes: provide award_id to get one award's rules, or omit it to list every award's name, ID and summary. It does not name alternatives or exclusions, such as when to use omiss_awards instead.

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 one real behavioral fact — that only awards with recipients are returned — but says nothing about size, ordering, or how IDs should be reused; return shape is covered by the output schema.

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, and the qualifying/secondary clauses each carry distinct information. 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?

A zero-parameter, read-only listing tool with full annotations and an output schema needs only to say what it lists and what the entries are for; the description does both.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters, so the baseline is 4; schema coverage is also 100% on an empty object. Nothing in the parameter space needs describing.

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') and resource ('OMISS awards') with an explicit scope qualifier: only awards that have recipients. The second clause ('award IDs the other award tools take') identifies the payload and how it differs from the related rules/recipients 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?

Clearly implies this is the discovery/prerequisite call whose output IDs feed 'the other award tools', which tells the agent where it sits in a call chain. It stops short of naming the specific siblings (omiss_award_rules vs. omiss_award_recipients) or stating when not to use it.

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, so the description correctly focuses on non-obvious behavior: results are ordered newest first, and the upstream site caps results at the latest 100 matches. That result-cap disclosure is genuinely valuable context an agent cannot get from annotations or schema. It stops short of describing what an empty result or a truncated page looks like.

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

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

Two sentences, front-loaded with the core action and ordering, with the filter list and the 100-result caveat following logically. No filler, though the mid-sentence filter enumeration ('on a band, on a date, or run by a net control') reads slightly list-like rather than prose.

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 needn't explain return shape, and it covers the pieces that matter for correct invocation: ordering, the optional-filter model, and the upstream result cap. A note on whether omitted filters mean 'all' vs 'most recent' would close the remaining gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter (band, date, callsign, om_number, net_control) is already documented with formats and examples. The description only restates the filter concepts at a higher level and adds no format, precedence, or combination rules 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?

Opens with a specific verb and resource ('List past OMISS nets') plus ordering ('newest first'), and enumerates the filter dimensions, which separates it from omiss_net_checkins (check-ins for a single net) and omiss_net_schedule (upcoming nets). It never names those siblings, so the differentiation is implicit rather than explicit.

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 'all of them, or only those...' makes clear that filters are optional and combinable, which is useful usage context. However there is no guidance on when to prefer this over omiss_net_checkins or omiss_net_statistics, and no mention of what happens with zero filters beyond the default listing.

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 still adds real value beyond them by naming the data source (omiss.net's own rosters, i.e. externally-maintained truth) and clarifying that only the queried callsigns are answered, which bounds the response scope.

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

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

The purpose is front-loaded in the opening sentence, and the second and third sentences add usage routing and response scope with no filler. Slightly awkward phrasing ('For stations on a net:') and gratuitous line breaks keep 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?

With an output schema present, the description needn't explain return values, and it covers the source of truth, the intended pairing with check-in tools, and the response boundary. It could be more complete by clarifying the batch-vs-single-lookup split against omiss_member_lookup.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single array parameter already documents its item format and the 200-callsign cap. The description adds only the semantic that results are limited to callsigns asked about; it contributes little parameter 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?

States a specific verb+resource: for a set of stations, report OMISS membership and which award categories each counts for, sourced from omiss.net rosters. Clear enough to act on, though it never distinguishes itself from the sibling omiss_member_lookup, so an agent may hesitate between the single-lookup and batch variants.

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 concrete usage context: pair it with a net's check-ins, naming netlogger_checkins for a live net and omiss_net_checkins for a past one, to identify who is still needed. It stops short of explicit exclusions or saying when to prefer omiss_member_lookup over this batch 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 readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered structurally. The description adds only the single-identifier constraint and nothing about failure modes (unknown callsign, ambiguous match) or lookup 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?

A single short sentence with the resource and the identifying constraint front-loaded; nothing is redundant or padded.

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 needn't be described, and annotations cover safety and idempotency. For a two-parameter lookup the description is nearly sufficient, with only not-found behavior left 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 description coverage is 100%, so the baseline would be 3. The description earns the step up by stating 'give one,' a mutual-exclusivity rule the schema does not enforce (both params are optional and allow null), which meaningfully constrains invocation.

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: look up a single OMISS member, with the two lookup keys named. That clearly separates it from list-oriented siblings like omiss_net_checkins or omiss_award_recipients, 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?

The parenthetical '(give one)' implies the two identifiers are mutually exclusive and that one is required, which is real guidance. But there is no statement of when to prefer callsign over OM number, no handling of a not-found result, and no mention of siblings.

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 covered. The description adds that the payload includes net control notes and a full check-in list, which hints at response size, but says nothing about pagination, permissions, or what happens if the net_id is unknown.

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

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

One sentence, front-loaded with the verb and subject, and the returned-field list is deferred to the end where it does not obstruct the core action. 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 and annotations cover the safety profile, so the description only needs to identify the resource and its scope — which it does. The remaining gap is not naming which sibling to use for live versus historical net data.

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?

Single parameter with 100% schema description coverage, which already tells the agent the net_id comes from omiss_checkin_history. The description only reinforces that this is a single-net lookup and adds no syntax, range, or lookup-path detail 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?

Specific verb plus resource: retrieves a single *past* OMISS net with an enumerated content list (net control, relays, frequency, notes, check-in list). The word 'past' implicitly separates it from omiss_nets_on_air, but no sibling is named explicitly, so differentiation is inferential 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?

The singular 'one past OMISS net' plus the schema note that net_id comes from omiss_checkin_history implies the lookup workflow, but the description itself never states when to pick this over omiss_net_schedule, omiss_nets_on_air, or omiss_net_statistics.

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 non-destructive, so safety is covered by structured data. The description adds non-obvious behavior the annotations cannot: next_utc is the listed start rather than actual open time, nets often open early for check-ins, and an in-progress net still reports next_utc as its next run. That is high-value operational 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?

Content is front-loaded: the resource and return payload come first, then timezone caveats, then the sibling routing. The first sentence is long and clause-dense, but nearly every clause carries information that changes how an agent uses the result.

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 need not describe return values, and it doesn't waste words doing so. For a parameterless, read-only tool it covers the remaining risks — UTC versus local day boundaries and the sibling that answers on-air status — so an agent can call it and interpret results correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. It still usefully explains how to interpret the returned time fields (next_utc, as_of_utc) for local-date reasoning, which is field semantics rather than parameter semantics.

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 and resource ('Get the OMISS net schedule') followed by an inventory of exactly what is returned: band, UTC time, frequency, window, days, holiday time, coordinator, next run, footnotes, and federal holidays. This is distinguishable at a glance from siblings like omiss_nets_on_air or omiss_net_statistics.

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

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

Explicitly routes the agent to the alternative: 'ask omiss_nets_on_air whether one is open' when the question is about whether a net is currently on the air. It also names the condition that selects the alternative (a net on air now shows next_utc as its next run), which is exactly the routing detail an agent needs.

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, non-destructive behavior, so the description is free to add value elsewhere — which it does by disclosing the data source (NetLogger) and the exact matching heuristic (frequency within window, correct day, near start time, or OMISS in the name). It does not mention refresh cadence or how stale the 'now' snapshot can be.

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

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

Three short sentences, with the core purpose front-loaded before the matching explanation. The closing sentence ('Each says which scheduled net it is') is slightly redundant with the opening clause about matching to the schedule but does clarify the output shape.

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 no explanation, and the description supplies source and matching logic. For a live-data tool it would be stronger with a note on snapshot freshness or the fact that results can be empty between nets.

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 there is nothing for the description to clarify and the baseline of 4 applies. The description correctly avoids inventing filter parameters that the empty schema does not support.

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 OMISS nets currently on the air, sourced from NetLogger and cross-matched to the OMISS schedule. This implicitly separates it from the static omiss_net_schedule and from checkin-oriented siblings, though it 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 phrase 'on the air now' implies a real-time use case versus the static schedule, but there is no explicit when-to-use guidance, no statement of when to prefer omiss_net_schedule or omiss_net_checkins, and no exclusions or 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=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context with the fixed 52-week window and what statistics are computed, but it does not discuss freshness, rate limits, or aggregation constraints.

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 efficient sentence that is front-loaded with the action and scope, followed by the returned categories. Every clause contributes useful 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?

The tool is simple, has full schema coverage, has an output schema, and has annotations covering its safety profile. The description is complete enough for an agent to understand what it returns and 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%, so both parameters are already documented in the schema. The description does not add meaning for 'top' or 'state' beyond what the schema provides, so the baseline of 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?

States a specific verb and resource ('Get OMISS net statistics') plus the exact scope ('last 52 weeks') and the categories returned: nets per band, last net per band, and leaderboards. This clearly distinguishes aggregate statistics from sibling tools like omiss_checkin_history and omiss_member_lookup.

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 52-week window and leaderboard contents imply when to use it for aggregate statistics, but there is no explicit when-not guidance or named alternative among the many OMISS siblings. Usage is inferable but not fully routed.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety and repeatability are covered elsewhere. The description adds content scope (which role categories appear) but says nothing about freshness, pagination, or whether the list is a fixed snapshot — modest added value beyond the structured fields.

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

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

A single front-loaded sentence with no filler; every listed term adds informational content about the result set. Nothing is repeated from the name or 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?

With an output schema present, the description need not explain return values, and the no-parameter signature keeps the surface small. It covers what an agent needs to select the tool; only the freshness/snapshot question remains implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to clarify on the input side. The role enumeration mildly helps an agent predict result shape but is not a parameter concern.

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 ('List') plus a concrete resource enumeration of the organizational roles it returns (officers, directors, band coordinators, committees, past presidents). It is clearly distinguishable from siblings like omiss_member_lookup or omiss_checkin_history, which serve member-level and activity data rather than leadership rosters.

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 is the tool for leadership/contact-role questions, but the description never states when to prefer it over omiss_member_lookup or what it excludes. No prerequisites or 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?

Annotations already cover the safety profile (readOnly=false, idempotent=true, destructive=false), so the description adds genuinely new context: NetLogger is informed which station is asking, and the value is shared with netlogger-mcp if installed. It also implies persistence rather than a per-call parameter. Return behavior is covered by the output schema.

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 and the prerequisite. The NetLogger/mcp-sharing detail is secondary but earns its place by explaining a side effect.

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 idempotent setter with full schema coverage, an output schema, and annotations, the description supplies the prerequisite, the side effect, and the sourcing rule for the value. Only an explicit statement of change/reset semantics or permissions is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema even supplies an example (KI7MT), so the baseline is 3. The description adds meaning beyond that by stressing the callsign must be the user's own and must not be guessed, which is a real correctness constraint on the value.

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 ("Save the user's amateur radio callsign") and scopes it to the target tool (omiss_nets_on_air). No sibling among the omiss_* lookup/report tools performs a write, so the distinction 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?

"Needed once" plus the tie to omiss_nets_on_air establishes a prerequisite and frequency, and "Ask the user for their own callsign; don't guess it" is an explicit behavioral instruction. It lacks a stated when-not-to-use case, 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?

The annotations already declare this a read-only, idempotent, open-world fetch, so the safety profile is covered. The description adds a little domain framing about what the schedule contains, but with an output schema present it does not need to itemize return fields, and it says nothing about caching, freshness, or why it is open-world.

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, with zero filler. The clause describing the returned contents is the only elaboration and it 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?

For a no-parameter read tool with a full annotation profile and an output schema, the description covers purpose and return shape adequately. The remaining gap is that domain terms like 'free-call states' and 'Statehood' are left unglossed and no routing to the general net schedule is offered.

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 are no semantics to clarify; the baseline of 4 applies. The description correctly presents this as a plain fetch with no filtering dimension.

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: retrieve the 40m Statehood net schedule, including each date, its free-call states, and the next occurrence. That wording separates it from generic siblings like omiss_net_schedule, though the distinction is implied by 'Statehood'/'40m' rather than called out 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 or when-not-to-use guidance, and no sibling is named as an alternative. An agent must infer from the label alone that this is the Statehood-specific schedule rather than the general one from omiss_net_schedule.

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