mcp-mikrotik

arm_dead_man

Arm a self-removing RouterOS scheduler that reverts specified commands after 1-60 minutes unless cancelled, guarding risky writes against lockout.

Instructions

Arm a local, self-removing RouterOS scheduler on device_name that reverts a change after minutes (1-60) unless cancelled first (cancel_dead_man) - the anti-lockout primitive behind every LOCKOUT-RISK write in this package (set_wireless_channel/ set_wireless_tx_power use it automatically by default). See README's "Dead-man / lockout-proof writes" section for the full design and the real-hardware incident that validated it.

NOT wireless-specific: revert_commands is any non-empty list (max 10 items) of RouterOS script statements that restore a known-good prior state - a route, a bridge port, a firewall rule, anything - run in order when the dead-man fires, after logging a warning (visible in logs/security_events) and before the scheduler removes itself. Build each command from state you already read from the device, not free-form text.

The returned preview's after["name"] (also after more broadly) is the exact scheduler that would be armed (or was armed, if confirm=True) - pass that name to cancel_dead_man once the change it guards is confirmed good.

WRITE tool, guarded: blocked entirely unless the server is running with MIKROTIK_ALLOW_WRITE=true. Call with confirm=False (the default) to preview the exact scheduler that would be armed without touching the device; call again with confirm=True to actually arm it.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`confirm`	No
`minutes`	No
`device_name`	Yes
`revert_commands`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.11.0Sep 13, 2026

TDQS

A4.9/5.0

Behavior5/5

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 meets it: it discloses the write-guard (MIKROTIK_ALLOW_WRITE=true), the dry-run default, the self-removing scheduler lifecycle, that revert commands run in order after a logged warning visible in logs/security_events, and that commands must be built from read state, not free text.

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?

Front-loaded with the core purpose and generally well structured, but the mid-paragraph clarification about the preview's after['name'] is wordy and slightly redundant, and the README pointer is a mild detour. Still efficient for the amount of behavior it must convey.

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?

With an output schema present, the description needn't enumerate return fields, yet it still points the agent at the returned preview's after['name'] for the cancel flow. Given the write-guard, dry-run semantics, and command constraints, nothing essential is missing.

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

Parameters5/5

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: minutes is bounded (1-60), revert_commands is any non-empty list of max 10 ordered RouterOS statements, confirm controls preview-vs-arm, and device_name is the target. All four parameters gain meaning beyond their bare titles.

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+resource ('Arm a local, self-removing RouterOS scheduler') and immediately scopes it as the anti-lockout primitive behind LOCKOUT-RISK writes. It cleanly distinguishes itself from cancel_dead_man, which it names as the counterpart.

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?

Explicitly says when to use it (guarding LOCKOUT-RISK writes), how the two-step confirm flow works (confirm=False to preview, confirm=True to arm), and when to cancel (once the guarded change is confirmed good via the returned name). No inference required.

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

Deploy Server