mikrotik-mcp

Overview Schema Source Related Servers Discussions Admin

Run a RouterOS command over SSH

mikrotik_exec

Destructive

Run a single RouterOS command on a configured MikroTik router over SSH and return the output. Each call is stateless; use absolute command paths.

Instructions

Run a single RouterOS command on a configured router over SSH and return its output. Stateless: each call opens a fresh connection and closes it before returning, so there is no session, working directory or shell state carried between calls — send absolute command paths such as '/system resource print'. Profiles are read-only by default, in which case commands that would change the router are refused before connecting. Use mikrotik_list_profiles to find profile names. Item numbers printed by RouterOS are NOT stable: they are reassigned per session and again on the next print, and every call here is a new session. Never pass a number seen in an earlier call to a later one — it will act on whatever holds that number now. Select by predicate instead, e.g. /ip firewall filter remove [find where comment="x"]. See mikrotik_search_docs for more.

Input Schema

Name	Required	Description
`command`	Yes	RouterOS command, e.g. '/system resource print' or '/ip address print detail'.
`profile`	Yes	Profile name from mikrotik_list_profiles.
`timeoutMs`	No	Override the profile's timeout for this call.

Output Schema

Name	Required	Description	Default
`ok`	Yes
`stderr`	Yes
`stdout`	Yes
`exitCode`	Yes
`durationMs`	Yes
`hostKeyFingerprint`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 21, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare destructiveHint=true and readOnlyHint=false, but the description adds critical traits annotations cannot express: statelessness (fresh connection per call, no session/working directory/shell state), the read-only-profile refusal that happens before connecting, and the RouterOS item-number instability across sessions. This is genuine operational context beyond the safety hints.

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

Conciseness4/5

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

Purpose and statelessness are front-loaded, followed by the read-only behavior and the item-number hazard, then sibling pointers. Every sentence carries information, though the item-number paragraph is slightly long for what is ultimately one warning.

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

Completeness5/5

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. Given a 3-parameter, non-idempotent, potentially destructive open-world tool, the description covers everything an agent needs: connection model, refusal behavior, profile source, command addressing, and a serious correctness pitfall.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description still adds meaning by requiring absolute command paths with a concrete example ('/system resource print') and by tying the profile parameter to mikrotik_list_profiles. The item-number warning further informs how the command argument should be constructed, exceeding what the schema states.

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

Purpose5/5

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

States a specific verb and resource ('Run a single RouterOS command on a configured router over SSH') plus the return ('return its output'). It also distinguishes itself from siblings by naming mikrotik_list_profiles and mikrotik_search_docs and explaining their roles, so an agent can separate this tool from its neighbors without opening schemas.

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

Usage Guidelines5/5

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

Explicit routing: use mikrotik_list_profiles to obtain a profile, see mikrotik_search_docs for more, and select targets by predicate rather than by printed item number. It also states the operating condition (profiles read-only by default refuse mutating commands before connecting), which tells the agent when a call will be rejected.

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

Deploy Server