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

No annotations are provided, so the description carries the full burden, and it does disclose key behaviors: backup, rollback timer, stop on first error. It omits what dry_run defaults to and how errors are surfaced, so it is strong but not complete.

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, front-loaded with the core purpose and then the safety behavior. 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?

An output schema exists, so return values need not be explained. But for a high-risk mutation tool with zero schema coverage and no annotations, the description should say more about dry_run, rollback semantics, and the run_command boundary.

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 0%, so the description must compensate and it partly does by implying the commands parameter is a one-command-per-item list. But the more consequential parameters (dry_run default true, rollback_minutes, name, description) get no explanation, leaving a meaningful gap.

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

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

States a specific verb+resource: apply arbitrary RouterOS commands. The routing note 'when no dedicated tool fits' distinguishes it from run_command and other siblings, though the exact boundary between apply_changes and run_command is somewhat blurry.

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 condition: use when no dedicated tool fits. That is a genuine when-to-use gate. It does not, however, explain when to prefer run_command or the other command-oriented sibling, leaving one ambiguity.

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

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

With no annotations, the description carries the full burden, and it does disclose the read-only nature plus the side effect of optionally writing a report to ~/mikrotik-sites/<site>/. However, it says nothing about required permissions, connection/session prerequisites, runtime cost, or error behavior for a multi-check audit.

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 purpose, then a dense enumeration, then the optional save behavior — no filler sentences. The list is long but each item is a distinct audit domain, so it earns its length.

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

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

An output schema exists, so return values need not be described, and the description thoroughly covers the audit scope. The remaining gap is parameter meaning (name/site) and connection prerequisites, which is minor given the output schema carries the payload structure.

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 0% and both parameters are undocumented in the schema, so the description must compensate. It clarifies that 'site' selects the save destination path, but the 'name' parameter (defaulting to 'router') and its relationship to session/device selection are never explained.

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 ('Read-only security audit') and enumerates the exact resources inspected (version, users, firewall, DNS resolver, compromise indicators, etc.). The 'read-only' qualifier implicitly separates it from mutating siblings like harden_services, firewall_baseline, and apply_changes, so an agent can route without opening a schema.

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

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

Usage is implied by 'read-only audit' and the optional report-saving behavior, but the description never states when to prefer this over collect_info, router_overview, or validate_network, nor when not to use it. No explicit alternative routing is 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?

With no annotations, the description carries the full burden, and it does contribute the key behavioral facts: it writes files to disk and the operation is read-only against the device. However, it omits permission/auth requirements, how long the collection takes, and whether it overwrites existing snapshots in the timestamped directory.

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 compact sentence that front-loads the action and the destination, with no filler. Slightly terse at the cost of the parameter guidance an agent needs.

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

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

An output schema exists, so return values need not be described, and the file destination plus 'Read-only' cover the essentials. Still missing is any explanation of the undocumented 'name' parameter and the usage relationship to sibling tools.

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

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

Schema description coverage is 0%, so the description must compensate. It references <site> through the path template but says nothing about the 'name' parameter or its 'router' default, leaving half of the parameter surface unexplained.

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 concrete verb (save) and enumerates the resource set it captures (full export, hardware/status/Wi-Fi/VPN/firewall info) plus the destination path template. That is more specific than the sibling router_overview, but the description never explicitly contrasts itself with that or run_command, so an agent must infer the difference.

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 says what will be saved but never when to choose this over router_overview or run_command, nor whether it should precede audit_security/validate_network. Usage is only implied by the output 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?

With no annotations, the description carries the full burden. It does disclose genuinely useful behavior: a typed password is never returned to chat and is saved under ~/mikrotik-sites/<site>/, generated passwords appear only in a local popup, and mixed WPA2-WPA3 falls back to WPA2 on the legacy driver. However, for a mutation tool it omits critical behavioral facts: whether changes take effect immediately or must be committed via apply_changes/confirm_changes, and how dry_run (default true) and rollback_minutes actually behave.

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

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

The purpose is front-loaded in one sentence, followed by a scannable parameter list. Every sentence carries information; there is no filler. Slight deduction for the trailing driver-compatibility note being placed last rather than near the security parameter it qualifies.

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

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

The output schema exists, so return values need not be described. But for an 11-parameter mutation tool with no annotations, the description leaves material gaps: the dry_run/rollback and apply/confirm workflow is unclear, and five parameters go unexplained. It covers the security-sensitive password handling well but is not complete enough for confident invocation.

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

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

Schema description coverage is 0%, so the description must compensate for 11 parameters. It does well on the risky ones: password modes, generate_password, security enum values (wpa2 / wpa2-wpa3 / wpa3), interfaces default 'all', and country. But name, site, dry_run (notably defaulting to true, meaning no change is applied unless overridden), ensure_ap_mode, and rollback_minutes are never explained, leaving the mutation-safety parameters undocumented in both schema and prose.

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 verb+resource: 'Set SSID and Wi-Fi password on the router's Wi-Fi interfaces.' That is unambiguous about what the tool changes. It does not, however, distinguish itself from the nearby sibling setup_bridge_with_wifi_subnet, which also touches Wi-Fi configuration.

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 through parameter guidance ('leave empty to have the user type it in a local popup (preferred)', 'country: ... Recommended on first setup'), which tells the agent something about when certain options are appropriate. But there is no explicit statement of when to choose this tool over setup_bridge_with_wifi_subnet, apply_changes, or confirm_changes, nor any preconditions such as an active session.

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

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

With no annotations, the description carries the full burden, and it does disclose two real behaviors: the rollback safety net is removed and the config is persisted locally. However it omits irreversibility, scope of persistence, and any permission/auth context, leaving meaningful gaps for a commit-like operation.

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 compact sentence with the action front-loaded and the side effect trailing; every clause carries information 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?

An output schema exists so return values need no explanation, and the workflow position is clear. Still, the lone parameter is unexplained and the behavioral profile of a config-committing action is thin, so the definition is adequate rather than 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 0% and the single 'name' parameter (default 'router') is never mentioned or explained in the description. An agent cannot tell from the text what 'name' selects or how it interacts with the saved config, so the description fails to compensate for the coverage gap.

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

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

States a specific verb+resource pair ('Disarm the rollback') with a concrete effect ('saves the new config locally'), which clearly separates it from rollback_now and apply_changes even though those siblings are not named. It is more precise than most, but stops short of explicitly contrasting with the sibling tools.

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

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

'after verifying the change works' supplies a clear trigger condition that places this step in the change workflow, implicitly distinguishing it from rollback_now. There is no explicit when-not or named alternative, so it is short of a 5.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose one valuable trait: an empty password triggers a local popup so the secret never enters the conversation. However, it omits authentication requirements, whether the session persists, and failure/interactive-prompt behavior.

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

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

Two tight sentences with the core action front-loaded and the password caveat immediately after. The parenthetical rationale is short and earns its place by explaining why.

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

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

An output schema exists, so return values need not be described. Still, for a session-establishing tool with zero annotations and 0% schema coverage, the description leaves lifecycle questions open: relation to 'reconnect'/'disconnect', auth mode, and what happens on failure.

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

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

Schema description coverage is 0% across 5 parameters, so the description must compensate and only partially does. It clarifies 'name' (router identifier) and 'password' (leave empty for prompt), but 'host' — the sole required parameter — plus 'port' and 'username' are left entirely unexplained.

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: 'Open an SSH session to a router'. It is clear what the tool does, but does not distinguish itself from the sibling 'reconnect', which is a near-neighbor an agent could easily confuse with this one.

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 operational guidance for the password parameter (leave empty to trigger a prompt), but says nothing about when to use this versus 'reconnect', 'discover_routers', or whether a session must be opened before 'run_command'. Usage is implied rather than stated.

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

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

No annotations are provided, so the description carries full behavioral burden. It discloses one key trait — credentials are forgotten — but does not state whether the operation is destructive, reversible, or requires specific permissions. This partial disclosure is useful but incomplete.

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

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

The description is a single front-loaded sentence with zero waste. Every word contributes to the core action and its side effect.

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

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

For a tool with a parameter and no annotations, the description is too minimal. It omits how to specify the target session and when this operation is appropriate, though the presence of an output schema means return values need not be explained.

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

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

Schema description coverage is 0% and there is one parameter ('name', default 'router') that is never mentioned in the description. The description says 'a session' without indicating that the parameter selects which session to close, so it fails to compensate for the schema gap.

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

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

States a specific verb ('Close') and resource ('a session') and adds a behavioral consequence ('forget its credentials'). However, it does not explicitly differentiate from siblings like reconnect or connect, so it meets the 'clear but no sibling differentiation' bar for 4.

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 is provided on when to use this tool versus alternatives such as reconnect or connect. There are no exclusions or prerequisites mentioned; an agent must infer usage 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?

No annotations are provided, so the description carries the full burden. It implies a read-only, time-bounded multicast probe (MNDP), but does not state that it blocks for a dwell period, that it requires multicast-capable local network access, or whether it disrupts anything. Key behavioral facts are left unstated.

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 tight sentence, zero waste, with the mechanism and the familiar Winbox analogy front-loaded. Nothing to trim.

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?

Return values are covered by the output schema, so the description needn't describe results. However, for a network-discovery probe with no annotations, the absence of timeout behavior and network preconditions leaves the definition only minimally 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 0% and the single parameter 'seconds' (default 5) is never mentioned in the description. The title alone hints it is a duration, but the description does not explain that it controls how long discovery listens, which matters for latency expectations.

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 (Find), resource (MikroTik devices), scope (local network) and mechanism (MNDP, with a Winbox Neighbors analogy). No sibling tool performs discovery, so an agent can distinguish it readily, though the description never explicitly contrasts itself with siblings like connect or list_sessions.

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 discovery versus alternatives, nor any prerequisite such as needing to be on the same L2 network before calling connect or reconnect. Usage is only inferable from 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?

With no annotations, the description carries the full burden and does well: it discloses the abort-on-existing-rules behavior, the tag-based rule preservation, NAT masquerading, and the different treatment of forward vs input chains. It omits the safety semantics of dry_run and rollback_minutes, which matter for a mutation 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?

The purpose leads and the rule groups are laid out as a structured, scannable list with no filler. It is longer than typical but every line conveys concrete configuration behavior rather than 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?

An output schema exists, so return values need no explanation, and the behavioral narrative is rich. The gap is parameters: with 0% schema coverage and no annotations, the description should clarify dry_run and rollback_minutes for a destructive firewall rewrite but does not.

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

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

Schema description coverage is 0% and seven parameters exist, yet the description only explains replace_existing. name, add_nat, dry_run, wan_interface, lan_interfaces, and rollback_minutes are left entirely undocumented, forcing the agent to guess at their meaning and defaults.

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 ('Apply a MikroTik-defconf-style IPv4 firewall') and enumerates the exact input/forward/nat rules, so the agent knows precisely what will be configured. It does not, however, contrast itself with nearby siblings like harden_services or audit_security, leaving the agent to infer the distinction.

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?

Provides a useful conditional: the tool stops and lists existing filter rules if any are present, and replace_existing=True overrides this while preserving mcp-wifi/mcp-wg rules. But it never states when to prefer this over siblings such as harden_services or audit_security, so usage is only implied.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose two genuinely useful traits: SSH can never be disabled here, and restrict_mgmt_to is refused if this machine's IP is outside the listed subnets. However it says nothing about the mutation/rollback nature of the operation (rollback_minutes defaults to 5), permission needs, or what happens to the other eight 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?

Three dense clauses, no filler, and the most consequential constraint (SSH/Winbox staying on) is stated up front. Tightly written for the amount of parameter-relevant information it packs in.

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 10-parameter configuration-changing tool with no annotations, the description leaves major gaps: rollback behavior, the meaning of dry_run, and eight boolean flags are undocumented. An output schema exists so return values needn't be described, but the mutation-safety picture is incomplete.

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

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

Schema description coverage is 0% across 10 parameters, so the description must compensate. It does so well for disable_services (explicit default list) and restrict_mgmt_to (comma-separated, '/prefix' or dotted mask, with a refusal condition), but leaves eight parameters – including the safety-relevant rollback_minutes and dry_run – entirely unexplained.

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?

"Common hardening" names a broad activity rather than a specific verb+resource, but the disable_services and restrict_mgmt_to clauses make the actual effect (disable named services, restrict management subnets) inferable. It never distinguishes itself from close siblings such as firewall_baseline or audit_security, so an agent cannot tell which one is appropriate without more context.

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 with firewall_baseline or audit_security, which appear to be the nearest alternatives. The only usage-like statement is "ask the user" for restrict_mgmt_to, which is a narrow interaction hint rather than selection 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?

No annotations are provided, so the description carries the full behavioral burden. It says only that it lists open sessions; it does not confirm read-only safety, explain the meaning of 'open,' mention pagination or filtering behavior, or disclose any other operational traits.

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

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

The description is a single, front-loaded sentence with no wasted words. For a simple zero-parameter list tool, it is appropriately sized.

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?

Because an output schema exists, return values need not be explained in the description. However, with no annotations and no usage context, the description is only minimally complete; it does not clarify what sessions are or when an agent should use this tool.

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

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

The tool has zero parameters and schema description coverage is 100%, so there are no parameter semantics to document. Per the rubric, zero parameters establish a baseline of 4.

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 ('open router sessions'), making the basic operation clear. It does not, however, explicitly differentiate this tool from sibling tools such as router_overview or connect, 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?

There is no guidance about when to use this tool versus alternatives. The description gives no prerequisites, no context about what an 'open session' is, and no indication of when listing sessions is appropriate.

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

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

With no annotations, the description must carry the full burden. It usefully discloses that credentials are reused (no auth prompt needed) and that re-homing to a new host is possible, but says nothing about what happens to the prior connection, failure modes, or whether the change is reversible.

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 scope ('reusing stored credentials') and the optional argument are both packed efficiently into one line.

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

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

An output schema exists, so return values need no explanation, but for a state-changing connection tool with zero annotation coverage the description is thin on prerequisites and side effects. It covers the basics but leaves an agent guessing about session state and error behavior.

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

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

Schema coverage is 0% for both parameters. The description only glosses the `new_host` parameter as 'optionally to a new IP' (and calls it IP where the schema says host), and never mentions the `name` parameter or its default of 'router', so it fails to compensate for the coverage gap.

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

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

States a specific verb (reconnect) and resource (a session), plus the key differentiator from plain `connect`: it reuses stored credentials and can optionally target a new host. An agent can distinguish it from siblings like connect/disconnect, though it never names 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?

Usage is implied rather than stated: the 'reusing stored credentials' clause suggests it applies when an existing session's credentials are still valid, but there is no explicit when/when-not guidance and no named alternative (e.g. use `connect` when credentials have changed).

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the action is immediate and forces a router reboot, which is a significant side effect. However, it does not state whether the rollback is destructive, irreversible, requires elevated permissions, or what downtime 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?

Two short sentences with zero waste. The primary action is front-loaded, and the reboot warning follows immediately, making the definition easy to parse at a glance.

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

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

The tool is a simple mutation with an output schema, so return values need not be explained. However, the description omits key usage context and completely ignores the one parameter, leaving the agent without guidance on when to invoke it or what the 'name' argument does.

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

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

Schema description coverage is 0% for the single 'name' parameter, and the description does not mention or explain it at all. The default 'router' is in the schema, but the description adds no meaning about what the parameter selects or how it affects the rollback.

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 ('restore') and resource ('pre-change backup'), and adds the critical side effect that the router reboots. It is clear what the tool does and how it differs from passive read or configuration tools, though it does not explicitly name sibling 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 guidance is given on when to use this tool versus alternatives such as apply_changes, confirm_changes, or run_command. The word 'Immediately' implies urgency, but there are no conditions, prerequisites, or exclusions stated.

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

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

With no annotations, the description must carry behavioral disclosure. It implies a read-only overview and gives a sequencing prerequisite, but it does not explicitly state safety, permissions, side effects, or output behavior.

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

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

Two short sentences, front-loaded with the most important information and no wasted wording. The usage instruction is succinctly appended.

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 overview tool with no output schema, the description lists the returned fields and gives a usage cue. However, it omits parameter semantics and does not compensate for the lack of 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?

The schema has one parameter, 'name', with 0% description coverage, and the description does not mention the parameter at all. An agent cannot tell whether 'name' selects the router, a device, or something else.

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 enumerates the specific resources returned: version, board, interfaces by type, Wi-Fi driver, bridges, and interface lists. That makes the tool's purpose clear, though it is a noun list rather than an explicit verb and does not differentiate itself from sibling tools like collect_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?

It gives a clear usage rule: 'Call this before planning any change.' This tells the agent when to invoke it, but it does not name alternatives or state 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?

No annotations are provided, so the description carries the full behavioral burden. It clearly discloses the READ-ONLY boundary and warns that changes belong elsewhere, but it omits prerequisites such as an active session/connection and does not explain what makes a command read-only or how errors are surfaced.

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 zero waste. The critical READ-ONLY constraint is front-loaded, and the alternative routing sentence earns its place.

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

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

An output schema exists, so return values need not be described. However, with no annotations and 0% schema coverage, the description should still cover session/connection prerequisites and clarify the command parameter; those gaps leave it only adequate.

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

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

Schema description coverage is 0% and the description never mentions the command or name parameters. The command examples hint at valid values, but the description does not explain that command is the RouterOS command string to execute or what the name parameter selects.

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: run a READ-ONLY RouterOS command, with examples like print, export, monitor, and ping count=4. It also distinguishes itself from write-oriented siblings by directing changes to dedicated tools or apply_changes.

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 says when to use it, for read-only commands, and when not to, for changes. It names the alternative apply_changes and other dedicated tools, so an agent can route correctly without 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?

With no annotations, the description carries the full burden and does well: it discloses the hardware-offload caveat for VLAN mode on non-CRS3xx models, the traffic-blocking effect of isolate_wifi_from_lan, and the dry-run confirmation flow. It omits any explanation of rollback_minutes and its 5-minute safety window, which is a notable behavioral gap for a disruptive 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?

The parameter-by-parameter bullet structure is front-loaded and dense; each line carries format, default, or effect information rather than filler. It is long but nearly every sentence 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 15-parameter disruptive network mutation with no annotations, the description covers most decision-relevant behavior and an output schema exists so returns need no explanation. The main omission is the rollback_minutes safety mechanism and the exact semantics of dry_run, which an agent would want spelled 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 0%, so the description must compensate, and it does explain formats and semantics for wifi_gateway, lan_address, dhcp_range, mode, wan_interface, lan_ports, wifi_ports and isolate_wifi_from_lan. But roughly half the parameters (dhcp, name, bridge, dry_run, wifi_bridge, wifi_vlan_id, rollback_minutes) get no meaning at all, so the coverage is only partial.

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 with scope: bridge all LAN ports and Wi-Fi, with Wi-Fi on its own subnet. This is clearly distinguishable from siblings like configure_wifi or firewall_baseline 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 strong operational guidance: wifi_gateway is REQUIRED and must be asked of the user, lan_address only when changing the LAN gateway, and defaults must be confirmed with the user. It does not, however, name a sibling alternative or state when this tool should not be used.

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

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

With no annotations, the description carries the full burden and discloses useful behavioral traits: it checks overlap against connected router session subnets, accepts multiple input formats, and reports detailed network calculations. It does not explicitly state that it is read-only or list permission requirements, but its validation framing makes the non-destructive nature clear.

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

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

The description is front-loaded with the core purpose, then details formats, purpose values, and reporting behavior. Every sentence adds useful information, and the examples are compact and directly relevant.

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?

Despite low schema coverage and no annotations, the description covers input formats, parameter semantics, conditional behavior, and reporting output. Since an output schema exists, it does not need to fully define return values, and the description is complete enough for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it documents value syntax with examples, comma-separated input, the meaning of purpose='interface' and purpose='network', and the conditional overlap behavior when name is a connected router session. All three parameters are given meaning beyond the bare schema.

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

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

The description states a specific verb ('Check') and resource ('IP addresses / subnets') and frames the tool as a pre-use validation step, which clearly distinguishes it from sibling tools that configure or apply changes. It also explains the user-facing purpose of explaining results.

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

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

It explicitly says to use this tool BEFORE using the addresses, giving a clear usage context. It also explains the meaning of purpose='interface' vs purpose='network', though it does not name alternatives or explicit 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?

With no annotations, the description carries full behavioral burden and does well: it discloses that keys are never generated server-side, that preshared keys are entered via a local popup (not chat), that public_key is validated against the router's own key and existing peers, and that empty public_key yields a template. It does not explain dry_run semantics, rollback_minutes behavior, or the apply/confirm/rollback workflow from the sibling tools, which are significant for a mutation 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?

The description is front-loaded with the core action and then uses a clear field-by-field list that is easy to scan. It is somewhat long, but every line maps to a parameter or a behavioral rule, so it largely earns its space. Slightly dense but well organized.

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

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

An output schema exists, so return values needn't be explained. Still, for a 16-parameter mutation tool with no annotations and 0% schema coverage, the description leaves several parameters (dry_run, rollback_minutes, name, site, comment, persistent_keepalive) unexplained. The core peer-creation flow is covered, but the gaps on operational parameters reduce 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?

Schema description coverage is 0% and there are 16 parameters, so the description must compensate. It documents handful of key parameters (allowed_address, public_key, use_preshared_key, endpoint, write_client_config and its dependents, client_dns) with real semantics and formats. However, it ignores name, site, comment, dry_run, preshared_key, persistent_keepalive, rollback_minutes, and server_endpoint, leaving many undocumented despite the low coverage. Partial compensation warrants a middle score.

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 (add) and resource (WireGuard peer), clearly distinguishing it from wireguard_update_peer and wireguard_remove_peer. The scope is unambiguous. It doesn't explicitly name siblings, but the verb distinction makes purpose unmistakable.

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 explains when to provide each field and gives channel-specific guidance (e.g., 'ask the user', 'Never ask the user to paste it in chat'), which is helpful operational context. However, it never states when to use this tool vs wireguard_update_peer or wireguard_create_interface, nor does it mention prerequisites like an existing interface. Usage is implied rather than scoped.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses validation/overlap checks, that 'router' keys never leave the router, and that user-supplied keys arrive via a local popup on apply. However, it omits major behavioral traits encoded as defaults: dry_run=true (nothing actually applied unless changed), rollback_minutes=5, allow_in_firewall=true, and trust_as_lan=false.

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 purpose, then uses a compact field-by-field list where each item carries substantive information (formats, ask-the-user mandate, key-source branching). Slightly dense but no filler sentences.

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

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

An output schema exists, so return values need not be described. But for a mutating network-configuration tool with no annotations, 10 params, and 0% schema coverage, leaving dry_run and rollback_minutes unexplained leaves an agent unsure what will actually be applied and what safety net 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?

Schema description coverage is 0% with 10 parameters, so the description must compensate. It does explain 5 of 10 (address format and validation, private_key_source semantics, private_key handling, wg_name, listen_port) with real added meaning. The remaining 5 — name, dry_run, trust_as_lan, rollback_minutes, allow_in_firewall — are undocumented despite dry_run and rollback_minutes being behaviorally critical.

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 ('Create (or update) a WireGuard interface'), which cleanly separates it from the peer-management siblings. The '(or update)' dual purpose adds slight ambiguity but the core operation is unmistakable.

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 operational guidance on required inputs and, notably, a decision rule for private_key_source ('router' vs 'user' with the rebuild-tunnel case). It does not state when this tool should be chosen over alternatives like wireguard_add_peer, but the resource scope makes that implicit.

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

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

No annotations are provided, so the description carries the full behavioral burden. It states that a peer is removed but does not disclose that dry_run defaults to true, that rollback_minutes defaults to 5, or that actual deletion likely requires dry_run=false. The destructive nature is implied but safety, reversibility, and side effects are unexplained.

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

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

The description is a single efficient sentence that front-loads the action and resource. It is not verbose, but its extreme brevity leaves important invocation details unstated. The issue is under-specification rather than excessive length.

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

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

An output schema exists, so return values need not be explained. However, the input schema has no field descriptions and the description only covers one of five parameters. For a destructive operation with dry-run and rollback defaults, the definition is incomplete for safe invocation.

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

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

Schema description coverage is 0%, so the description must compensate for five undocumented parameters. It only clarifies that 'peer' can be a public key or comment. It does not explain the required 'interface' parameter, the 'name' default, the 'dry_run' safety behavior, or the 'rollback_minutes' rollback mechanism.

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: remove a WireGuard peer. It also clarifies the peer identifier can be either a public key or comment. It is clearly distinguishable from sibling tools like wireguard_add_peer and wireguard_update_peer, though it does not name alternatives 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 guidance about when to use this tool versus wireguard_update_peer or other WireGuard management tools. It also does not mention prerequisites, required context, or when removal should be avoided. Usage is implied only by the verb 'remove'.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose a meaningful trait: 'Secrets are masked.' The verb 'Show' signals read-only, and it enumerates the returned facets (handshake, traffic, endpoints, firewall). It stops short of permissions/rate-limit context, but adds genuine value beyond 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?

One tightly packed sentence, front-loaded with the primary resource and using parentheticals that each carry substantive detail. Slightly dense, but no wasted wording.

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

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

An output schema exists, so return values needn't be explained, yet the description helpfully enumerates them anyway. For a zero-required-param read tool this is close to complete; only the input parameter's meaning is left 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 single 'name' parameter has 0% schema description coverage, and the description never addresses it or its 'router' default. The parentheticals describe output, not the input, so nothing compensates for the schema gap.

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

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

States a specific verb (Show) and precise resources: WireGuard interfaces, peers, and firewall per-port allowance. An agent can distinguish it from the mutating siblings (wireguard_create_interface, wireguard_add_peer), though it doesn't name any 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?

The read-only 'Show' framing implies diagnostic/inspection use before or after mutation, but there is no explicit when-to-use, when-not, or alternative routing (e.g., vs. router_overview or audit_security). Usage is left 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?

With no annotations, the description carries the full burden, and it does disclose real behavior: keys are never generated, key entry happens 'in a local popup on apply', allowed_address is validated, and endpoint accepts '' to clear. It omits other important behaviors, notably the dry_run default of true and the rollback_minutes safety window, which an agent needs to know before mutating a peer.

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

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

Dense and front-loaded: the core purpose comes first, then per-parameter notes in a compact format. Slightly fragmented across lines but every sentence adds information with little 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?

An output schema exists, so return values need not be explained, and the description covers the trickiest parameters. But for a 13-parameter mutation tool with no annotations, the omission of dry_run/rollback safety semantics and most parameter meanings leaves the agent under-informed.

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

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

Schema description coverage is 0%, so the description must compensate, and it only documents about half the 13 parameters (allowed_address syntax, endpoint format, replace_*_key, new_public_key alias). It says nothing about disabled, new_comment, persistent_keepalive, rollback_minutes, or dry_run, leaving significant gaps on a low-coverage schema.

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

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

States a specific verb and resource ('Modify a WireGuard peer') and names the lookup key ('found by its public key or comment'), which clearly separates it from wireguard_add_peer, wireguard_remove_peer, and wireguard_create_interface.

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 'Modify' plus the peer lookup implies this is for changing existing peers rather than creating them, and the endpoint note ('"" to clear (roaming client)') gives a concrete usage condition. However, there is no explicit when-to-use vs the sibling mutation tools, and no mention of prerequisites such as needing an existing interface.

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