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

Annotations already declare readOnlyHint=false, idempotentHint=false, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds real value by disclosing the return value (the new item's .id), which matters because no output schema exists. It says nothing about duplicate creation on repeat calls, whether the item is enabled by default, or how invalid paths/properties fail.

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

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

Two sentences, front-loaded with the action and the CLI equivalent, with zero filler. Nothing could be removed without losing information.

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

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

For a generic write tool against a live router with no output schema, the definition is minimally adequate: the schema covers inputs fully and the return value is stated. It is missing guidance on failure modes, on the generic-vs-specialized tool choice, and on the live-impact of the write, which an agent would want before invoking.

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 schema already explains `path` formats, `device` defaulting, and the free-form `properties` object with an example. The description adds no parameter meaning beyond this, so the baseline 3 applies. The nested `properties` pass-through, the most error-prone parameter, is not elaborated further.

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

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

The description gives a specific verb+resource ('Add an item to any RouterOS menu') and even shows the equivalent CLI form `/<path> add ...`, which makes the scope concrete. It is distinguishable from mikrotik_set/mikrotik_remove by the verb, but never names those siblings 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?

There is no statement of when to use this generic add versus overlapping siblings such as mikrotik_firewall_add_rule (purpose-built) or mikrotik_run_command (which can also issue `add` commands). The only implicit guidance is 'any menu', which leaves the agent guessing at the boundary cases.

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=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds nothing behavioral: it does not say whether adding an existing entry duplicates or errors (notably with idempotentHint=false), how removal behaves when the entry is absent, or that timeout creates auto-expiring entries.

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 zero filler. It is efficient, though its brevity comes at the cost of the missing detail flagged in other dimensions.

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 7-parameter mutating tool with no output schema and under half of parameters documented, one sentence is not enough. An agent gets no information on list creation, duplicate handling, removal semantics, or what the response contains.

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 only 43% across 7 parameters. The description mentions no parameters at all, leaving 'list', 'action' (the enum), 'comment', and 'ipv6' undocumented in both places, 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 pair (add/remove) and resource (firewall address list), plus the typical intent (block/allow hosts). It is clearly narrower than the generic siblings mikrotik_add/mikrotik_remove, but the description never names those siblings to make the distinction explicit.

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

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

The parenthetical 'commonly used to block or allow hosts' explains intent, not tool selection. There is no guidance on when to use this versus mikrotik_add, mikrotik_remove, or mikrotik_firewall_add_rule, and no stated prerequisites (e.g. whether the list must already exist).

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=true, so the safety profile is fully covered elsewhere. The description adds real value by disclosing that results merge ARP entries with MNDP/CDP/LLDP neighbor discovery, which explains why the output may contain hosts outside the ARP table. It does not mention truncation behavior or that rows are capped, so it stops short of a 4.

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 zero filler; the resource comes first and the rationale trails it. Nothing is redundant with 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 read-only listing tool with no output schema and no required parameters, the description is adequate but leaves the undocumented 'interface' filter and the shape of returned rows (address, MAC, interface, neighbor protocol) unexplained. An agent can call it correctly but cannot predict the response fields.

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 67%: limit and device are well documented in the schema, but the 'interface' parameter has no description anywhere and the description never compensates for it. The description adds no parameter meaning beyond the schema, so the 3 baseline for high-ish coverage is appropriate.

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

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

States a specific verb ('List') and precise resource ('ARP entries and discovered neighbors'), plus names the discovery protocols (MNDP/CDP/LLDP). This lets an agent distinguish it from mikrotik_dhcp_leases or mikrotik_ip_addresses, though it doesn't explicitly name those siblings as the 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?

The trailing clause 'to see which hosts are on the network' implies the use case, but there is no explicit when-to-use-vs-alternatives guidance despite several overlapping siblings (dhcp_leases, wireless_clients, ip_addresses) that also answer 'which hosts exist'.

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

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

The description adds real value beyond annotations by disclosing the side effect's location: files are written to the router's own file system (not downloaded to the caller). However, with idempotentHint=false it never warns that an existing file of the same name may be overwritten, nor does it mention possible size/time cost of a full config backup, which are the traits an agent most 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 action, both artifact types, and the destination are all in the first clause.

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 should say what the agent gets back (created file names/paths, or confirmation) and whether a backup can overwrite an existing file; neither is covered. For a write tool that creates persistent files, this leaves a meaningful gap, though the schema carries the parameter detail well.

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 all four parameters (name, device, password, exportScript) are already documented in the schema, making 3 the baseline. The description's only added meaning is the pairing of 'binary backup' with password encryption and 'text export' with exportScript, which is useful but already inferable from 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 (Save) and resource (binary .backup and/or text .rsc configuration export) plus the destination (the router's file system). No sibling tool does backups, so no differentiation is needed, but the description never says how this relates to the read-oriented siblings (e.g., that it writes rather than reads 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?

Usage is only implied: the 'and/or' phrasing hints that either artifact can be produced, and the schema's exportScript default covers the choice, but there is no explicit when-to-use context (e.g., before upgrades), no prerequisite that a device must be configured, and no guidance on when a password-protected binary backup is preferable.

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=true, so the safety profile is fully covered structurally. The description usefully enumerates the returned fields but says nothing about pagination limits, whether dynamic/static leases are both included, or behavior when a device/server is unreachable. With annotations carrying the behavioral load, a 3 is appropriate.

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

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

A single front-loaded sentence that gives the resource, the returned fields, and the optional scoping filter with zero 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 read-only list tool with no output schema, the description appropriately names the returned fields, which the structured data does not provide. Minor gaps remain around pagination defaults and error behavior, but nothing essential to calling it correctly is missing.

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

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

Schema coverage is 67%; device and limit are well documented in the schema. The undocumented `server` parameter is partially compensated by "optionally for one DHCP server," but neither source explains the expected identifier format or what happens if the server name is unknown.

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 DHCP leases) and names the returned fields (IP, MAC, hostname, status), which distinguishes it from mikrotik_arp_table and mikrotik_ip_addresses by implication. It stops short of explicitly naming a sibling alternative, so it isn't a full 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 phrase "optionally for one DHCP server" hints at when to pass the server filter, but there is no explicit guidance on when to use this tool versus mikrotik_arp_table, mikrotik_ip_addresses, or generic mikrotik_print. 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?

Annotations already declare this as a non-readonly, non-idempotent, open-world write. The description adds a useful behavioral fact the annotations don't: default append position and the ordering effect of placeBefore. It omits other traits such as the default device selection, and what happens on invalid properties (RouterOS may reject or silently ignore).

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 purpose, each carrying distinct information about properties and placement. Slight name-restating in the opening clause, but nothing 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?

For an 8-parameter mutation tool with no output schema and a nested free-form object, the description covers the two most subtle parameters but leaves half the surface (chain vs table vs ipv6 interplay, device default, action semantics) to the schema, which itself is thinly described.

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 only 25%, so the description needs to compensate. It does add genuine meaning for `properties` (accepts any RouterOS rule property, with examples) and `placeBefore` (takes a rule .id), but leaves chain, action, table, device, ipv6, and comment undocumented in 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?

States a specific verb and resource ('Add a firewall rule'), which distinguishes it from the sibling mikrotik_firewall_rules (listing) and from mikrotik_set (modification). It doesn't explicitly name the siblings it differs from, but the operation 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?

The description gives clear guidance for the placement decision — use placeBefore to insert above an existing rule, otherwise it is appended — which is real when-to-use advice. It offers no guidance on how this relates to generic siblings like mikrotik_add or mikrotik_set, or when to prefer this over editing an existing chain.

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, so safety is covered structurally. The description adds that rules come back in evaluation order and include packet/byte counters, which is genuine value. It says nothing about device scoping, ordering guarantees across tables, or truncation 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 front-loaded sentence with no filler; the table list and the counters note are the two facts an agent most 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?

With no output schema, the description's mention of counters partially covers return content, and annotations cover safety. But for a five-parameter tool spanning multiple devices, tables, chains and an ipv6 switch, the description leaves truncation, default-device scoping and ipv6 behavior 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?

At 60% schema coverage the baseline is 3, and the description roughly holds there: it echoes the table enum values and the notion of order, but a rule's ordering relative to chain/ipv6 selection is unaddressed. The undocumented ipv6 parameter and the semantics of chain filtering are not compensated 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?

Specific verb+resource ("List firewall rules") with the enumerated tables and a note that counters are included, which tells an agent exactly what it gets back. It is implicitly the read counterpart to mikrotik_firewall_add_rule, but it never names or contrasts that sibling.

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

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

No statement of when to use this versus mikrotik_print, mikrotik_firewall_add_rule, or other table-listing siblings, and no prerequisites. The read-only intent is only inferable from the verb "List".

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 openWorld, so safety is covered. The description adds value by disclosing what data comes back (state, MAC, MTU, traffic counters), which matters since there is no output schema, but says nothing about pagination, truncation, or the cost of collecting counters.

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

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

One sentence, front-loaded with the verb and resource, zero filler. It is efficient but thin enough that the space saved is not spent on routing or filter clarification.

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?

Four optional params and no output schema, so the description should carry return-value and filter meaning. It covers return fields adequately but leaves usage routing, the 'running' filter, and the default-device behavior to the schema or nothing at all.

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 75%, so baseline is 3. The description does not clarify the parameters; worse, 'type' and 'running' read as returned fields rather than as filters, leaving the 'running' filter (the one undocumented schema param) undefined anywhere.

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

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

Specific verb ('List') plus resource ('interfaces'), and it enumerates the fields returned (type, running/disabled, MAC, MTU, counters). That distinguishes it from siblings like mikrotik_ip_addresses or mikrotik_routes by resource, though no sibling is named 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 statement of when to use this versus alternatives such as mikrotik_print or mikrotik_list_devices. The only routing hint in the whole definition is inside the schema's 'device' parameter, not the description.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered structurally. The description adds nothing beyond that baseline — no pagination behavior, no note that results are capped, no indication of per-device scoping — so it neither informs nor contradicts.

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. Nothing is wasted, though the brevity contributes to the gaps in the other dimensions.

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 four-parameter, no-output-schema read tool, the description covers the core purpose but leaves the interface filter and IPv6 toggle unexplained and says nothing about result limits or device defaulting. It is minimally 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 coverage is 50%: 'limit' and 'device' are documented in the schema, while 'ipv6' and 'interface' are not. The parenthetical '(or IPv6)' hints at the ipv6 toggle but never explains its boolean semantics, and the 'interface' filter is not described at all, 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?

The description gives a specific verb ('List') and resource ('IPv4/IPv6 addresses assigned to interfaces'), which is clearer than the bare title. It does not differentiate itself from nearby siblings such as mikrotik_interfaces or mikrotik_address_list, so an agent must infer which listing 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 mikrotik_interfaces, mikrotik_address_list, or mikrotik_print, and no mention of prerequisites or filtering scenarios. The only implicit guidance is that it is a read/listing operation.

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 and openWorldHint=false, so the safety profile is covered. The description adds genuinely new context — that the result is limited to devices the server is configured to manage and that no credentials are returned — which is meaningful for an agent deciding whether it needs a separate auth step. No pagination or result-size behavior is disclosed.

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 zero padding, front-loaded with the verb and resource. The parenthetical security note is short and 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 trivial zero-parameter read tool with annotations covering safety, the description gives enough to call it correctly. The only minor gap is that no output schema exists and the description does not indicate what fields a device entry contains (name, host, id), which an agent may need to interpret the response.

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; the schema is empty and fully described. Baseline for a no-parameter tool is 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?

States a specific verb (list) and resource (MikroTik routers this server is configured to manage), which is concrete and distinct from the operational siblings like mikrotik_print or mikrotik_system_overview. It does not explicitly contrast itself with those siblings, which keeps it at 4 rather than 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?

Usage is only implied: an agent can infer this is the discovery entry point before calling per-device tools. There is no explicit 'use this when...' or note about what to do with the returned device identifiers, and no exclusion of alternatives.

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, so the safety profile is covered. The description adds useful behavior by specifying that results are the *most recent* entries (an implicit newest-first ordering), but it says nothing about truncation, how many entries exist, or what a log entry contains.

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 wasted clauses; the ordering constraint comes first and the optional filters follow it.

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

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

For a low-complexity read-only tool with full parameter documentation and complete annotation coverage, this is nearly sufficient. The only remaining gap is the return shape (fields per log entry), which matters somewhat since there is no output schema.

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 all four parameters carry descriptions, so the schema does the heavy lifting. The description confirms that topics and text filtering are optional, but adds no syntax or semantics beyond what the schema already provides for limit, device, topics and contains.

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 ("Read the most recent system log entries") and adds the filtering scope, so it is clearly the log-reading tool rather than the generic mikrotik_print or the system_overview sibling. It does not name a sibling explicitly, but the resource is distinctive enough to be told 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 phrase "optionally filtered by topic or text" implies when the filters are appropriate, but there is no explicit guidance on when to choose this over mikrotik_print or the other read-only inspection tools, nor any stated prerequisites (device reachability, 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 readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds that execution originates on the router rather than the MCP host, which is genuinely useful context, but it says nothing about timeouts, likely latency or packet-loss results, or how the default count of 4 is applied.

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 core action front-loaded and the parenthetical earning its place by adding usage context. Nothing is repeated from the title or restated without value.

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 6-parameter diagnostic tool with no output schema and no return-value documentation, the description should say what comes back (latency, loss, per-packet results) and how the device default is resolved. It covers the core action adequately but leaves an agent guessing about results and several parameters.

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 only 33% — address, interface, srcAddress, and count are undocumented in the schema. The description partially compensates by surfacing the interface and source-address concepts, hinting at what those two parameters do, but leaves count and address semantics unaddressed, so it is a partial rather than complete compensation.

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 ('ping a host') and disambiguates direction by saying 'from the router itself', which separates it from pinging the router. It does not name the nearest sibling (mikrotik_traceroute), so it falls short of full sibling 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?

The parenthetical gives a positive use case ('test connectivity from a specific interface or source address'), which is real guidance. However, it offers no exclusions and no mention of the obvious alternative, mikrotik_traceroute, for path diagnosis rather than reachability.

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, so safety is covered. The description adds the useful equivalence to `/<path> print`, but says nothing about output volume, the 200-row default cap, or what happens on an invalid path — gaps for a tool that can return up to 5000 rows.

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, both front-loaded: first sentence establishes the operation and the terminal analogy, second gives the selection rule and examples. Nothing repeats the name or the 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 catch-all read tool with no output schema, an agent would benefit from knowing the return shape (rows of properties, .id presence) and that results are capped/filterable. The description stops at what the command is equivalent to, leaving output and error behavior to be inferred.

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 of the six parameters is documented inline, including path examples, limit default, query syntax and where semantics. The description adds only the convenience that path is expressed like a terminal menu path, so baseline 3 is appropriate.

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

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

Names a specific verb ('Print items') and a fully general resource ('any RouterOS menu path'), and anchors it with the terminal/WinBox equivalents. It also explicitly separates itself from the dedicated sibling tools by scoping itself to 'anything without a dedicated tool'.

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

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

Gives an explicit selection rule ('use this for anything without a dedicated tool') plus concrete example paths (/ip/dns, /interface/bridge/port, /user) that show the intended fallback role. An agent can decide when to reach for this versus mikrotik_interfaces or mikrotik_firewall_rules without opening any schema.

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 readOnlyHint=false, but the description adds real information the agent cannot get elsewhere: the connection drops for roughly a minute, and user confirmation is mandatory. It stops short of saying whether the device comes back automatically or whether in-flight config is lost.

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, with the action and its impact front-loaded and the safety instruction last. Every 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?

For a two-parameter destructive action with no output schema, the description covers the action, its observable effect, the downtime window, and the human-in-the-loop requirement. Only a note on post-reboot state or failure behavior 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 both the 'device' default behavior and the const-true 'confirm' guard are already documented in the schema. The description adds no parameter detail beyond that, which is acceptable at full coverage.

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

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

States a specific verb and resource ('Reboot the router') in the first sentence. No sibling tool performs reboots, so the action is unambiguous against the long list of mikrotik_* diagnostic and config 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 an explicit precondition ('Always confirm with the user first') that governs whether the agent may invoke at all. It doesn't name alternatives, but no sibling offers a comparable action, so there is little 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 declare `destructiveHint: true`, `idempotentHint: false`, and `openWorldHint: true`. The description adds a meaningful behavioral safety rule: the item is removed by `id` or by a `where` filter that matches exactly one item, which helps prevent accidental mass deletion. It omits details about permissions, irreversibility, and response behavior, but the annotations carry much of that burden.

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 filler. The action and command syntax come first, followed by the key targeting constraint.

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

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

For a destructive mutation tool with rich annotations and no output schema, the description supplies enough to call it correctly: `path` is required, and the target is selected by `id` or an exactly-one-match `where` filter. It could say more about confirmation/irreversibility, but the annotations already signal destructiveness.

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

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

Schema coverage is 75%, so the schema already documents `path`, `where`, and `device`. The description adds useful semantics beyond the schema by clarifying that the target is identified either by `id` or by a `where` filter matching exactly one item.

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 ('Remove'), resource ('item'), and even the RouterOS command form, with identification by `id` or a `where` filter. It does not explicitly contrast with siblings like `mikrotik_run_command` or `mikrotik_set`, so it stops short of the sibling-differentiation bar for 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 an important selection constraint: a `where` filter must match exactly one item. However, it provides no explicit when-to-use/when-not guidance and does not name alternatives such as `mikrotik_run_command` or `mikrotik_set`.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered. The description adds the meaningful scope fact that it returns the routing table and can be narrowed, but says nothing about result volume, pagination, or the default device fallback that affects what data comes back.

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 well-formed sentence with the resource front-loaded and the optional modes trailing. No filler or 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 read-only list tool with no output schema, the description covers what is returned and the optional filters. The only gap is the default-200/pagination and default-device behavior, which the schema partially covers.

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 60% and already documents limit, device and the dstAddress example. The description only adds loose meaning for the undocumented ipv6 and activeOnly flags ('IPv4 (or IPv6)', 'only active routes') without formats or edge cases.

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 (IPv4/IPv6 routing table) with the optional narrowing filters named inline. It is clearly the routes tool among the siblings, though it never explicitly contrasts itself with generic readers like mikrotik_print.

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 optional 'activeOnly' and 'single destination' modes imply when the filters are used, but there is no explicit when-to-use vs when-to-use-an-alternative guidance or prerequisite note (e.g. that device defaults to the first configured device).

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

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

The description supplies real behavioral context beyond the annotations, notably the hang risk on monitor/torch/ping without `once`/`count` and the read-only-device command whitelist. However, it also advertises mutating commands (/ip/dhcp-server/lease/make-static, /system/script/run, /tool/fetch) and frames the read-only restriction as a per-device property, which contradicts the readOnlyHint=true, destructiveHint=false and idempotentHint=true 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?

Three sentences, front-loaded with the capability and its examples, then the two operational caveats. The example list is slightly long but each example illustrates a distinct command shape (script, monitoring, mutation, fetch), so no sentence 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?

With no output schema and a nested `args` object, the description covers invocation pitfalls well but leaves open what a failed command returns, how output is formatted/truncated at the 200-default/5000-max row limit, and why a specialized sibling tool would be safer. Given the tool can mutate device state despite read-only annotations, that omission matters.

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 `command`, `args`, `query`, `limit` and `device` are already documented with examples and a default. The description reinforces `args` by demonstrating `once=yes`, but adds no semantics for `query`, `limit` bounds, or `device` resolution 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?

The description states a specific verb and resource ('Run an arbitrary RouterOS command') and anchors it with four concrete command examples spanning script, monitor, DHCP and fetch operations. It is clear what the tool does, but with 20 sibling tools that already encapsulate discrete operations (mikrotik_print, mikrotik_add, mikrotik_set, mikrotik_ping), it never says when this generic escape hatch should be preferred over 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 through imperative constraints: non-terminating commands must receive `once` or `count`/`duration`, and read-only devices restrict the command set. This is genuinely actionable guidance, but there is no routing rule telling the agent to use the specialized siblings first and fall back here only when no dedicated tool exists.

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 mutation profile (readOnly=false, idempotent=false, destructive=false, openWorld=true), and the description adds the constraint that a `where` filter must match exactly one item and that singleton menus need no identifier. It stops short of saying what happens on multi-match (error vs silent partial apply), whether unrelated properties are preserved, or what the call returns.

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 tight sentences: the operation, the identification strategy, then the singleton exception. The CLI form is front-loaded and every clause carries operational 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 5-parameter mutation tool with no output schema, the description covers identification and the singleton edge case well. It is slightly thin on result behavior (what the response contains, whether the item is re-read after the change) and on error conditions when a filter matches zero or many items.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds semantics the schema does not encode: the mutual-exclusivity/omission rule for `id` and `where` in singleton menus, and the requirement that a filter resolve to exactly one item. That is real decision-making value beyond the per-parameter 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+resource ("Change properties of an item") and grounds it in the underlying RouterOS CLI form (`/<path> set <id> ...`), which unambiguously separates it from mikrotik_add and mikrotik_remove. It does not explicitly name the closest siblings (mikrotik_set_enabled for a single boolean, mikrotik_run_command for arbitrary CLI), so it falls short of full sibling 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?

The description explains how to target the item (id, or a where filter matching exactly one item, or neither for singleton menus), which is genuinely actionable guidance. However it gives no guidance on when to prefer this over mikrotik_set_enabled or mikrotik_run_command, and no exclusions such as bulk edits across many matches.

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 write/idempotency/open-world profile, and the description usefully adds the range of item types affected. However, for a mutation tool it omits the key behavioral question: what happens when a `where` filter matches zero or multiple items (bulk toggle vs error), and whether the change is immediate and persistent.

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 the action front-loaded and the targeting mechanism second; 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?

With five parameters including a nested free-form `where` object, no output schema, and destructive-adjacent consequences (disabling a firewall rule or interface), the definition should say more about match cardinality and failure modes. As written it is callable but leaves real ambiguity for a mutation 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?

Schema coverage is 60%, with `path`, `where`, and `device` documented inline; the description only adds the framing that `id` and `where` are alternative identification mechanisms. It does not clarify whether they are mutually exclusive, what happens if both are supplied, or why `path` is required alongside `id`.

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 (enable/disable) and the resource family it acts on (interface, firewall rule, route, user), so the action is unambiguous. It is implicitly distinct from the generic sibling mikrotik_set, but the description never names that sibling or states the contrast 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 description gives targeting guidance (identify by `id` or a `where` filter), which is useful, but it never says when to prefer this tool over mikrotik_set or mikrotik_run_command, nor when a `where` filter is appropriate versus a single `id`. 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?

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds one genuinely useful behavioral trait — that all these data points are fetched in a single round trip — but says nothing about what happens on unreachable devices or how absent health sensors are handled.

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, front-loaded with the returned data categories, with zero filler. Nothing could be removed without losing information.

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

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

Although there is no output schema, the description effectively enumerates the return contents, and the read-only annotations make the risk profile clear. The only gap is that it does not note platform-dependent variability in the returned set (e.g. health sensors on boards that lack them or fields unsupported by older RouterOS).

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 'device' parameter is fully documented in the schema, including its default and a pointer to mikrotik_list_devices. The description adds nothing about the parameter, which is acceptable given the schema does the work — baseline 3.

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 exactly what the tool returns (identity, RouterOS version, board, CPU/memory/disk usage, uptime, clock, health sensors), which makes the resource unambiguous and clearly distinct from the sibling list-style tools (interfaces, routes, logs). The verb is only implied by 'in one call' rather than stated, so it falls just short of a perfect verb+resource statement.

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 guidance on when to choose this over alternatives such as mikrotik_print, mikrotik_list_devices, or the per-resource tools. The phrase 'in one call' hints that it is an aggregate convenience read, but no exclusions or preconditions are 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds one useful behavioral fact — execution happens on the router itself — but says nothing about how long a trace blocks, whether the target must be resolvable from the device, or what hops output 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?

A single front-loaded sentence with no waste and the scope constraint ('from the router') placed early. It is arguably under-specified rather than over-long, so conciseness itself is fine but earns no bonus.

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 network diagnostic with no output schema and two undocumented parameters, the description leaves too much open: nothing about hop output, timeout/failure behavior, or what maxHops controls. Annotations cover safety but not operation, so the definition is thin for the task.

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 only 33%: only 'device' is documented. The required 'address' is bare, and 'maxHops' has no description in either the schema or the description, so the agent gets no guidance on its default, units, or the 1-64 bound's meaning. 'to a host' barely implies that address is a target host/IP.

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 ('Trace') and resource ('the path from the router to a host'), and the phrase 'from the router' pins down that the probe originates on the device rather than the caller. It is clearly distinct from siblings like mikrotik_ping or mikrotik_run_command, 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?

There is no statement of when to prefer this over mikrotik_ping (reachability) or mikrotik_run_command (arbitrary command), nor any exclusion or prerequisite. The agent must infer the use case entirely 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds genuine domain context by naming the four supported packages (wifi, wifiwave2, legacy wireless, CAPsMAN), which tells the agent the tool works across firmware families. It says nothing about result ordering or the default row cap beyond what the schema already states.

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 zero filler; the parenthetical package-support note is the only elaboration and it earns its place.

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

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

For a two-parameter, zero-required, read-only listing tool with full schema coverage and no output schema, the definition is essentially sufficient. The only unmet need is telling the agent which client attributes come back or how this differs from other table-listing 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?

Schema description coverage is 100%, so both parameters (limit with its default of 200, and device defaulting to the first device) are fully documented in the schema. The description contributes no additional parameter meaning, so the baseline of 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 and resource (list connected Wi-Fi clients) plus the data source (the registration table), which is far more precise than the sibling-sounding mikrotik_print. It does not explicitly contrast itself with neighboring table tools like mikrotik_dhcp_leases or mikrotik_arp_table, so an agent must 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?

The description says what the tool returns but gives no when-to-use guidance, no exclusions, and no pointers to alternatives. An agent choosing between this, mikrotik_dhcp_leases, and mikrotik_arp_table for 'who is on my network' gets no routing signal.

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