Skip to main content
Glama
Sign In
MikroMCP

MikroMCP

by AliKarami
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Apply Plan

apply_plan
Destructive

Execute ordered MikroTik write operations with per-step snapshots and journaling, stopping on first failure. Non-admins need a confirmation token; undo steps via rollback_change journal IDs.

Instructions

Execute write operations in order, stopping on first failure. Each step is snapshotted and journaled individually. Non-admin identities need a confirmationToken (same two-step flow as other destructive tools). Undo individual steps via rollback_change with the returned journal IDs.

Input Schema

NameRequiredDescriptionDefault
stepsYesOrdered list of write operations to apply in sequence
routerIdNoRouter ID; omit to use the default router.
confirmationTokenNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.14.1
    • removedInput schema / properties / confirmationToken / description
      Removed value: -"Token from a prior APPROVAL_REQUIRED response. Re-submit the identical call with this token to confirm the destructive action."
  2. Changed2 schema fields changedv1.6.0
    • changedInput schema / properties / routerId / description
      Previous value: -"Target router identifier"New value: +"Router ID; omit to use the default router."
    • changedInput schema / required
      Previous value: -[
-  "routerId",
-  "steps"
-]New value: +[
+  "steps"
+]
  3. Addedv1.5.0
  4. Removedv1.1.0
  5. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: ordered execution, halt-on-first-failure (consistent with idempotentHint=false, since partial application is non-repeating), per-step snapshot/journal creation, the confirmationToken requirement for non-admin callers, and the rollback path. Nothing contradicts the destructiveHint/readOnlyHint declarations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, zero filler, ordered by importance: what execution means, how it's journaled, then the auth requirement and undo path. Every clause carries operational 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?

For a destructive batch tool with no output schema, the description covers the essentials: sequencing, failure behavior, auth prerequisites, and where the returned journal IDs go. It even hints at the return value (journal IDs) that the absent output schema would otherwise hide.

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 67%, and the schema already documents steps, its item shape and the routerId default. The description adds the key semantic that confirmationToken is a non-admin requirement, but the token's acquisition flow and routerId's effect are left to the schema. Adequate but not compensatory.

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 and resource: it executes an ordered batch of write operations. The failure semantics ('stopping on first failure') and per-step journaling make the operation concrete. It doesn't explicitly differentiate itself from siblings like plan_changes or bulk_execute, so an agent must infer the preview-then-apply relationship.

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 real usage conditions: non-admin identities need a confirmationToken, and individual steps are undone via rollback_change. The phrase 'same two-step flow as other destructive tools' signals prior token acquisition. What's missing is an explicit statement that plan_changes should be called first to preview the plan.

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