MikroMCP

Manage Firewall Rule

manage_firewall_rule

DestructiveIdempotent

Manage MikroTik firewall rules: add, remove, disable, or enable using comment as idempotency key; supports dry-run.

Instructions

Add, remove, disable, or enable a firewall rule on a MikroTik router. Matches addresses, ports, protocol, interfaces, interface lists, and connection/NAT state; nat rules take toAddresses/toPorts (e.g. a dst-nat port forward). Uses comment as idempotency key for deduplication and identification: a repeated add returns already_exists only when the match, NAT targets, and disabled state agree, otherwise CONFLICT (use enable/disable when only the disabled state differs). Supports dry-run mode.

Input Schema

Name	Required	Description	Default
`chain`	Yes	Firewall chain (e.g. forward, input, output, srcnat, dstnat)
`table`	No	Firewall table to manage: filter or nat	filter
`action`	Yes	Action to perform: add, remove, disable, or enable a firewall rule
`dryRun`	No	If true, validate and return planned changes without applying
`comment`	No	Comment to identify the rule (used as idempotency key); omit for none
`dstPort`	No	Destination port or range
`srcPort`	No	Source port or range
`toPorts`	No	NAT target port or range (nat table only)
`disabled`	No	Whether the rule should be disabled
`protocol`	No	Protocol to match
`routerId`	No	Router ID; omit to use the default router.
`dstAddress`	No	Destination address or network
`ruleAction`	Yes	RouterOS rule action (e.g. accept, drop, reject, masquerade)
`srcAddress`	No	Source address or network
`inInterface`	No	Incoming interface
`placeBefore`	No	Place the new rule before this rule ID
`toAddresses`	No	NAT target address or range (nat table only, e.g. dst-nat)
`outInterface`	No	Outgoing interface
`connectionState`	No	Connection-tracking states, comma-separated, optionally negated: established,related or !invalid
`inInterfaceList`	No	Incoming interface list, e.g. WAN or !LAN
`outInterfaceList`	No	Outgoing interface list, e.g. WAN or !LAN
`confirmationToken`	No	Token from a prior APPROVAL_REQUIRED response. Re-submit the identical call with this token to confirm the destructive action.
`connectionNatState`	No	Connection NAT state to match, e.g. dstnat or !dstnat

Schema Changelog

Changes observed during successful MCP inspections.

Changed14 schema fields changedv1.14.1Oct 17, 2026

changedInput schema / properties / comment / description

Previous value: -"Comment to identify the rule (used as idempotency key)"New value: +"Comment to identify the rule (used as idempotency key); omit for none"

addedInput schema / properties / comment / minLength
```
Added value: +1
```

addedInput schema / properties / connectionNatState

Added value: +{
+  "description": "Connection NAT state to match, e.g. dstnat or !dstnat",
+  "pattern": "^!?(srcnat|dstnat|srcnat,dstnat|dstnat,srcnat)$",
+  "type": "string"
+}

addedInput schema / properties / connectionState

Added value: +{
+  "description": "Connection-tracking states, comma-separated, optionally negated: established,related or !invalid",
+  "pattern": "^!?(established|related|new|invalid|untracked)(,(established|related|new|invalid|untracked))*$",
+  "type": "string"
+}

addedInput schema / properties / dstAddress / minLength
```
Added value: +1
```
addedInput schema / properties / dstPort / minLength
```
Added value: +1
```
addedInput schema / properties / inInterface / minLength
```
Added value: +1
```

addedInput schema / properties / inInterfaceList

Added value: +{
+  "description": "Incoming interface list, e.g. WAN or !LAN",
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / outInterface / minLength
```
Added value: +1
```

addedInput schema / properties / outInterfaceList

Added value: +{
+  "description": "Outgoing interface list, e.g. WAN or !LAN",
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / srcAddress / minLength
```
Added value: +1
```
addedInput schema / properties / srcPort / minLength
```
Added value: +1
```

addedInput schema / properties / toAddresses

Added value: +{
+  "description": "NAT target address or range (nat table only, e.g. dst-nat)",
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / toPorts

Added value: +{
+  "description": "NAT target port or range (nat table only)",
+  "pattern": "^\\d{1,5}(-\\d{1,5})?$",
+  "type": "string"
+}

Changed2 schema fields changedv1.6.0May 30, 2026

changedInput schema / properties / routerId / description

Previous value: -"Target router identifier from the router registry"New value: +"Router ID; omit to use the default router."

changedInput schema / required

Previous value: -[
-  "routerId",
-  "action",
-  "chain",
-  "ruleAction"
-]New value: +[
+  "action",
+  "chain",
+  "ruleAction"
+]

Addedv1.5.0May 28, 2026
Removedv1.1.0May 22, 2026
First observedv0.1.0May 20, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare destructive=true and idempotent=true, but the description adds genuine depth: the comment-as-idempotency-key mechanism, the already_exists vs CONFLICT return semantics, and dry-run support. It omits the APPROVAL_REQUIRED/confirmationToken flow that the schema exposes, which is a notable gap for a destructive tool.

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-loads the core action verbs, then layers behavior in a compact paragraph appropriate to a 23-parameter tool. Dense but every sentence carries information; no filler.

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

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 23-param destructive mutation with no output schema, the description covers purpose, idempotency, NAT behavior, and dry-run adequately. The main missing piece is any mention of the two-step approval/confirmation flow that the schema's confirmationToken implies.

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 description coverage is 100%, so the baseline is 3, but the description adds meaningful grouping and relationships beyond the schema: which params apply to nat (toAddresses/toPorts), and the set of match dimensions (addresses, ports, protocol, interfaces, connection/NAT state). This helps an agent reason about parameter interactions.

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 specific verbs (add, remove, disable, enable) plus the resource (firewall rule) and the platform (MikroTik router), and enumerates the match dimensions it manages. This clearly distinguishes it from siblings like manage_mangle_rule and manage_routing_rule.

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

Usage Guidelines4/5

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

Gives clear operational context: nat rules take toAddresses/toPorts, comment is the idempotency key, and enable/disable is the correct path when only disabled state differs. It stops short of naming sibling tools or stating when to prefer this over manage_mangle_rule, so it's strong context rather than explicit routing.

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

Deploy Server

Manage Firewall Rule

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools