mcp-mikrotik

set_wireless_tuning

Tune a wireless interface's adaptive noise immunity or distance to fix poor CCQ. Preview before/after, then confirm; numeric distance arms a dead-man restore.

Instructions

Set a /interface/wireless interface's adaptive_noise_immunity ("none"/"client-mode"/"ap-and-client-mode") and/or distance ("dynamic"/"indoors"/an integer number of km). At least one must be given.

adaptive_noise_immunity alone is reception-only tuning - CONFIRMED SAFE against real hardware today (does not drop an already- associated link), never arms a dead-man. CONFIRMED TODAY: with good signal but poor CCQ (interference, not distance), adaptive_noise_immunity="ap-and-client-mode" measurably helped.

A NUMERIC distance (unlike the named "dynamic"/"indoors" modes) directly changes the ACK-timeout/TDMA timing - LOCKOUT-RISK, CONFIRMED LIVE it can silently drop an already-associated link on a mismatch (e.g. too short for the real link length). By default (arm_deadman=True), a numeric distance arms a dead-man (arm_dead_man) that restores the interface's prior distance after deadman_minutes (1-60, default 3) unless cancelled - same mechanism as set_wireless_channel/set_wireless_tx_power. For a long verified PtP link, an explicit distance (e.g. 9 for ~9km) gave a better ACK timeout than leaving it on "dynamic".

WRITE tool, guarded: blocked entirely unless the server is running with MIKROTIK_ALLOW_WRITE=true. Call with confirm=False (the default) to get a before/after preview (including the LOCKOUT-RISK warning for a numeric distance, without arming anything) without changing anything; call again with confirm=True to actually apply it. Errors if interface_name doesn't exist on /interface/wireless

never creates one.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`confirm`	No
`distance`	No
`arm_deadman`	No
`device_name`	Yes
`interface_name`	Yes
`deadman_minutes`	No
`adaptive_noise_immunity`	No

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?

With no annotations, the description fully carries the behavioral burden and does so richly: it flags the LOCKOUT-RISK of a numeric `distance` (silently drops associated links), states that `arm_deadman=True` arms a restoring dead-man, and documents that the tool never creates an interface and errors if it is missing. This is well beyond what any structured field provides.

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?

It is front-loaded with the core purpose and every sentence carries operational content, but the heavy ALL-CAPS emphasis and long multi-clause sentences make it denser and more shouty than needed. Slightly more structure would improve scanability without losing information.

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 returns need not be described, and the description still covers the write guard, the confirm workflow, dead-man behavior, the lockout risk, and the not-found error. For a 7-parameter mutation tool it is complete enough for an agent to call correctly.

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 description coverage is 0% and enums are absent, yet the description supplies the enum-like values for `adaptive_noise_immunity` (none/client-mode/ap-and-client-mode), the accepted forms for `distance` (dynamic/indoors/integer km), the deadman_minutes range (1-60, default 3), arm_deadman's default and effect, and confirm's preview-vs-apply meaning. It compensates almost entirely for the schema gap.

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?

The description names the exact resource (`/interface/wireless` interface) and the two settings it mutates (`adaptive_noise_immunity` and/or `distance`), with specific syntax for each. It also positions itself against siblings by noting it shares the dead-man mechanism with set_wireless_channel and set_wireless_tx_power.

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?

It gives concrete when-to-use guidance per parameter: `adaptive_noise_immunity` for good-signal/poor-CCQ interference cases, numeric `distance` for long verified PtP links. It also states the prerequisite (at least one setting must be supplied), the write guard (MIKROTIK_ALLOW_WRITE=true), and the confirm=False/True workflow, leaving nothing to inference.

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

Deploy Server