Skip to main content
Glama
AliKarami

MikroMCP

by AliKarami
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Manage IP Pool

manage_ip_pool
DestructiveIdempotent

Add or remove IP address pools on MikroTik routers, with idempotent handling by name, dry-run preview, and confirmation for destructive changes.

Instructions

Add or remove an IP address pool. Idempotent by name: add returns already_exists if a pool with the same name and ranges already exists.

Input Schema

NameRequiredDescriptionDefault
nameYesPool name — idempotency key
actionYesAction to perform
dryRunNoPreview changes without applying.
rangesNoIP range (e.g. '192.168.1.100-192.168.1.200'; required for add)
nextPoolNoNext pool name for overflow
routerIdNoRouter ID; omit to use the default router.
confirmationTokenNoToken from a prior APPROVAL_REQUIRED response. Re-submit the identical call with this token to confirm the destructive action.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.14.1
    • 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"
+}
  2. Changed3 schema fields changedv1.6.0
    • 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",
-  "name"
-]New value: +[
+  "action",
+  "name"
+]
  3. Addedv1.5.0

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so those traits are covered. The description adds real value beyond them by pinning down the idempotency key ('by name') and the concrete error outcome ('already_exists' when name and ranges match), which the agent cannot get from the hints. It stops short of describing the approval/confirmation flow for remove, though the confirmationToken schema description covers that.

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?

Two sentences, front-loaded with the core capability and followed immediately by the idempotency contract. Every clause carries information, though the second sentence packs several facts into one dense line.

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 destructive two-action tool with no output schema, the annotations plus schema already carry the safety profile, the dryRun preview, and the confirmation-token flow. The description supplies the mutation semantics and one return case, leaving little an agent needs that is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so all seven parameters are already documented, including name as the idempotency key and ranges as required for add. The description restates the name idempotency without adding new syntax or format detail, so the baseline 3 applies.

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

Purpose4/5

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

States a specific verb pair ('Add or remove') and resource ('IP address pool'), which clearly separates it from the read-only sibling list_ip_pools by implication. It does not, however, name the sibling or otherwise differentiate explicitly in text.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no when-not-to-use, and no routing to alternatives such as list_ip_pools for inspection. The only usage signal is the verb choice itself, which the agent could infer from the name alone.

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

Deploy Server

Other Tools