MikroMCP

Manage Mangle Rule

manage_mangle_rule

DestructiveIdempotent

Add, remove, enable, or disable RouterOS firewall mangle rules using comment as idempotency key. Preview changes with dry-run mode.

Instructions

Add, remove, enable, or disable a firewall mangle rule. ruleAction sets the action; when it is omitted, a new* value implies its own (newRoutingMark → mark-routing), otherwise accept. Each new* value is accepted only under its action. Uses comment as idempotency key: a repeated add returns already_exists only when the chain, match fields, marks, DSCP, MSS, passthrough, and the given or implied action agree, otherwise CONFLICT. Supports dry-run mode.

Input Schema

Name	Required	Description
`chain`	No	Mangle chain (required on add): prerouting, input, forward, output, postrouting
`action`	Yes	Action to perform
`dryRun`	No	Preview changes without applying.
`newMss`	No	MSS to set: a number or clamp-to-pmtu (ruleAction change-mss, with protocol tcp and tcpFlags syn)
`comment`	Yes	Idempotency key — uniquely identifies this mangle rule
`dstPort`	No	Destination port or range
`srcPort`	No	Source port or range
`protocol`	No	Protocol to match (e.g. tcp, udp)
`routerId`	No	Router ID; omit to use the default router.
`tcpFlags`	No	TCP flags to match, comma-separated, ! negates one (e.g. "syn"); needs protocol tcp
`dstAddress`	No	Destination IP/CIDR to match
`ruleAction`	No	Mangle action, add only. Omitted: the action of the new* value given (newRoutingMark → mark-routing, newConnectionMark → mark-connection, newPacketMark → mark-packet, newDscpValue → change-dscp, newMss → change-mss), else accept, the RouterOS default
`srcAddress`	No	Source IP/CIDR to match
`inInterface`	No	Incoming interface to match
`passthrough`	No	Whether to continue matching subsequent rules
`newDscpValue`	No	DSCP value to set, 0–63 (ruleAction change-dscp)
`outInterface`	No	Outgoing interface to match
`newPacketMark`	No	Packet mark to set (ruleAction mark-packet)
`dstAddressList`	No	Destination address list name to match
`newRoutingMark`	No	Routing mark to set (ruleAction mark-routing, chain prerouting or output)
`srcAddressList`	No	Source address list name to match
`confirmationToken`	No	Token from a prior APPROVAL_REQUIRED response. Re-submit the identical call with this token to confirm the destructive action.
`newConnectionMark`	No	Connection mark to set (ruleAction mark-connection)

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv1.14.1Oct 17, 2026

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

changedInput schema / properties / newConnectionMark / description

Previous value: -"Connection mark to set"New value: +"Connection mark to set (ruleAction mark-connection)"

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

changedInput schema / properties / newDscpValue / description

Previous value: -"DSCP value to set (0–63)"New value: +"DSCP value to set, 0–63 (ruleAction change-dscp)"

addedInput schema / properties / newMss

Added value: +{
+  "anyOf": [
+    {
+      "maximum": 65535,
+      "minimum": 0,
+      "type": "integer"
+    },
+    {
+      "const": "clamp-to-pmtu",
+      "type": "string"
+    }
+  ],
+  "description": "MSS to set: a number or clamp-to-pmtu (ruleAction change-mss, with protocol tcp and tcpFlags syn)"
+}

addedInput schema / properties / newPacketMark

Added value: +{
+  "description": "Packet mark to set (ruleAction mark-packet)",
+  "minLength": 1,
+  "type": "string"
+}

changedInput schema / properties / newRoutingMark / description

Previous value: -"Routing mark to set"New value: +"Routing mark to set (ruleAction mark-routing, chain prerouting or output)"

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

addedInput schema / properties / ruleAction

Added value: +{
+  "description": "Mangle action, add only. Omitted: the action of the new* value given (newRoutingMark → mark-routing, newConnectionMark → mark-connection, newPacketMark → mark-packet, newDscpValue → change-dscp, newMss → change-mss), else accept, the RouterOS default",
+  "enum": [
+    "accept",
+    "passthrough",
+    "mark-routing",
+    "mark-connection",
+    "mark-packet",
+    "change-dscp",
+    "change-mss"
+  ],
+  "type": "string"
+}

addedInput schema / properties / tcpFlags

Added value: +{
+  "description": "TCP flags to match, comma-separated, ! negates one (e.g. \"syn\"); needs protocol tcp",
+  "minLength": 1,
+  "type": "string"
+}

Changed1 schema field changedv1.8.0Jul 25, 2026

addedInput schema / properties / confirmationToken

Added value: +{
+  "description": "Token from a prior APPROVAL_REQUIRED response. Re-submit the identical call with this token to confirm the destructive action.",
+  "type": "string"
+}

Changed3 schema fields changedv1.6.0May 30, 2026

changedInput schema / properties / dryRun / description

Previous value: -"Preview changes without applying"New value: +"Preview changes without applying."

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",
-  "comment"
-]New value: +[
+  "action",
+  "comment"
+]

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

TDQS

A4.3/5.0

Behavior5/5

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

Goes well beyond annotations (readOnly=false, idempotent=true, destructive=true) by disclosing the idempotency-key mechanism, the already_exists vs CONFLICT outcome on repeated adds, the exact set of fields that must agree, the implied ruleAction fallback, and the per-action acceptance constraint on new* values. This is exactly the extra behavioral context a mutation tool needs.

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 is front-loaded in the first sentence, and the remaining sentences each carry distinct semantic content (implied action, per-action constraint, idempotency/CONFLICT, dry-run). It is dense but no sentence is filler; a light trim would make it a 5.

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-parameter tool with no output schema, the description covers actions, implied rules, idempotency, conflict behavior, and dry-run well. It omits the destructive-action confirmation/APPROVAL_REQUIRED flow, which is only surfaced via the confirmationToken parameter and the destructiveHint annotation, so a small gap remains.

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, but the description adds a genuine cross-parameter validation rule absent from the schema: each new* value is accepted only under its matching action. It also restates the implied ruleAction mapping, which the schema already covers, capping it below 5.

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?

Starts with a specific set of verbs (Add, remove, enable, disable) applied to a precise resource (firewall mangle rule), which distinguishes it from the sibling manage_firewall_rule and complements list_mangle_rules. An agent can tell what domain this operates in without opening the schema.

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

Usage Guidelines3/5

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

Usage is implicit: the semantics of add/remove/enable/disable and dry-run imply when to call it, but there is no explicit when-to-use, when-not, or named alternative against siblings like manage_firewall_rule or manage_routing_rule. Adequate but leaves routing decisions 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

Manage Mangle Rule

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools