MCP server for MikroTik RouterOS — 780+ tools over SSH for firewall, NAT, routing, DHCP, DNS, WireGuard, wireless, QoS and more.
Strong foundation with 12 tools featuring comprehensive descriptions (avg 180 chars, well above 34-char baseline) and explicit input schemas. Tool naming follows verb_noun convention (ping, traceroute, bandwidth_test, resolve_dns, add_netwatch, etc.). Most parameters include type and description. However, several tools lack output schema documentation, and some parameter descriptions could be more prescriptive about constraints. The gateway tools (find_tools, describe_tool, invoke_tool) are well-designed discovery/execution patterns. Error handling guidance is present but inconsistent across tools.
Creates a host-monitoring entry (`/tool netwatch add`) that probes a host at a set interval and runs RouterOS scripts on up/down state transitions — use to trigger automated responses (e.g. failover scripts) when a host becomes reachable or unreachable. `interval` and `timeout` accept RouterOS time strings (e.g. `'00:00:10'`). `up_script` and `down_script` are inline RouterOS script strings executed on state change. Returns the detail of the created entry, confirmed by a follow-up `/tool netwatch print detail` lookup. To view existing entries use `list_netwatch`; to inspect one entry's detail use `get_netwatch`; to delete use `remove_netwatch`.
Runs a RouterOS throughput test to a remote host (`/tool bandwidth-test`) — use to measure available bandwidth between the router and a target that must be running the RouterOS bandwidth-test server. `direction` controls traffic flow: `receive` (download from server), `transmit` (upload to server), or `both`. `duration` (default 5 s) bounds the run so it terminates; it does not run indefinitely. `protocol` is `tcp` (default) or `udp`. Supply `user`/`password` if the remote server requires authentication. Returns throughput results or a failure message if the remote end is unreachable or not running the bandwidth-test server. For reachability checks use `ping`; for path diagnostics use `traceroute`.
Return the exact input schema, parameters (name · required · description), risk level and purpose of ONE tool by its exact name — use it after find_tools to build a correct call before running a tool you can't see listed. Pass the tool's snake_case name, e.g. 'create_filter_rule'.
Output schemas not documented for any tool. LLMs cannot plan downstream calls or extract required fields without knowing response structure.
resolve_dns description states 'server' parameter is 'informational only' and ignored, but parameter is still exposed. This violates the principle that tool parameters should control behavior. Either remove the parameter or make it functional.
add_netwatch accepts RouterOS time strings (e.g. '00:00:10') but parameter descriptions lack format specification. LLMs may pass invalid formats like '10 seconds' or '10s'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
🔍 START HERE — this is the PRIMARY entry point for ANY MikroTik / RouterOS task. ALWAYS call this tool FIRST before attempting any other tool. This server has several hundred dedicated tools with full validation and structured output, but the host only surfaces a small subset — this tool searches the FULL catalog and finds the best match for your intent. Describe what you want to do in natural language or keywords, e.g. 'block a LAN client by MAC', 'add an IPv4 firewall filter rule', 'import a TLS certificate', 'list DHCP leases', 'create a WireGuard peer'. Returns each match's exact tool name, description, and parameters — then call it directly if available, or via `invoke_tool`. Workflow: find_tools → (optional) describe_tool → invoke_tool. Only fall back to run_routeros_command if this search returns zero results. For IPv4 vs IPv6, include 'ipv4' or 'ipv6' to disambiguate. For authorized changes that must be coordinated across multiple routers, search 'begin_transaction' BEFORE individual write tools (VPN tunnels, peering, routes or fleet ACLs). Discovery does not authorize verify_transaction or commit_transaction.
Sends a burst of ICMP echo requests as fast as possible to a target host or IP (`/tool flood-ping`). Use to stress-test packet loss and measure raw round-trip latency under maximum-rate load rather than at a timed interval; the run terminates after `count` packets (default 1000) so it does not stream indefinitely. Returns sent/received packet counts and min/avg/max round-trip times. Optional: `size` (packet size in bytes), `interface` (outgoing interface), `src_address` (source IP address to use).
Reads bandwidth-test server configuration (`/tool bandwidth-server print`) — use to inspect whether the server is enabled, requires client authentication, and what session/port limits are active. For live in-progress tests use `list_bandwidth_server_sessions`. Returns the full settings block including `enabled`, `authenticate`, `max-sessions`, and `allocate-udp-ports-from`.
Execute ANY tool in the catalog by its exact name with the given arguments — the precise way to run a tool you found via find_tools but the host hasn't surfaced for a direct call. The arguments are validated against that tool's real schema and run through its real handler, so this is exactly as safe/accurate as calling the tool directly (unlike raw CLI). To target a specific device in a multi-device setup, set the top-level `device` parameter on THIS call — not inside `arguments`. If validation fails you get the expected parameters back; fix and retry. For a one-off raw command with no dedicated tool, prefer run_routeros_command.
Lists currently active bandwidth-test server sessions (`/tool bandwidth-server session print`) — use to see in-progress tests accepted by this device's server side, including remote client usernames. Optionally filter by partial username with `user_filter`. To inspect or change the server's global settings use `get_bandwidth_server` or `update_bandwidth_server`. Returns zero or more active session records; empty when no tests are running.
Sends ICMP echo requests to a target host (`/ping`) from the RouterOS device — use to verify reachability or measure round-trip latency from the router's vantage point. Output is a single bounded run of `count` packets (1–100, default 4); it does not stream continuously. Optional `interface` pins egress to a specific interface; `src_address` sets the source IP for the probe. Returns packet statistics (sent/received/loss/RTT) or a failure message if unreachable. For hop-by-hop path discovery use `traceroute`; for throughput measurement use `bandwidth_test`.
Resolves a DNS hostname to an IP address (`[:resolve]`) using the RouterOS device's configured system resolver — use to verify that DNS resolution works correctly from the router's own perspective. The optional `server` argument is informational only; the handler always invokes the system resolver regardless. Returns the resolved IP address string, or an error if resolution fails. For managing static DNS entries on the device use `add_dns_static`.
Traces the network path to a target host hop by hop (`/tool traceroute`) — use to diagnose routing problems or identify where packets are dropped between the router and a destination. Output is a bounded run of `count` probes per hop (default 3; keep small to prevent long runtimes). Set `use_dns=true` to resolve hop addresses to hostnames. Returns a hop-by-hop list with RTTs, or an error if the command fails. For simple reachability checks use `ping`; for throughput measurement use `bandwidth_test`.
Configures the bandwidth-test server (`/tool bandwidth-server set`) — enables or disables the server, toggles client authentication, caps concurrent sessions, and sets the UDP port allocation base. To inspect current values before changing them use `get_bandwidth_server`. Returns the updated settings block after applying changes. Arguments: `enabled`: accept incoming bandwidth-test sessions. `authenticate`: require valid device credentials from test clients. `max_sessions`: cap concurrent test sessions. `allocate_udp_ports_from`: first UDP port used for test streams.
bandwidth_test and ping accept 'count' and 'duration' parameters but lack explicit bounds (min/max). Descriptions mention defaults but not ranges, risking LLM-generated invalid values.
No error handling guidance in tool descriptions. Tools should explain what to do if a host is unreachable, DNS resolution fails, or bandwidth-test server is not running.