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?

Goes well beyond the annotations: it discloses the mirror refresh on every run, conditional dated snapshots, synchronous execution, a round-trip md5 verification of the mirror, and that staging happens in /tmp RAM with nothing written to the USB stick. These are exactly the operational traits an agent needs and none are derivable from the 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?

Four compact sentences, front-loaded with what is backed up and where, then behavior, then the safety detail about /tmp. No filler and every clause carries information.

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

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

With no output schema, the description compensates by describing what the tool reports ('reports what happened, including a round-trip md5 check of the mirror'), and it covers the one optional parameter and the safety profile. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning by explaining that the run performs a round-trip md5 check of the mirror, which is precisely what the 'verify' parameter toggles. That contextualizes the single flag beyond its terse schema text.

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') plus the exact resource and its distinctive scope: the keenetic-mcp files git cannot restore (.env, watch_rules.json, the Entware init script), and the destination (the NAS). This clearly separates it from the sibling backup_config, which targets router config rather than git-unrecoverable MCP state.

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

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

The phrase 'files that git cannot restore' implies the context (complementing version control for untracked secrets), and 'writes a dated snapshot only when the content changed' hints at when it is worth running. But it never explicitly says when to prefer this over backup_config or how it relates to list_backups, leaving the routing 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 destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered by structured data. The description adds only one behavioral detail beyond them — that the target must be a registered client — but says nothing about what blocking actually does (deny network access?), whether it persists across reboots, or how to reverse it.

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

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

One short sentence with zero waste; the action and its target/identifier are front-loaded and nothing is padded.

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

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

A single-required-param mutation tool with annotations and no output schema does not need much, but for a destructive operation the description leaves out the effect of blocking and the recovery path (unblock_client), which are the details an agent would want before calling it.

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

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

Schema description coverage is 100% and the single mac parameter is documented with a concrete example (aa:bb:cc:dd:ee:ff), so the schema carries the parameter burden. The description only restates 'by MAC address' and adds no format or validation 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 (Block) plus resource (registered client) and the identifier used (MAC address), so the agent knows exactly what the call does. It partially differentiates from siblings via 'registered client' (implying register_client must precede it) and contrasts implicitly with unblock_client, but never names those alternatives.

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

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

No when-to-use or when-not-to-use guidance. The word 'registered' hints that unregistered clients (see get_unregistered_clients) are out of scope, but the prerequisite is never stated, and the obvious alternative unblock_client is not referenced.

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), and the description adds non-obvious behavior: secrets are masked on both sides, the comparison is checksum-independent, and it is deliberately not invoked by write tools. This is real context beyond the structured fields.

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

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

Front-loads the core operation, then layers in return shape, masking, and usage timing. Four dense sentences with 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?

With no output schema, the description carries the return contract itself (only_in_running and only_in_startup line lists, both empty means fully saved), plus endpoint placement. An agent has everything needed to call and interpret 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?

Zero parameters, so there is nothing to disambiguate; baseline 4 applies. The description correctly does not waste space on parameter semantics.

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

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

States a specific verb+resource pair (diff running-config against startup-config) and frames the exact question it answers ('what is not saved yet'). This is clearly distinguishable from siblings like get_config, get_config_state, 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?

Gives explicit usage timing ('call it on demand, not after every write') and notes it is not wired into the write tools. It does not name a sibling alternative (e.g. get_config_state) for the 'what's saved' question, so it stops just short of full when/when-not/alternatives coverage.

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 fully covered elsewhere. The description adds only that results are 'active' leases and include expiry time — modest extra context. No mention of pagination, sorting, or what happens when no leases 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?

One short sentence with no filler, front-loaded on the resource. The phrasing 'Get list of' is slightly clipped/ungrammatical but costs nothing in clarity.

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 listing with no output schema, the description is sufficient: it identifies the resource and signals the returned field of interest (expiry time). It could note the return shape or empty-result behavior, but nothing needed to call it correctly is missing.

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

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

The tool takes zero parameters, so the schema baseline is 4. There are no argument 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?

Specific verb+resource: 'Get list of devices with active DHCP leases', plus a scope detail (expiry time). It is clearly distinguishable from get_dhcp_static (static reservations), though it never names a sibling explicitly.

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

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

No guidance on when to use this versus get_dhcp_static, get_clients, or get_dhcp_leases-adjacent siblings, and no prerequisites. The 'active' qualifier hints at scope but is not framed as usage advice.

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=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety and idempotency profile is fully covered. The description adds only the informational payload (connection status plus external IP), which is a modest increment over the structured data.

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

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

A single eight-word sentence with the payload front-loaded and no filler. Nothing wasted, nothing that could be trimmed.

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 place return values could be characterized, and it gives only a broad indication ('status and external IP') without the shape or fields an agent would see. The zero-param, annotation-covered nature keeps this from being a serious gap, but it is not 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 per the rubric the baseline is 4. There is nothing parameter-wise for the description to clarify or compensate for.

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

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

The description names a specific verb (Get) and resource (internet connection status and external IP), which is more precise than a bare 'get status'. However it offers no differentiation from adjacent read tools like get_system_info or get_interfaces, so an agent must infer the boundary.

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

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

There is no when-to-use guidance, no mention of alternatives such as get_interfaces or get_system_info, and no exclusions. The agent gets a purpose statement but no routing signal among the many sibling read tools.

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

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

Annotations already 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, and destructiveHint=false, so the safety profile is covered by structured data. The description adds useful behavioral context about time-window filtering and accepted time formats, but says nothing about default line counts, output ordering, or truncation limits.

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 core purpose and followed by the one non-obvious detail (time-window formats). 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 read-only, four-optional-parameter log tool with no output schema, the description covers purpose and the trickiest parameter formats. The remaining gap is the lack of differentiation from sibling log tools, which is more a usage-guideline issue than a completeness one.

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 genuinely adds meaning by giving concrete accepted formats for since/until ('HH:MM', 'HH:MM:SS', 'Jul 24 08:00') that the schema does not provide. It leaves the 'filter' and 'lines' semantics to the schema, which is 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 and resource ('Get system log entries with timestamps'), which is clear enough to act on. However, it does not distinguish itself from the closely related siblings get_log_by_device, get_extender_log, and dump_log, leaving the agent to guess which log tool to pick.

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 use this tool versus the other log-retrieval siblings. The description implies a general-purpose log read, but with dump_log and get_log_by_device present, the absence of routing guidance is a real gap.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds the filtering dimensions but says nothing about the default line count, output format, or behavior when the device is unknown, leaving gaps the annotations don't fill.

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 action front-loaded and no filler. Every clause carries information relevant to selecting the tool.

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

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

For a simple read-only lookup with full schema coverage and annotations carrying the safety profile, the description is essentially complete. It could go one step further by clarifying how it differs from the generic get_log, but nothing essential to 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 description coverage is 100%, so both parameters are already documented in the schema. The description's mention of MAC/IP/name merely restates the 'device' parameter, and the 'lines' parameter is not addressed, so no meaning is added beyond structured data.

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 filtering scope ('by device MAC address, IP address or name'). The 'by device' qualifier implicitly distinguishes it from the sibling get_log, though it never names that 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?

Usage is implied: reach for this when you need log entries scoped to one device rather than the whole system. No explicit when-to-use, no exclusions, and no reference to sibling tools like get_log or get_extender_log to disambiguate.

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 readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered without the description. The description adds only content scope — which metrics are returned — and says nothing about cost, freshness of uptime data, or whether the call is expensive on the device.

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 with the action front-loaded and the payload enumerated after the colon. No filler, no 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-parameter read with full annotation coverage and no output schema, the description supplies the one thing an agent needs — the shape of the returned data. It could go slightly further by noting this is a lightweight status snapshot versus a full config dump, but nothing essential is absent.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No parameter semantics are needed or missing.

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 ('Get router system info') and enumerates the exact fields returned (version, uptime, CPU, memory), which distinguishes it from neighboring reads like get_config_state or get_traffic. It stops short of explicitly contrasting itself with any sibling, so it lands at clear-but-undifferentiated.

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

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

There is no statement of when to reach for this tool versus the many other get_* diagnostics (get_internet_status, get_opkg_status, get_config_state). The use case is inferable from the field list, but no conditions, prerequisites, or alternatives are given.

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

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

Annotations already 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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds the meaningful scope qualifier that these apps are exposed via Keenetic DDNS, but says nothing about result size, pagination, or what an entry represents.

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. It is brief to the point of being slightly terse, but nothing is wasted.

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 list tool with full annotation coverage and no nested or required inputs, the description is nearly sufficient. A minor gap is that it does not hint at the shape of each returned entry, and no output schema exists to cover that.

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 of 4 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?

Names a specific verb (Get list) and a well-scoped resource: web applications exposed to the internet via Keenetic DDNS. This is distinguishable from nearby siblings like get_port_forwarding and get_keendns_mappings, though it does not explicitly contrast itself with them.

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 statement of when to use this tool versus the many other read-only getters, and no prerequisites or exclusions. The agent must infer usage entirely from the resource name.

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

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

Annotations already declare 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 declare destructiveHint=true, readOnlyHint=false, and non-idempotent behavior, so the safety profile is covered elsewhere. The description adds nothing beyond that, saying nothing about downtime, dropped client connections, or loss of unsaved configuration/runtime state.

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?

It is a single four-word sentence with no waste, but the brevity stems from under-specification rather than economy of expression. Nothing is front-loaded because almost nothing is said.

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, non-idempotent reboot with no annotations in the description and no output schema, an agent is left without any warning about service interruption or side effects. The definition is far too thin for a disruptive operation.

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 input schema has zero parameters with full coverage, so the description has nothing parameter-level to compensate for; per the zero-parameter baseline this dimension is inherently satisfied. Still, the description never confirms that the operation requires 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 simply restates the tool name and title ('Reboot the router') with no additional specificity about scope, target, or effect. It is a tautological echo of the structured fields rather than an independent statement of purpose.

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

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

There is no when-to-use guidance, no preconditions, and no reference to any sibling tool (e.g. when to reboot vs. inspect state with get_config_state or get_system_info). With a large sibling set of read-only getters, some differentiation was expected.

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 and idempotentHint=true, so the safety profile is covered by structured data. The description adds a genuinely important behavioral fact not in the schema defaults visible to a caller: that dry_run is TRUE by default, meaning the call is a no-op unless explicitly overridden. It does not describe auth requirements or side effects on active leases.

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, zero filler, with the destructive action front-loaded and the safety-relevant default immediately after. Nothing could be removed without losing signal.

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 mutation with full schema coverage and annotations carrying destructive/idempotent hints, plus no output schema to explain, the description covers the essentials including the dry_run safety default. Minor gaps remain around permissions and post-removal 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?

Schema description coverage is 100%, so both parameters are documented structurally, establishing a baseline of 3. The description restates the dry_run default (already in the schema) and clarifies that mac is the lookup key, adding marginal meaning only.

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 (Delete) and resource (static DHCP reservation) plus the keying field (by MAC). An agent can distinguish it from set_dhcp_host, get_dhcp_static, and remove_dns_host without inspecting 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?

Usage is implied by the name and verb, but there is no explicit when-to-use guidance, no mention of the setter counterpart (set_dhcp_host) for creating reservations, and no stated preconditions. Mentioning the dry_run default gives a hint about safe invocation, but routing guidance is absent.

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. The description adds genuinely useful context beyond that: dry_run defaults to TRUE (a safety-relevant default) and that the address is resolved from the config tree because the removal form needs both name and address.

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 compact sentences, front-loaded with the operation and command, then the address-resolution rule, then the dry_run default. 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?

No output schema, but the description covers the mutation semantics, the default-safe dry_run behavior, and the address-resolution rule, which is what an agent needs to invoke it correctly. An explicit note on permanence/reversibility would round it out.

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 meaning beyond the schema: it explains why 'address' is optional (auto-lookup, explicit only for disambiguation) and reiterates the dry_run default. This clarifies intent the terse schema descriptions do not.

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

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

States a specific verb and resource ('Delete a static DNS record') and even gives the underlying router command ('no ip host <domain> <address>'). This clearly distinguishes it from set_dns_host, remove_dhcp_host, 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?

Explains the key usage condition: the address is looked up automatically and should only be passed explicitly to disambiguate a name with multiple addresses. No explicit when-not or named alternative, but the operational 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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds two genuinely new facts: protected names are refused, and dry_run defaults to true, which materially changes how an agent should invoke the tool. It stops short of 5 because it never explains what dry_run=false actually does or whether deletion is recoverable.

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, zero filler, and the destructive scope plus the dry_run default are front-loaded. Every sentence carries information an agent needs before calling.

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 mutation with full annotation coverage and no output schema, the description supplies the essential constraint (protected names) and the safety default. It leaves a small gap in not clarifying the effect of flipping dry_run to false, which is the one behavior an agent must get right to complete a real deletion.

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 both parameters, establishing a baseline of 3. The description's note that dry_run defaults to TRUE largely restates the schema's 'Default true' and adds no syntax or format detail beyond 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?

States a specific verb and resource ('Delete a KeenDNS mapping by name'), which cleanly separates it from set_keendns_mapping and get_keendns_mappings. It does not explicitly name those siblings, 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?

The mention that 'dry_run is TRUE by default' hints at the safe-invocation workflow, and 'Protected names are refused' signals a failure condition. However, there is no explicit statement of when to use this versus set_keendns_mapping, nor any instruction on setting dry_run=false to actually commit the deletion.

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, but the description adds non-obvious guard behavior: ambiguous matches and protected ports are refused, and dry_run defaults to TRUE. It does not say whether the change is immediately applied/persisted or what a success response looks like.

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

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

Two sentences, no filler, with the action and selection mechanism front-loaded and the safety caveats and default in the second sentence. 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 destructive mutation with no output schema and full schema coverage, the description covers targeting, refusal conditions and the dry-run default. It leaves out the effect of a successful delete (persistence/immediacy) and required permissions, which would round it out.

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

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

Schema coverage is 100%, so the schema already documents all four parameters, setting the baseline at 3. The description adds provenance for index (it comes from get_port_forwarding) and reinforces the dry_run default, but adds nothing about protocol's tcp/udp narrowing or port/index precedence beyond what the schema states.

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 (Delete) and resource (port forwarding rule) plus the two selection keys (index or port). It is immediately distinguishable from set_port_forwarding and get_port_forwarding by naming the delete operation 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?

Explains how to target the rule and points at get_port_forwarding as the source of a valid index, plus warns that ambiguous matches and protected ports are refused. It stops short of stating when not to use this tool or naming an alternative removal path.

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 destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the mutation profile is covered. The description adds meaningful context beyond that: dry_run is TRUE by default (a safety-critical detail), protected names (MCP servers, Home Assistant) are refused in code, and the mapping is published with ssl redirect on the ndns domain. It doesn't mention permission requirements or what an update overwrites, hence not 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?

A single dense sentence that front-loads the core action and then appends the key safety facts (protected names refused, dry_run default). Efficient with no filler, though the parenthetical and colon-separated clauses make it slightly packed rather than ideally scannable.

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 tool with no output schema, the description covers the essential agent needs: what it changes, the safe-by-default dry_run behavior, and the protected-name guard. It omits what an update does to pre-existing fields and any auth requirements, but annotations carry the safety profile, so this is largely 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 description coverage is 100%, so the schema already documents all six parameters including defaults. The description restates the name->host:port mapping and the ssl/ndns publication semantics, adding some conceptual clarity, but no format, range, or validation details beyond what the schema provides. Baseline 3 applies.

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

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

States a specific verb+resource ('Create or update a KeenDNS web-access mapping') plus the underlying RCI concept ('ip http proxy') and the exact data flow (name -> upstream host:port, published on the ndns domain with ssl redirect). This clearly distinguishes it from the sibling readers get_keendns_mappings and the mutator 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 description implies usage (create/update a web-access mapping, dry_run defaults to TRUE, protected names are refused), which gives the agent useful operating context. However it never states when to choose this over alternatives like set_port_forwarding or set_dns_host, nor when-not to use it, so guidance is implied rather than 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?

Adds substantial context beyond annotations: dry_run defaults to TRUE and returns the payload without sending, a real write persists to startup-config and is verified by re-reading the tree, and endpoint ports are refused in code. This meaningfully qualifies the destructiveHint and non-idempotent 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?

Four tight sentences, front-loaded with purpose, then targeting rules, then the dry_run safety default, then refusal behavior. No sentence is redundant or padding.

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 9-parameter mutation tool with no output schema, the description covers the critical agent-facing facts: default-safe dry_run, persistence/verification behavior, target resolution, and code-level refusal. Nothing essential for 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 already 100%, so the baseline is 3, but the description adds real semantics: to_host resolution behavior (MAC vs registered-host IP, refusal on unknown) and the exact default and effect of dry_run, which the schema only labels 'Default true'.

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 or update) and resource (port forwarding rule, aliased to 'ip static'), and contrasts implicitly with get_port_forwarding and remove_port_forwarding in the sibling list. 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 usage conditions: pass to_host as MAC or as an IP of a registered host (resolved, refused if unknown), and notes that MCP-endpoint ports are refused in code. It does not explicitly name an alternative tool for viewing or removing rules, so it stops short of full when/when-not routing.

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

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

Annotations 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 the safety profile (readOnlyHint=false, destructiveHint=true, idempotentHint=true, openWorldHint=false), so the mutation and repeatability semantics are covered structurally. The description adds only the 'previously blocked' state constraint; it does not explain that unblocking restores network access, whether it requires admin auth, or whether the change is immediate.

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 clause that front-loads the action, the target, and the identifier. No filler, nothing repeated from 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 one-parameter tool whose annotations already carry the safety and idempotency profile and which has no output schema, the description is nearly sufficient. The only real gap is the absence of the block/unblock relationship to sibling tools, which an agent could infer but not confirm from this text alone.

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

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

Schema coverage is 100% and the single mac parameter is already documented with a concrete example format (aa:bb:cc:dd:ee:ff). The description names the MAC address as the lookup key but adds no format or matching nuance beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb ('Unblock') and resource ('client') plus the identifying key (MAC address), which cleanly separates it from the sibling block_client. It stops short of naming the sibling tool or its inverse, so differentiation is inferable rather than explicit.

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

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

The phrase 'previously blocked client' implies the precondition for use, but there is no explicit when-to-use guidance, no mention of the block_client counterpart that creates the state being undone, and no exclusions or prerequisites such as required permissions.

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.