Run any RouterOS command

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.