Skip to main content
Glama
AliKarami

MikroMCP

by AliKarami
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Create Backup

create_backup
Destructive

Creates a binary MikroTik router configuration backup file, optionally encrypted with a bound secret, and supports dry-run preview before writing to the router filesystem.

Instructions

Create a binary configuration backup on a MikroTik router. The backup is saved as .backup on the router's filesystem. To encrypt it, prefer passwordSecret (a MIKROMCP_SECRET_ bound to the router in routers.yaml — the password never reaches the conversation) over a literal password. Dry run checks that the secret resolves.

Input Schema

NameRequiredDescriptionDefault
nameNoBackup file name (without extension)backup
dryRunNoPreview the backup without creating it
passwordNoLiteral password to encrypt the backup. It stays in the conversation history; prefer passwordSecret
routerIdNoRouter ID; omit to use the default router.
passwordSecretNoEncrypt with the server's MIKROMCP_SECRET_<NAME> value, bound to this router by its secrets list in routers.yaml. The value never reaches the conversation
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. Changed2 schema fields changedv1.16.0
    • changedInput schema / properties / password / description
      Previous value: -"Password to encrypt the backup file"New value: +"Literal password to encrypt the backup. It stays in the conversation history; prefer passwordSecret"
    • addedInput schema / properties / passwordSecret
      Added value: +{
+  "description": "Encrypt with the server's MIKROMCP_SECRET_<NAME> value, bound to this router by its secrets list in routers.yaml. The value never reaches the conversation",
+  "pattern": "^[A-Z0-9_]+$",
+  "type": "string"
+}
  2. 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"
+}
  3. Changed2 schema fields changedv1.6.0
    • changedInput schema / properties / routerId / description
      Previous value: -"Target router identifier from the router registry"New value: +"Router ID; omit to use the default router."
    • removedInput schema / required
      Removed value: -[
-  "routerId"
-]
  4. Addedv1.5.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the safety profile is covered. The description adds genuinely new behavior: the artifact lands as <name>.backup on the router filesystem and dry run only validates secret resolution rather than creating anything — context the annotations cannot convey.

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 with no filler: the action, the output artifact, then the encryption preference with dry-run behavior. The most decision-critical constraint (secret over literal password) is front-loaded.

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 zero-required-param mutation with a fully documented schema and no output schema, this is nearly complete. The one gap is that it doesn't flag overwrite risk if <name>.backup already exists on the router filesystem, which matters for a destructive tool.

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. The description still adds decision-relevant semantics by stating a preference ordering between password and passwordSecret and explaining that the secret value never enters the conversation, which is more than the per-field descriptions convey on their own.

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 ('Create a binary configuration backup on a MikroTik router') plus the resulting file name, which is far more concrete than a tautology. It does not explicitly differentiate itself from siblings like export_config or save_swos_backup, which is the only thing keeping it from a 5.

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?

It gives useful in-tool guidance — prefer passwordSecret over a literal password, and dry run verifies the secret resolves. It never says when to pick this over export_config (textual export) or save_swos_backup, so sibling-level routing is left implied.

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