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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the manual/immediate timing context, but does not explain what 'destructive' means here (e.g., overwriting an existing backup) or what side effects to expect, so it adds only modest value beyond the annotations.

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 the verb first and zero filler. Every word earns its place and nothing is repeated from the title 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?

For a no-parameter, no-output-schema tool, the description covers the core action and its manual/on-demand nature. It could go slightly further by clarifying the relationship to list_backups or whether an existing backup is replaced, but the annotations already carry the destructive safety signal.

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

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

The tool takes no parameters, so the baseline is 4 per the scoring rule. The description correctly adds no parameter detail because none exists, and the empty schema is self-explanatory.

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: 'trigger a router config backup.' The 'router config' qualifier implicitly distinguishes it from sibling backup_mcp_config and from list_backups, though no sibling is named explicitly. Clear and actionable, but sibling 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?

'Manually' and 'right now' imply this is the on-demand counterpart to scheduled backups, giving an implied usage context. However, there is no explicit when-to-use/when-not-to-use guidance and no mention of alternatives such as list_backups or diff_saved_config.

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?

Adds substantial context beyond annotations: mirror is refreshed every run, dated snapshots written only on content change, execution is synchronous, and a round-trip md5 verification is reported. It partially explains the destructiveHint=true by describing mirror overwrite, though it never warns about the risk of overwriting existing snapshots.

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?

Four dense sentences, purpose front-loaded, each contributing distinct information (scope, mirror semantics, sync + verification, staging location). No filler or repetition of the title.

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 one optional parameter and no output schema, the description covers what it does, how it behaves, and roughly what it reports. Minor gaps remain around failure handling and snapshot retention, but nothing that blocks correct invocation.

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

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

Schema description coverage is 100% and the single `verify` parameter is fully documented in the schema. The description reinforces it ('round-trip md5 check of the mirror') but adds no default, cost, or failure-mode detail 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 (back up) and a precisely scoped resource (this server's own config files not restorable via release/git pull, naming .env, watch_rules.json, the Entware init script). This clearly distinguishes it from the sibling backup_config (router config) and list_backups.

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 scope criterion ('files that no release or git pull restores') implies when this tool is appropriate, but it never explicitly names the alternative backup_config or states when to choose one over the other. Usage is inferable rather than directed.

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 destructive=true, readOnly=false, and idempotent=true, so safety is largely covered. The description adds meaningful behavioral detail by noting that an unregistered device is first registered as 'Blocked Device' and that unblock_client reverses the action.

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 action, followed by the side effect and undo path. No sentence is redundant.

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 destructive tool with annotations and no output schema, the description covers the core action, unregistered-device side effect, and reversal. It could clarify exactly what blocking does to an already-connected client, but is otherwise complete.

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 mac parameter already includes a format example. The description only restates that blocking is by MAC address, adding no syntax or constraints beyond the schema.

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

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

The description states a specific verb and resource: block a device by MAC address. It clearly distinguishes the action from its sibling unblock_client and implies a different role than get_clients or update_client.

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 names unblock_client as the undo path and explains the special case for unregistered devices. It stops short of broader when-to-use/when-not guidance versus update_client or register_client, so it is clear but not comprehensive.

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 behavior. The description adds substantial context beyond that: it explains the data source (RCI), that the comparison is checksum-independent, that secrets are masked on both sides, and that empty lists mean fully saved. It also discloses that the tool is not wired into write tools.

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 four tightly written sentences, front-loaded with purpose and return semantics. Every sentence adds useful information: source, return structure, secret masking, and usage constraint.

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 input parameters and no output schema, the description fully compensates by explaining what is returned (only_in_running and only_in_startup line lists), how to interpret empty results, and the security behavior around secrets. It is complete for an agent to call and interpret this 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?

The tool has zero parameters, so there are no parameter semantics to document. The description appropriately focuses on behavior and return values instead.

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 operation: diffing running-config against startup-config to identify unsaved changes. It names the exact return fields and semantics, making the tool clearly distinguishable from generic config-reading siblings like get_config.

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 to call it on demand rather than after every write, which is useful usage guidance. However, it does not name alternative sibling tools such as get_config or get_config_state, so the when-to-use-vs-alternatives guidance is incomplete.

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 declare readOnlyHint=false with destructiveHint=false, which is a slightly ambiguous safety profile. The description adds valuable behavioral context: 'RAM-only staging, no flash writes', clarifying that the write is non-destructive to persistent storage. It doesn't disclose auth requirements or overwrite behavior on the NAS path, 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?

Single efficient sentence, front-loaded with the action and destination, followed by clarifying parenthetical and rationale. 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?

A zero-param mutation tool whose annotations already carry safety hints. The description covers what, where, and why, and confirms non-destructive staging. Minor gaps: no mention of whether it overwrites prior dumps or the NAS path 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?

Zero parameters and 100% schema coverage, so the baseline is 4. The description adds context about what the operation targets (current router log to NAS backup path), leaving nothing for an agent to clarify.

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 (snapshot + rsync) and resource (router log to NAS backup path). Clearly distinguishes itself from the sibling get_log / get_log_by_device read tools, which merely retrieve logs, by emphasizing the backup-to-NAS action.

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 names the use case 'preserve the log before a reboot', giving a clear trigger condition. It does not name alternatives or when-not-to-use, but the usage context is concrete and actionable.

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 safety behavior is covered. The description adds the valuable non-annotation detail that the tool returns a recommendation (least busy channel) rather than raw scan data, which tells the agent what to expect from the result.

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 states action and outcome with no filler or redundancy. Every word 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 zero-parameter, read-only analysis tool whose annotations fully cover the safety profile, the description supplies the one thing structured fields do not: that the output is a channel recommendation. No output schema exists, and the description adequately characterizes the return value, though it could note the scope of the analysis (e.g. per-band or per-radio).

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 nothing to document and the baseline is 4. The description correctly avoids inventing parameter discussion that does not apply.

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 pairs a specific verb ('Analyze') with a specific resource ('WiFi channel congestion') and adds the concrete outcome ('recommend the least busy channel'). This clearly separates it from data-listing siblings such as get_wifi and get_site_survey, 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 statement of when to reach for this tool versus get_wifi, get_site_survey, or get_wifi_stations, all of which touch the same Wi-Fi domain. The 'recommend' framing implies the use case loosely, but no condition or exclusion is 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 declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description earns credit by disclosing a concrete return-field detail (the 'node' field identifying which mesh node a client is attached to), which is behavioral context annotations cannot supply.

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

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

Two tight sentences with the core purpose front-loaded and a useful return-value note appended. Every sentence earns its place; nothing is redundant with the title or annotations.

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 read tool with full annotation coverage, the description is nearly complete, and it helpfully surfaces the 'node' field since no output schema exists. Only a brief note on the returned client shape would make it fully self-sufficient.

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 no parameter syntax to explain and the description correctly spends no words on it.

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+resource: 'Get list of connected clients (devices) in the network.' The qualifier 'connected' implicitly separates it from the sibling get_unregistered_clients, but no sibling is named, 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?

There is no explicit when-to-use or when-not-to-use guidance; usage is only implied by the purpose itself and by the contrast with get_unregistered_clients. No alternatives are named for filtered or unregistered client 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 the description goes beyond that by disclosing a non-obvious behavioral trait: secrets (md5/nthash/psk/password/private-key) are masked unless include_secrets is true. That is exactly the kind of side effect an agent needs to know before trusting or forwarding the output.

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 sentences, front-loaded with the operation, then the important masking caveat, then actionable examples. No filler; every clause carries information an agent would otherwise have to guess.

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 read-only tool with a fully documented schema and no output schema, the description covers operation, safety-relevant masking behavior, and filtering guidance. Output format (raw config text) is only implied rather than stated, which is the one small 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 coverage is 100%, so the baseline is 3, but the description adds real value: concrete filter values that map to use cases, and the effect of include_secrets (unmasking secrets) beyond the schema's terse 'Return unmasked secrets'. Only the limit parameter is left entirely to 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+resource (read the router's running-config) and a clear scope qualifier (optional regex filter). It does not explicitly name siblings like get_config_state or the specialized getters, but the examples make clear that this is the raw config surface versus the structured per-feature 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?

The four filter examples ('ip static', 'access-list', 'ip dhcp host', 'ip http proxy') give concrete context for when and how to use the tool for specific data needs. It stops short of naming alternatives or stating when-not to use it (e.g., prefer get_port_forwarding over filtering config), so no exclusions.

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

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

Annotations already cover read-only/idempotent safety, yet the description adds genuine behavioral context beyond them: it warns that the raw fail-safe block's 'unsaved' field is NOT a save indicator and can read false while a save is in flight, steering the agent to the checksum instead. That is exactly the kind of non-obvious trait an agent needs.

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 parsed fields, then the caveat and the recommended usage. Three sentences all carry weight, though the em-dash clause is slightly dense.

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 and no parameters, the description fully carries the burden by naming the returned fields (last-change date in MSK and UTC, agent, user, checksum) and the unreliable field. Nothing an agent needs to interpret the response is missing.

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

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

The tool takes zero parameters, so there is no parameter semantics to document; baseline 4 applies. The description instead documents the shape of the return payload, which is a reasonable substitute.

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 (parses show/last-change to report when config was last touched, by whom, and its checksum) and enumerates the returned fields. It is clearly distinguishable from siblings like get_config (raw config) and diff_saved_config.

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 usage context ('the only reliable signal that a save has actually landed on disk') and an explicit invocation pattern ('Compare checksum across two calls'). It stops short of naming alternative tools 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that results are lease-holders with expiry, but says nothing about ordering, volume, or whether expired leases appear. With annotations doing the heavy lifting, this is adequate but thin.

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, no filler, with the core definition first and the sibling disambiguation second. 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?

There is no output schema, so the description's mention of expiry time is the only hint at return shape, and it is a useful one. For a parameterless read tool with full annotation coverage, that is close to sufficient; only result volume or ordering 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?

The tool takes zero parameters, so there is no parameter semantics to explain; baseline for a parameterless tool applies. The description correctly frames the output as an unfiltered list, which implicitly confirms there is nothing to pass in.

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 the precise resource (devices holding a lease from the DHCP pool) and what is returned alongside it (expiry time), which is more specific than the title. The verb is implicit rather than stated, but an agent can tell exactly what data this yields and how it differs from get_dhcp_static.

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 excludes fixed reservations and routes that case to the named sibling get_dhcp_static, which is the main ambiguity among the DHCP-related tools. It doesn't state the reverse condition (when to prefer get_dhcp_static over this), but that is strongly implied.

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 destructiveHint=false, so the safety profile is fully covered. The description adds only the content distinction (fixed bindings) and the CLI reference, with no mention of output format or pagination — adequate but modest added value 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 short sentences, front-loaded with what the tool returns and immediately followed by the disambiguating comparison. 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 zero-parameter list tool with annotations covering safety and no output schema, the description is nearly complete. Only the absence of any note about return shape or empty-result behavior 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, so the baseline is 4; there is nothing for the description to disambiguate and it does not misrepresent any inputs.

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 (static DHCP reservations), and adds the underlying CLI equivalent 'ip dhcp host' for grounding. It explicitly distinguishes itself from the sibling get_dhcp_leases, so an agent can select it without opening either schema.

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

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

It names the alternative tool (get_dhcp_leases) and the condition that separates them: dynamic pool leases vs. fixed bindings. That is clear routing guidance, though it stops short of an explicit 'use this when you need X' directive.

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. The description adds a genuinely useful behavioral disclosure beyond that: a missing proxy-status block is surfaced as an error rather than an empty list, which changes how an agent must handle the response. It also declares the parsing shape (domain/address) of static records.

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 dense clauses, front-loaded with the resource name. Every sentence carries distinct content: resolvers, static records, config tree, and the error-vs-empty behavior. Slightly clause-heavy but 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?

No output schema exists, so the description must describe the return value, and it does: upstream resolvers with DoT SNI, parsed A/AAAA records, and the ip host tree, plus the error semantics. Missing only pagination/size limits, which are unlikely for a single-status read. Adequate for a no-parameter status 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?

Zero parameters, so the schema cannot carry semantic load; per the rubric this is a baseline 4. The description correctly does not invent parameters and instead spends its words on the return shape, which is where the semantics actually live.

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+resource: 'DNS proxy status', then enumerates the exact sub-resources returned (upstream resolvers with DoT SNI, static A/AAAA records, ip host config tree). It distinguishes itself from siblings by content, but never references set_dns_host/remove_dns_host as the counterpart writers beyond mentioning them as consumers of the config tree it reads.

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: an agent can infer this is the read-side of the set_dns_host/remove_dns_host pair, and the mention of the 'ip host config tree' that those tools write to hints at the workflow. But there is no explicit 'use this when...' or exclusion of alternatives (e.g., get_config or get_config_state could overlap).

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 destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: extenders are auto-discovered and an omitted extender_ip fans out to all active extenders. No return format or pagination details, but solid for a read tool.

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 action and resource, followed by the discovery and default-scope behavior. No filler, though the final sentence partially duplicates the schema's extender_ip default.

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-required-param, read-only tool with fully documented parameters and no output schema, the description covers purpose, discovery, and default scope. Nothing critical is missing, though the absence of output/format expectations is a minor 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 coverage is 100%, so lines, filter, and extender_ip are already documented in the schema. The description's note that omitting extender_ip fetches from all extenders largely restates the schema's own 'default: all extenders' text, so it adds little beyond the 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 and resource ('Get system log from mesh extender(s)'), which scopes it to extenders and distinguishes it from the generic get_log/get_log_by_device siblings. It stops short of explicitly naming those siblings, so differentiation is inferred 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?

Explains the auto-discovery behavior and that omitting extender_ip fetches all extenders, which is useful context for calling it. However, it never says when to prefer this over get_log, get_log_by_device, or dump_log, leaving the sibling-routing decision 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 readOnlyHint, idempotentHint, non-destructive, and openWorld=false, so safety is covered. The description adds real value by disclosing what the read returns (access-lists with entries, IP firewall settings, interface access-groups), which is important 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?

A single front-loaded sentence with no filler; every clause enumerates a distinct category of returned data. It is appropriately sized for a zero-argument listing 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?

Given no parameters, a fully covered empty schema, and annotations that carry the safety profile, the description is nearly complete. It enumerates the returned categories, which is valuable absent an output schema, though it could mention return format or ordering/pagination for full completeness.

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. There is no parameter semantics to clarify, and the description does not need to compensate for any schema gaps.

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 (List) and resource (firewall rules) and even enumerates the sub-components returned: access-lists with entries, IP firewall settings, and interface access-groups. It clearly distinguishes itself from non-firewall siblings, though it does not explicitly name an alternative tool, which isn't necessary here since no sibling 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 'List' verb and the tool's no-argument, read-only nature, but the description offers no explicit when-to-use guidance, prerequisites, or reference to alternative tools. For a simple getter this is minimally adequate.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds the useful detail that results include traffic statistics, but does not describe output format or refresh 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 the verb and resource front-loaded. No filler or redundancy.

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

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

For a zero-parameter read-only tool with full annotation coverage and no output schema, the description is nearly complete. It could be slightly richer about what 'traffic stats' includes, but the safety and idempotency story is fully handled 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?

No parameters exist, which is the baseline 4 case. The description adds scope meaning ('status and traffic stats') that indicates what the tool surfaces, though there is nothing further to document.

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 ('network interfaces') with the scope of data returned ('status and traffic stats'), clearly distinguishing it from sibling tools like get_traffic or get_wifi. It does not name alternatives, but the resource 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?

No guidance on when to use this versus the many other get_* siblings. There are no parameters, so there is no filtering condition to explain, but the description offers no context about when an agent should prefer this over get_traffic.

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 covered. The description adds useful scope by saying only connections that are up are returned and by listing fields like external IP and default-route flag, but it does not describe the full return structure or edge-case 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?

Two short sentences with no wasted text. The resource and returned fields are front-loaded, and the sibling routing note follows immediately.

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

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

With zero parameters, no output schema, and rich safety annotations, the description provides enough context: it identifies the resource, lists the key returned fields, and points to get_system_info for related router-level information.

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 has zero parameters, so there are no input semantics to explain. The description appropriately spends its space on output field meaning instead, which is useful even though it is not required for 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?

The description states a specific resource and scope: internet connections that are up, with the returned fields listed. It also distinguishes this tool from get_system_info by assigning router firmware/load/uptime to that sibling, so an agent can identify the tool without opening schemas.

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 boundary by saying router firmware, load and uptime belong in get_system_info, which helps route the agent. It does not explicitly compare against other network-status siblings such as get_interfaces or get_vpn_status, so the guidance is clear but not exhaustive.

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 carried for free. The description adds genuinely new behavioral context: the data is read from running-config ('ip http proxy'), making it the authoritative source rather than a derived config. It does not describe return shape or ordering.

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, each earning its place: the first states scope and provenance, the second disambiguates from the nearest sibling. Front-loaded with the resource name and 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 zero-parameter, read-only listing tool with no output schema, the description covers purpose, provenance, and sibling differentiation adequately. It could be richer by sketching the returned fields (e.g. mapping name and target), but the annotations already cover safety and side effects.

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 disambiguate. The mention of 'ip http proxy' is a useful hint about the underlying config key but is not parameter guidance.

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?

Specifies the resource (KeenDNS / web-access mappings) and its source of truth ('running-config', 'ip http proxy'), which an agent can distinguish from siblings. It also explicitly names the closest sibling (get_web_access) and the differing data source, so no schema inspection is needed to tell them apart.

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 positions the tool against get_web_access by contrasting data sources (running-config vs generated nginx config), which implies when to pick each. It stops short of stating an explicit 'use this when / not when', so it is clear context rather than 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=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds no further behavioral context such as default output volume, truncation behavior, or whether the log is a fixed ring buffer and how far back it reaches.

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 capability stated first and the sibling routing second; no filler and nothing an agent doesn't need for selection.

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 read-only, zero-required-parameter log reader with full schema coverage and annotation-declared safety, this is close to sufficient. The remaining gap is that the description never contrasts with dump_log, a directly related sibling an agent may reasonably hesitate between.

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 is 3, but the description genuinely adds meaning the schema lacks by enumerating accepted time formats for since/until ('HH:MM', 'HH:MM:SS', 'Jul 24 08:00'). It does not similarly elaborate on 'lines' or 'filter', which is a minor omission.

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 system log entries') plus the notable property that entries carry timestamps. It also names the sibling that handles device-scoped lines, so an agent can distinguish get_log from get_log_by_device 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?

Explicitly routes the device-specific case to get_log_by_device ('For lines about one device (by MAC, IP or name)...'), which is a real when-to-use rule. It does not address the other log-related sibling, dump_log, leaving one plausible alternative unexplained.

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, non-destructive behavior, and the description adds meaningful context: device identity expansion and the absence of a time window. It does not cover return ordering or detailed output shape, but the annotations lower the burden and the added behavioral context is strong.

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 purpose and scope. The second sentence directly addresses the main alternative and exclusion. No wasted text.

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-only log retrieval tool with full schema coverage and rich annotations, the description is complete enough. It clarifies the device identity expansion behavior and explicitly redirects time-windowed log queries to get_log.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real semantic value for the required device parameter by explaining that a MAC, IP, or name is expanded to all known MACs, IPs, and names for that device. It adds no extra meaning for the lines parameter beyond the schema.

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

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

The description states a specific verb and resource: retrieve router log lines for one device. It also explains the key scope behavior, expanding the given MAC, IP, or name to all known identities for that device, which distinguishes it from a generic log retrieval 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 explicitly states when to use this tool versus the alternative: no time window, and for the whole log or since/until use get_log. This gives clear routing guidance without ambiguity.

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 establish readOnly/idempotent/non-destructive/non-open behavior, so safety is covered. The description adds real value beyond that by disclosing the shape of the result (per-drive fields and subsystem attribution), which matters since 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 resource and its reported fields, followed by a single usage note. No filler or redundant restatement of the title.

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-param read tool with no output schema, the description usefully enumerates return fields and gives a purpose (Entware drive health). It lacks only edge-case behavior (e.g. what is returned when no USB drive is present), a minor 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?

The tool takes zero parameters, so the schema is empty and parameter semantics are moot; baseline 4 applies. The description appropriately spends no space on nonexistent inputs.

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 (internal flash and USB drives) and enumerates exactly what is reported: partition UUID, label, filesystem, state, free space, and consuming subsystem. This clearly differentiates it from sibling read tools like get_opkg_status or get_system_info.

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

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

"Use it to check whether the Entware drive is healthy" gives a concrete when-to-use scenario. However, it does not name an alternative or state when this tool is the wrong choice (e.g. versus get_opkg_status for package state), so no exclusion guidance is present.

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, and destructiveHint=false, so the safety profile is fully covered. The description adds the useful detail that nodes include controller and extenders plus per-node metrics, but says nothing about result size, ordering, or what happens if no mesh system exists.

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 tight sentence that leads with the resource and then lists what each node exposes. Nothing is wasted and no critical information is buried.

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

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

With no output schema, the description must convey return content, and it does list the per-node fields an agent would care about. Coverage is strong for a zero-param read tool; only edge behavior (empty/unsupported mesh, ordering) 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?

The tool takes zero parameters, so there are no names or formats for the description to clarify; baseline 4 applies. Schema coverage is 100% with an empty property set, consistent with the description.

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 ('Mesh Wi-Fi system nodes') and enumerates the returned fields (client count, firmware, uptime, connection speed), so the agent knows exactly what this returns. It does not explicitly contrast itself with near siblings like get_wifi or get_clients, which is the only thing keeping it from 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?

The description gives no when-to-use guidance, no prerequisites, and no mention of alternatives among the many sibling list tools (get_wifi, get_clients, get_wifi_stations). Usage is only implied by the tool 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 readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine value beyond that by interpreting the output: a false opt_mounted value means the MCP server itself is at risk, which is non-obvious operational context an agent would not infer from annotations alone.

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, front-loaded with the resource and the reported fields before the diagnostic warning. Nothing is wasted, though 'borrowed time' is slightly figurative for a technical spec.

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 burden of explaining return values and does name the key fields (bound drive, initrc path, opt_mounted). Exact field names and formats are left to the actual response, but for a zero-parameter status tool this is close to complete.

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 nothing for the description to disambiguate and the baseline of 4 applies. The description instead spends its words on the result shape, which is the more useful place given no input exists.

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 (Entware/OPKG state) and enumerates exactly what is reported: bound drive, initrc path, and /opt mount status. That is specific enough that an agent knows precisely what this returns, though it relies on the tool name for the verb and no sibling is close enough to require differentiation.

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 explicit statement of when to call this versus other diagnostic tools such as get_system_info or get_config_state, and no prerequisites or ordering guidance. The 'borrowed time' sentence hints at why the result matters but does not tell the agent when to reach for this 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 and non-destructive, so the safety profile is covered. The description adds genuine context beyond them: the rules are read from running-config, meaning unsaved/active state rather than the saved config — relevant given the sibling diff_saved_config. It stops short of describing output format or count.

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 tight sentence, front-loaded with the action and resource, with no filler. 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?

For a no-argument, read-only list tool with no output schema, the description is essentially complete: it says what is listed and where it comes from. The only minor omission is the shape/scope of returned rules, which is not strictly required since no output schema exists.

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 nothing for the description to clarify; the baseline of 4 applies. No misleading parameter hints are present.

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) plus resource (port forwarding / static NAT rules) and even names the underlying config construct ('ip static'). It clearly separates from the mutation siblings set_port_forwarding/remove_port_forwarding, though it does not explicitly distinguish itself from the adjacent read-only get_firewall_rules.

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 listing intent implies when to use it, and naming running-config hints at the source of truth, but there is no explicit statement of when to prefer this over get_firewall_rules or when-not to use it. Usage is left to inference from the name and 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 cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantive behavioral context beyond them: it guarantees an explicit error instead of an empty list on read failure, and insists that 'no window configured' and 'could not read' be distinguishable. That failure-mode contract is exactly what a caller deciding on a reboot needs.

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 purpose and return fields before the error-behavior caveat. The second sentence is dense and slightly repetitive in restating the 'no window' vs 'could not read' distinction, but the content is not wasteful.

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, so the description carries the return-value burden itself and does so by naming the fields returned. Combined with the explicit error semantics, an agent has everything needed to call the tool and interpret its outcomes.

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 and schema coverage is 100%, so there is nothing for the description to compensate for; baseline 4 applies. The description correctly adds no redundant parameter discussion.

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 router schedules'), gives a concrete example (firmware auto-update window), and enumerates the returned fields (name, weekday/time actions, seconds until next fire). An agent can distinguish this from siblings like reboot or get_config 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?

Usage is implied rather than stated: the closing clause frames the tool as something 'a caller deciding whether it may reboot the router' consults, which hints at the reboot relationship. However, no alternative is named and no explicit when-to-use/when-not guidance is 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 declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety and side-effect profile is fully covered structurally. The description adds nothing beyond that, only restating the title; it never mentions that a scan may take time, may briefly disturb the radio, or what scope of results (own APs vs. neighbors) to expect.

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 no filler or redundancy, and the core action is front-loaded. It is appropriately sized for a parameterless call, though it is terse enough that nothing is elaborated.

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, read-only tool with no output schema and full annotation coverage, a short description is defensible, but the result shape (SSIDs, BSSIDs, channels, signal strength) and the fact that this is a live scan rather than a cached listing are left entirely 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 per the rubric the baseline is 4. There is nothing for the description to clarify on the input side, and it correctly implies the call needs no arguments.

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 ('Scan and list nearby WiFi networks'), so an agent knows it enumerates surrounding access points rather than configuring Wi-Fi. It does not, however, distinguish itself from siblings like get_channel_analysis, get_wifi, or get_wifi_stations, which all touch the wireless domain.

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 at all. The sibling set contains several plausibly overlapping Wi-Fi tools (get_wifi, get_wifi_stations, get_channel_analysis), and the description gives no condition for choosing this one over them or any prerequisite for invoking 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, non-destructive, and closed-world, so the safety profile is fully covered. The description adds useful scope (the fields it reports and what it does not report), but says nothing about response shape, caching/staleness, or auth requirements. With annotations doing the heavy lifting, a 3 is appropriate.

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 list is front-loaded and the sibling routing is placed immediately after it.

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 read tool with no output schema, the description does the essential job of telling the agent what comes back, which the schema and annotations do not provide. It stops short of describing the response structure or format, which would have made it fully complete.

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. The description correctly implies no input is needed and spends its words on output content instead.

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?

Enumerates the concrete fields returned (firmware, model, uptime, CPU load, memory, server version, boot time), which is more specific than a generic 'get system info'. It also differentiates itself from get_internet_status by name. It lacks an explicit verb, but the resource and returned content are 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?

It routes the agent away from this tool for internet connection and external IP, naming get_internet_status as the alternative. There is no explicit 'use this when' statement, but the field inventory plus the exclusion makes the intended use clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds scope (all active interfaces) and return content (rx/tx bytes), which is useful context beyond annotations, but does not disclose rate limits, auth needs, or failure 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?

Single sentence, front-loaded with verb and resource, no redundant words. It efficiently conveys the essential purpose and return data.

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 should convey return values. It states 'rx/tx bytes' and 'traffic summary for all active network interfaces', which is sufficient for a simple read-only getter, though it omits units or aggregation period.

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 has zero parameters, so the baseline is 4. The description does not need to compensate for parameter meaning, and the empty schema is fully adequate.

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 'traffic summary', with scope 'all active network interfaces' and data fields 'rx/tx bytes'. However, it does not explicitly differentiate from sibling tools like get_interfaces, which could also return interface data, so it falls 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?

No when-to-use guidance or alternatives are mentioned. The description states what it returns but not when to choose it over sibling tools such as get_interfaces or get_system_info, leaving usage 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 readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the scoping qualifier 'active but unregistered (unknown)', which is useful, but says nothing about what is returned or how 'active' is determined.

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 no filler and the key qualifier ('active', 'unregistered') front-loaded after the verb. Appropriately sized, though extremely terse.

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-argument read-only list tool with no output schema, the description is minimally sufficient, but it doesn't indicate what constitutes 'active' or what fields each entry carries, which an agent may need to act on the result.

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 nothing for the description to compensate for. Baseline 4 applies; no parameter semantics are needed.

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 list of') and resource ('active but unregistered (unknown) devices in the network'), and the parenthetical clarifies the meaning of 'unregistered'. It implicitly contrasts with the sibling get_clients but never names it, so sibling 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?

Usage is only implied: an agent can infer this is for inspecting unknown devices while get_clients covers known ones. There is no explicit when-to-use statement, no mention of the register_client follow-up, and no named alternative.

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's contribution is the scoping detail that all VPN interfaces across four protocols are returned, but it says nothing about permissions, refresh behavior, or the shape of the status payload.

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 sentence that front-loads the verb and resource and spends its remaining words on the protocol scope. No filler or redundancy.

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

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

For a parameterless read-only status tool this is nearly sufficient, but with no output schema the description could have said more about what 'status' contains per interface. It is complete enough to invoke correctly but not to interpret the result.

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. Schema coverage is 100% and there is nothing further for the description to disambiguate.

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 status of all VPN interfaces') and enumerates the covered protocols (WireGuard, IPsec, L2TP, PPTP), which sharpens scope. It does not explicitly distinguish itself from potentially overlapping siblings such as get_interfaces or get_internet_status, 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 get_interfaces, get_internet_status, or other connectivity checks. Usage is only inferable from the name; no context or exclusions are provided.

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 destructiveHint=false, so the safety profile is covered. The description adds meaningful context beyond them by disclosing what is inspected (the rules file actually read, the watcher's own RCI session state, last delivery error) and the operational intent of liveness checking. No auth, rate-limit, or failure-mode caveats are given.

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, purpose front-loaded, and the usage hint placed last. The per-rule field enumeration is dense and slightly list-heavy, but every item is informative given there is no output schema to carry it.

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 and no parameters, the description carries the full burden of explaining what comes back, and it does so thoroughly — process state, config provenance, session state, and per-rule counters/errors. An agent knows what it will receive 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a 0-param tool applies. The description instead spends its detail budget on the return contents, which is the right allocation.

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 opens with a specific resource ('background event watcher') and enumerates exactly what the status payload contains: running state, rules file read, RCI session state, and per-rule fields (source, poll interval, cooldown, next-poll seconds, counters, last delivery error). This is far more specific than the title and clearly separates it from siblings like test_watch_rule or get_log.

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

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

'Use it to check that a rule is alive without waiting for the event it watches for' gives a concrete trigger and implicitly contrasts with test_watch_rule (which would exercise a rule). It stops short of explicitly naming that alternative or stating when not to use this tool, so it is clear context rather than 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 non-destructive behavior, so the safety profile is covered. The description adds the non-obvious trait that results reflect the router's current generated configuration rather than stored intent, which is exactly the context an agent needs to interpret the output.

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, no filler, and the primary distinction (what this returns) is front-loaded before the pointer to the sibling tool. 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?

With zero parameters, no output schema and full annotation coverage, the description carries only the interpretive burden, which it meets by contrasting rendered config against configured mappings. The one residual gap is that the shape of the returned app entries is not hinted at, though that is minor for a no-arg read 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 tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No misleading parameter language is present.

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 (web apps published via KeenDNS) and a specific viewpoint (as the router serves them now, i.e. generated nginx config). It explicitly separates this tool from the sibling get_keendns_mappings, so an agent can pick correctly 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?

It states the condition that selects this tool (the live, rendered nginx config) and names the alternative (get_keendns_mappings) for the configured/upstream view. That is an explicit when-to-use and when-to-use-the-other pair in two sentences.

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 description help. The description adds the field set that comes back, which is genuinely useful since there is no output schema, but it omits whether results cover one radio or both bands and gives no rate/refresh 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?

A single front-loaded sentence with no filler; the verb and resource come first and the payload list follows. Every token 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?

With no output schema, the description is the only source of return-value information, and it does name the fields — helpful. But it leaves structural questions open (one radio vs. per-band results, units, whether station count is a list or a number), which matters for a status tool with several lookalike siblings.

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 nothing for the description to disambiguate; baseline 4 applies. Schema coverage is 100% with an empty properties object.

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 WiFi radio status') and enumerates the returned fields (channel, bandwidth, bitrate, temperature, stations count), so the agent knows exactly what this retrieves. However, it never distinguishes itself from closely-named siblings like get_wifi_stations, get_channel_analysis, or get_site_survey, which plausibly return overlapping WiFi data.

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

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

No when-to-use guidance is given and no alternative is named. The agent must guess whether to call this versus get_wifi_stations for station counts or get_channel_analysis for channel data.

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. The description adds value beyond that by enumerating the returned data (signal strength, traffic, device name, mesh node), which is the most useful behavioral context for a no-argument read tool lacking an 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?

A single tight sentence with the resource front-loaded and the useful return fields appended; every clause earns its place with 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 simple zero-param read tool with no output schema, the description supplies the key missing piece: what data comes back. Coverage is good, though it could note whether results are paginated or limited to the local mesh.

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; there are no parameter semantics for the description to clarify or omit.

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 (currently associated WiFi stations) plus the fields returned (signal strength, traffic, device name, mesh node). This distinguishes it from get_clients/get_mesh_nodes by scoping to associated stations, 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 word 'currently associated' implies the usage context (live wireless associations rather than all known clients), but there is no explicit when-to-use statement and no mention of alternatives such as get_clients or get_mesh_nodes for related queries.

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 covered. The description adds the underlying mechanism ('rsync --list-only'), telling the agent results come from the remote NAS listing rather than local state, which is meaningful extra context. It says nothing about result size or pagination.

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, no filler, with the core action front-loaded and the verification use case second. Nothing could be cut 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?

For a no-parameter, read-only listing with rich annotations and no output schema, the description covers what it does and why. The only gap is the shape of the result (filenames, paths, timestamps), which the absent output schema leaves unexplained.

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. There are no inputs whose semantics need explaining and the description correctly introduces none.

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 config backup files') and scopes it with 'already present on the NAS', which implicitly contrasts with the backup_config/backup_mcp_config siblings that create backups. It never names a sibling explicitly, 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?

'Confirms that scheduled backups actually arrived' gives a clear use case for reaching for this tool rather than creating a backup. There is no explicit when-not or named alternative, but the context is unambiguous.

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, but the description goes further by explaining WHY it cannot write (writing needs a POST body it never sends) and enumerating blacklisted scopes. This adds real context beyond the annotation flags.

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

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

Front-loaded with the core behavior and safety claim, then supporting detail. The path lists are a bit dense but each entry is functional; little waste overall.

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 and only two simple params, the description covers safety, purpose, alternatives, and scope limits. It does not describe the shape of returned data, but for an exploratory raw-query tool this is nearly complete.

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 both params are documented, and the description reinforces the config_tree purpose ('see write-shapes, e.g. ip/static'). The 'Useful paths' examples add practical guidance the schema doesn't, though it stops short of path syntax details.

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 ('Raw READ-ONLY query against the router's RCI tree') and the exact mechanism (GET /rci/show/<path>). It distinguishes itself from siblings by redirecting running-config to get_config, so an agent can separate it from the many get_* 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?

Gives explicit when-to-use ('explore state that has no dedicated tool yet') and when-not (the blacklist: running-config, crypto, ppp, user), and names the alternative for the blacklisted case (get_config). Routing guidance is 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 flag destructiveHint=true and idempotentHint=false, but the description adds what the annotation cannot: the effect is immediate, cannot be cancelled once started, and kills connectivity to this server until boot completes. That last point materially changes how an agent should sequence the call.

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, with the irreversible consequence front-loaded immediately after the action. Nothing repeats the title or annotations verbatim.

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-argument, no-output-schema, destructive action, the description supplies exactly the missing pieces: destructiveness is in annotations, and timing, irreversibility, and post-call unreachability are in the text. An agent has everything needed to call it safely.

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 nothing needs explaining; baseline is 4. The description correctly avoids inventing parameter discussion for an argument-free tool.

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 ('Reboot the router') in the first three words. Against a sibling list dominated by read-only getters and a few client/config mutators, there is no ambiguity about which operation this is.

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 by the severity warning; the description never says when this should be invoked versus avoided (e.g. only on explicit user request, prefer reconnecting Wi-Fi first). No alternatives are named, though the sibling list shows none perform a reboot.

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 destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is supplied structurally. The description adds nothing beyond that: it doesn't say what gets destroyed or overwritten (e.g. an existing DHCP host entry for that MAC), that re-registering is idempotent, or what happens on conflict — all of which matter for a destructive mutation.

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 the operation first and parameters second, with no filler. It is efficient, though the brevity is arguably under-specification rather than optimal concision.

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 destructive, idempotent mutation with no output schema, the description is too thin: it omits conflict/overwrite behavior, prerequisites, and any notion of what the caller gets back. The structured fields carry the safety profile, but the behavioral gaps remain.

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 mac, name, and ip with format examples. The description only restates these three fields at a high level and adds no extra meaning such as IP format, whether the IP must be inside the DHCP range, or uniqueness constraints.

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 verb (Register) and resource (device/client) and enumerates the inputs (MAC, name, optional static IP), which clearly separates it from sibling readers like get_clients or get_unregistered_clients. It does not, however, distinguish itself from the close sibling update_client or explain how it relates to set_dhcp_host.

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 and no comparison to alternatives such as update_client or set_dhcp_host, even though those siblings operate on the same client/DHCP concept space. The agent must infer the appropriate context from the name alone.

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 destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description nevertheless adds two pieces of behavior not in the annotations: that dry_run defaults to true (a partial-deletion guard) and that the removal is not self-reversible, requiring re-creation via set_dhcp_host.

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 terse sentences with zero filler, and the operation-plus-identifier is front-loaded before the safety default and the alternative tool. 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?

For a two-parameter destructive tool with full annotation coverage and no output schema, the description supplies everything needed to invoke it safely: the identifier, the dry-run default, and the recovery path. Only minor gaps remain, such as what a dry-run response returns.

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 both parameters are already documented with types. The description only restates that mac identifies the reservation and that dry_run defaults to true, adding no format or behavioral detail beyond the schema's own 'Default true' note. 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?

Specific verb (Delete) plus resource (static DHCP reservation) and the selector (by MAC) in the first clause. It also disambiguates from the sibling set_dhcp_host by framing that tool as the counterpart operation, so an agent can pick correctly 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?

The closing sentence 'Re-create with set_dhcp_host' tells the agent the alternative to reach for when the goal is creation rather than removal, and the dry_run note signals the default usage mode. It stops short of stating prerequisites or when removal is inappropriate, but the routing guidance is explicit.

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?

Goes well beyond the annotations by disclosing that dry_run defaults to TRUE — critical for a destructive tool — and that the address is resolved from the config tree because the router's removal form needs both fields. Annotations already flag destructive/idempotent, and the description adds the operational nuance that would otherwise cause a surprise deletion.

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?

Four short sentences, front-loaded with the action and the wire-level command, then the non-obvious caveats. 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 destructive, no-output-schema tool, everything needed is present: safety default (dry_run), parameter resolution rules, and the recovery path via set_dns_host. Nothing material 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%, so the baseline is 3, but the description adds real meaning: the address parameter's resolution-from-config behavior and the consequence of omitting it are explained rather than just 'Address, only needed if the name has several'.

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 ('Delete a static DNS record'), quotes the underlying CLI form, and distinguishes itself from the sibling set_dns_host by naming the inverse operation. An agent can tell exactly what this does.

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?

Explains the key conditional: address is normally looked up automatically and should be passed only to disambiguate a duplicated name. It also names set_dns_host as the re-create path, though it never mentions read-side siblings (e.g. get_dns_proxy/keendns mapping listing) for verification.

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 destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds genuinely useful behavior beyond that: protected names are refused, dry_run defaults to TRUE, and deletion can be reversed via set_keendns_mapping. It doesn't describe what the response contains or whether the mapping must already exist.

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?

Four short sentences, zero filler, with the core action front-loaded and the safety caveats immediately after. Every sentence contributes a distinct fact.

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 destructive two-parameter tool with no output schema and full annotation coverage, the description supplies the essentials: dry-run default, protected-name refusal, and a recovery path. Minor gap is the absence of any note on failure behavior for unknown names or what the tool returns.

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 both parameters are already documented, establishing a baseline of 3. The description reinforces dry_run's default and hints that name validity depends on protection status, but adds little syntax or format 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?

States a specific verb and resource ('Delete a KeenDNS mapping') plus the selector ('by name'), which cleanly differentiates it from get_keendns_mappings and set_keendns_mapping. An agent can identify the operation 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?

Points to set_keendns_mapping as the re-creation path and warns that protected names are refused, which implicitly tells the agent when this call will fail. It lacks an explicit statement of when to prefer this over alternatives (e.g., removing a stale mapping vs. modifying it), but the context is clear.

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?

Goes beyond the annotations (destructive, idempotent, not read-only) by disclosing refusal behavior on ambiguous matches and protected ports, plus the dry_run default that turns a destructive call into a preview. It doesn't say what the refusal or dry-run response looks like, which is the remaining gap for a destructive tool.

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?

Four short sentences, each carrying distinct information: action, selectors, safety constraints, and the recovery path. Key risk facts (dry_run default, refusals) are not buried.

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

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

For a 4-parameter destructive mutation with no output schema, the definition covers selection, safety refusals, the safe default, and the counterpart set tool. Only the shape of success/refusal results is unaddressed, which is a minor omission given annotations already flag destructiveness.

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 baseline is 3, but the description adds semantics the schema lacks: index originates from get_port_forwarding, port is the fallback selector, and dry_run being TRUE by default means a bare call is non-destructive. It leaves the protocol parameter's narrowing role to the schema alone.

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?

"Delete a port forwarding rule" names the verb and resource precisely, and the clause on index/port selection separates it from set_port_forwarding and get_port_forwarding. An agent can pick this tool without consulting any 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 index sourced from get_port_forwarding, or fall back to port, and use set_port_forwarding to re-create. It stops short of stating when not to use this tool (e.g. to disable rather than delete), but the alternative-tool pointers are concrete.

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 is fully covered. The description usefully adds that the probe originates from the router (not the caller) and that it returns latency and packet loss, but says nothing about blocking behavior, timeouts, or how a failure is reported.

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; purpose, origin, and result are all stated compactly with zero redundancy.

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

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

With no output schema, the description correctly steps in to say what is returned (latency and packet loss). For a two-parameter diagnostic tool with rich annotations this is nearly complete, though it omits failure semantics and timeout expectations.

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% for both parameters (host and count with its default of 4), so the schema carries the parameter burden. The description adds no syntax (IPv4/IPv6, hostname) or count-bound detail beyond what the schema already states, making the baseline of 3 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 states a specific verb (ping) and resource (host) plus the scope 'from the router' and names the observable results. It is unmistakably distinct from the get_* configuration siblings, but it never explicitly positions itself against other connectivity checks such as get_internet_status.

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 explicit when-to-use or when-not-to-use guidance and no mention of alternatives, even though sibling tools like get_internet_status and get_watch_status serve adjacent diagnostic needs. The use case is only vaguely inferable from the verb 'ping'.

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 destructiveHint=true and idempotentHint=true, so safety is partly covered. The description adds genuinely new behavior: the IP-uniqueness refusal rule and the fact that dry_run is TRUE by default, which materially affects how the agent calls it. No permissions or return-shape detail, but the added context is substantive.

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 action, then the failure condition, then the boundary with siblings, then the important default. Every sentence carries distinct information with 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 destructive, idempotent mutation with no output schema, the description covers what changes, the refusal condition, the default dry_run value, and where the sibling responsibility lies. It stops short of stating auth/permission requirements, but nothing essential to correct invocation is missing.

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

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

Schema coverage is 100% and each parameter is already described, so the baseline is 3. The description's note that dry_run defaults to TRUE duplicates the schema's own 'Default true' and does not add syntax or format detail beyond the schema; the uniqueness constraint touches the ip parameter only loosely.

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 pair ('Create or update') and resource ('static DHCP reservation') with the underlying config primitive ('ip dhcp host'). It also explicitly carves out the device-name concern as belonging to register_client/update_client, so an agent can separate it from the sibling tools without opening any 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 a clear routing rule: device NAME lives in the known-host tree, so use register_client/update_client for that. It also states a precondition (refuses an IP already reserved for a different MAC). It does not discuss the counterpart remove_dhcp_host or get_dhcp_static, but the key alternative is 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?

Adds substantial behavior beyond the annotations: dry_run defaults to TRUE, a real write persists to startup-config and is verified by re-reading the tree, and an existing name resolving elsewhere is refused rather than round-robined. This is exactly the mutation context an agent needs and is not duplicated by the annotation hints.

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

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

Front-loaded with the core action and the CLI form, then adds constraints. It is dense but every sentence earns its place; the split-horizon justification is the only mildly verbose element.

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 mutating tool with no output schema, the description covers persistence, dry-run default, verification, and failure mode. It could note the response shape or permission requirements, but what an agent needs to call it correctly is essentially present.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: the dry_run default and the round-robin rationale for why a conflicting name is rejected rather than extended. The CLI syntax mapping ('ip host <domain> <address>') further disambiguates domain and address roles.

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 (create) and resource (static DNS record), plus the exact CLI form ('ip host <domain> <address>'). It is clearly distinguishable from the sibling remove_dns_host and from set_dhcp_host, which covers a different record type.

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?

Explains the intended scenario (LAN half of a split-horizon setup) and gives a concrete prerequisite ('Remove the old record first'). It stops short of explicitly naming siblings like remove_dns_host as the routing alternative, but the when-to-use context is clear and actionable.

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 destructive=true, idempotent=true, readOnly=false; the description goes beyond them by warning that protected names (this server's own and MCP_PROTECTED_PROXY_NAMES) are refused in code and that dry_run is TRUE by default. That preview-by-default behavior is exactly the kind of safety context a destructive tool needs. It does not describe what happens on the actual write (e.g., whether an existing mapping is replaced wholesale).

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?

Dense and front-loaded: the resource and mapping shape come first, followed by the safety caveats. Every clause carries information, though the dry_run default is repeated from the schema and the parenthetical 'ip http proxy' adds density.

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, but for a destructive upsert with six fully documented parameters, the description covers effect (published on ndns domain with ssl redirect), safety (dry_run default, protected-name refusal) and idempotency. Missing only auth/permission requirements and post-write return behavior.

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

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

Schema coverage is 100%, so the baseline is 3; the description reinforces the name/host/port relationship and notes ssl redirect, but adds no syntax or format detail the schema lacks. Appropriate at 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 pair (create or update) against a named resource (KeenDNS web-access mapping / 'ip http proxy') and spells out the mapping shape (name -> host:port) plus where it is published. This clearly separates it from get_keendns_mappings and remove_keendns_mapping.

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 upsert semantics ('Create or update') imply that the tool is used whether or not the mapping exists, and the refusal of protected names is useful context. However, it never directs the agent to inspect existing mappings first via get_keendns_mappings or states when-not-to-use, so usage is only implied.

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 description substantially adds to the annotations by disclosing dry-run behavior, startup-config persistence, post-write verification, MAC/IP resolution and refusal, and protected-port refusal in code. This is rich behavioral context beyond the destructive/non-idempotent hints.

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 compact and front-loaded, with each sentence carrying concrete operational information. There is no filler or repetition.

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 destructive mutation tool with no output schema, the description covers the essential safety and behavior details: dry run, real-write persistence and verification, target resolution, and protected-port refusals. An agent has enough information to invoke it 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 coverage is 100%, so the baseline is 3. The description adds important meaning for key parameters: to_host accepts a MAC or registered-host IP with resolution/refusal, dry_run returns the payload without sending, and protected ports are blocked by code.

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: 'Create or update a port forwarding rule (\'ip static\')'. It is distinguishable from get_port_forwarding and remove_port_forwarding by the create/update framing, but it does not explicitly name or contrast with those sibling 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?

It gives clear operational context: to_host must be a MAC or an IP of a registered host, unknown targets are refused, dry_run defaults to true, and protected ports are refused. It does not explicitly map when to use this tool versus get_port_forwarding or remove_port_forwarding, but the create/update scope is clear.

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 declare readOnlyHint=false, destructiveHint=true and openWorldHint=true; the description adds the crucial context that credentials are masked in the render but real when sent, and that dry_run defaults to true (no send) versus dry_run=false (a real outbound call). This explains the practical safety envelope far beyond the boolean hints.

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 sentences, front-loaded with the action and purpose, then the masking caveat, then the dry_run semantics. No filler; each sentence carries distinct 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?

Two parameters, no output schema, and a tool whose side effect (a real outbound call) is the main risk. The description covers rendering, masking, and the behavior of both dry_run values, which is everything needed to invoke it 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 coverage is 100% (baseline 3), but the description adds meaning beyond the schema: what dry_run=false actually causes (a real HTTP call proving receiver reachability) rather than just 'render only, do not send'. rule_id gains no extra detail, hence not a 5.

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 a specific verb and resource ('Render a watcher rule's outbound HTTP call') plus the scope (with sample event values), which is clearly distinct from read-only siblings like get_watch_status or get_config_state. An agent can tell what it does 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 clear context: use it to inspect URL/headers/body before a real event fires, and dry_run=false is described as the way to prove reachability. It does not name alternatives or state when not to use it, but the when-to-use signal is strong and unambiguous.

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 destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the mutation profile is covered. The description adds the useful relationship to block_client but says nothing about permission requirements or what state changes/return value to expect, which is the 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?

A single short sentence, front-loaded with the verb and resource, and every clause adds information (the inverse operation and the addressing key). 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?

For a one-parameter toggle-style operation with full schema coverage and annotations covering safety and idempotency, the description is nearly sufficient. Only minor gaps remain (error behavior for unknown/unblocked MACs), and no output schema exists to clarify results.

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 an inline example (aa:bb:cc:dd:ee:ff), so the schema does the work. The description only identifies the MAC as the target selector, adding nothing 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?

Specific verb 'Unblock' plus resource 'a device blocked by block_client', with the addressing key (MAC) stated. An agent can distinguish it immediately from the sibling block_client and from update_client.

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 names block_client as the inverse operation, which effectively signals when this tool is appropriate. It doesn't state preconditions (e.g. what happens if the MAC isn't currently blocked) or explicit when-not-to-use 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=false, destructiveHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds only that the target must be a registered device and that the mutable fields are name and IP; it says nothing beyond annotations about reversibility, what overwriting an existing IP does, or auth needs.

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; the verb, mutable fields, and target scope all appear immediately.

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

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

For a destructive, idempotent mutation with no output schema, annotations cover safety and the schema covers all three params. The description is nonetheless thin: it omits what identifying key is used (mac), whether both fields can be updated together, and any effect on existing configuration.

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 mac, ip, and name with an example format. The description restates the mutable fields but adds no format, constraint, or optionality 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 verb (update) plus the exact fields (name, static IP) and the target (a registered device), which separates it from siblings like register_client, block_client, and remove_dhcp_host. It does not explicitly name a sibling to disambiguate against, 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?

The description gives no when-to-use or when-not-to-use guidance and names no alternative. An agent must infer from the word 'registered' that this is for already-registered clients rather than register_client, and nothing states prerequisites such as the device existing.

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