Band Atlas (Hyper Nexus)

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds real value beyond that by disclosing the scoring methodology: dual-source cross-checking, sub-1 GHz bands weighted double, and the 60 percent threshold for 'good'.

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 action is front-loaded, but the whole description is one long run-on sentence that crams the scoring rules together, making them hard to parse. It is dense rather than genuinely 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 no output schema, the description carries the return-value burden and does describe the verdict plus missing bands per network, along with the rules used. It stops short of describing result shape or ordering, but is sufficient to call the tool 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?

Schema description coverage is 100%, so the schema already documents lte_bands, nr_bands, and countries with examples and the 10-country limit. The description only restates that NR is optional, adding no syntax or format detail; 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: paste LTE/5G NR bands and get a per-network verdict for one or more countries, including missing bands. Clear what it does, but it does not explicitly differentiate itself from siblings like check_device or get_country_networks.

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 usage context is implied by the input shape (you supply a band list and countries), but there is no explicit when-to-use/when-not guidance and no pointer to alternatives such as check_device. An agent can infer the case but receives no routing help.

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 closed-world behavior, so the safety profile is covered. The description adds useful substance beyond that by stating what the response contains (a verdict plus the missing LTE/NR bands per network), which is valuable given there is no 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?

Two tight sentences, with the verdict/output shape front-loaded before the routing advice. 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?

For a two-param read-only lookup with no output schema, the description covers the return content (verdict + missing bands) and the alternative paths adequately. It is nearly complete, with only minor gaps such as result granularity per network.

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 schema already documents both parameters with examples (mf833v, Quectel EG25-G) and the ISO code / country name format. The description adds only the implicit hint that 'device' must be a known id (pointing to list_coverage), which is marginal beyond what the schema provides.

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 precise verb and resource: a verdict (good/limited/no) for a known module or device across every network in a country, including the LTE/NR bands it lacks. The scope and output shape are clear enough to distinguish it from siblings like check_bands and list_coverage without opening a 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?

Explicitly routes the agent: use list_coverage to find device ids, or check_bands for a device that is not listed. This is exactly the when-to-use/alternative guidance that prevents mis-selection among the 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuine behavioral context beyond them by explaining the ranking basis (network 'good' ratings) and what the response conveys (which device works on every network), which matters given there is no 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?

Two sentences, front-loaded with the action, with no filler. The first sentence is long and compound but each clause carries distinct information (the ranking criterion and the per-country verdict); the second sentence cleanly states the payoff.

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 single-parameter, read-only tool with annotations and no output schema, the description covers purpose, use case, and the conceptual shape of the result. It could say more about result ordering/limits across up to 20 countries, but nothing essential to calling it correctly is missing.

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

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

Schema coverage is 100% and the countries parameter is fully documented in the schema (ISO codes or names, max 20). The description only refers to 'the given countries' and adds no format, cardinality, or matching semantics beyond what the schema already supplies, 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 (rank) and resource (modules and devices in Band Atlas) with precise scope: ranking by how many networks of the given countries rate them good, plus per-country 'works on every network' verdicts. This aggregation-over-countries behavior sets it apart from single-entity siblings like check_device and check_bands.

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 a clear use context — picking the fewest SKUs for a multi-country deployment — which tells the agent when this tool is the right choice. It does not, however, name alternatives (e.g., check_device) or state when-not to use it, so it stops short of explicit routing.

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=false, and destructiveHint=false, so the safety profile is fully covered. The description adds one genuinely behavioral detail beyond the schema — that bands are marked as cross-checked by two independent sources or single-source — which is useful provenance context, but it says nothing about error handling for unknown countries or response shape.

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 that leads with the resource scope before listing payload contents. The enumeration is dense but each item carries information; the only weakness is that it reads as a field dump rather than a prioritized statement of purpose.

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?

No output schema exists, so the description must carry the return-value burden, and it does so thoroughly by naming every band family and technology generation reported. For a simple read-only, one-parameter lookup with complete annotations, this is close to sufficient; only edge-case behavior (unknown or ambiguous country) is unaddressed.

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?

With a single parameter at 100% schema description coverage, the schema already fully documents the accepted formats (ISO alpha-2, English or Chinese name). The description adds no additional meaning about the country argument, so the baseline 3 applies.

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

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

States a specific verb+resource ('Mobile networks of one country') and enumerates exactly what is returned (4G/LTE and 5G/NR bands, core bands, 2G/3G/5G SA/RedCap/LTE-M/NB-IoT states, switch-off dates). It does not, however, distinguish itself from siblings like check_bands, list_coverage, or iot_readiness, which plausibly overlap with the band and technology-state content.

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 mention of when another sibling (e.g., check_bands for a single band query or iot_readiness for IoT readiness) would be preferable, and no stated preconditions. The agent must infer applicability purely from the payload description.

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=false, so the safety profile is covered. The description adds genuinely useful methodological context the annotations cannot: it is beta, the score weighting breakdown, and the caveat that 'not listed' is never treated as 'not available', so thinly documented countries may be under-scored.

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 resource and default scope, then the weighting breakdown. It is a single dense sentence with embedded percentage clauses that reads slightly run-on, but nearly every clause carries selection-relevant information.

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

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

With no output schema, the description partially compensates by naming returned elements (rank, data confidence, weighted score) and the eligibility rule for confirmed data. Complete enough to call correctly, though it does not describe response shape or ordering in detail.

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 there is a single optional parameter, so the schema already documents ISO codes/names and the ≤20 rule. The description restates the top-20 default but adds no format or validation detail beyond the schema. 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?

States a specific resource (IoT connectivity readiness index / Band Atlas score) with its scope (given countries, or top 20 default) and a clear output range (0-100). An agent can distinguish this from get_country_networks or check_bands, which cover raw network/band data rather than a composite index.

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 defines the no-argument default ('top 20 when none are given') and the 20-country cap, which tells the agent how to call it. It does not, however, name a sibling as the alternative for when raw band/coverage data is wanted, so the routing guidance is implicit rather than complete.

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=false, so the safety profile is fully covered without the description. The description adds only the sequencing hint that this is a discovery step before other calls; it doesn't mention result size, pagination, or rate limits for what is described as a complete catalogue.

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, zero filler. The content enumeration comes first and the routing instruction second, so the agent gets scope before guidance. Every clause carries 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?

There is no output schema, but the description compensates by naming the fields returned for both entity types (ISO code, name, network count; id, name, kind). With no parameters and annotations covering the safety profile, this is nearly complete; minor gaps are the absence of any hint about catalogue size or response format.

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 per the rubric the baseline is 4. The description cannot and need not explain argument semantics, and it introduces no misleading argument language.

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 verb and resource set: it enumerates every country (with ISO code, name, network count) and every module/device (with id, name, kind) that Band Atlas covers. That scope is clearly distinct from siblings like check_bands or iot_readiness, though no sibling tool is named to make the distinction 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?

It gives an explicit trigger: 'Call this first if you are unsure of a country code or a device id.' That is real when-to-use guidance tied to a concrete precondition. It lacks any when-not-to-use statement or named alternative (e.g., find_devices for searching by attribute), so it falls short of a 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds real value beyond them: it discloses what the report contains, the indoor-coverage risk caveat when a network's coverage band is missing, and that results should be confirmed by an engineer. It does not mention latency, rate limits, or result freshness, which keeps it short of 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?

The scope ('one report for a device across several target countries') is front-loaded, and the sentence is dense but free of filler. The nested parentheticals make the second half slightly harder to parse, but every clause carries information.

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

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

With no output schema, the description usefully summarizes the return content and mentions the downstream artifacts (website PDF, share link). Both parameters are fully specified by the schema, so nothing essential is missing, though result formatting/pagination remains unaddressed.

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 (device, countries) are already documented with examples, formats, and the 30-country cap. The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

The description states a specific resource (a multi-country device report) and its output structure: where the device works as is, needs attention, or does not work. It is clear and actionable, but it never contrasts itself with siblings like check_bands, iot_readiness, or list_coverage, so the agent must infer the distinction from the name 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?

Usage is implied rather than stated: 'for a device across several target countries' suggests the multi-country scenario, but there is no explicit when-to-use, when-not-to-use, or alternate-tool routing versus the six sibling tools. An agent can guess the context but gets no decision rule.

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