Skip to main content
Glama
AliKarami

MikroMCP

by AliKarami
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Manage Container Config

manage_container_config
DestructiveIdempotent

Configure global container settings on MikroTik RouterOS, including registry URL, RAM limits, and veth interface. Preview changes with dry run or confirm destructive updates.

Instructions

Update global container settings. Idempotent: returns no_change if nothing differs.

Input Schema

NameRequiredDescriptionDefault
dryRunNoPreview changes without applying.
routerIdNoRouter ID; omit to use the default router.
ramHighMbNoRAM high-water mark in MB
registryUrlNoContainer registry URL
vethInterfaceNoVeth interface name for container networking
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."
    • removedInput schema / required
      Removed value: -[
-  "routerId"
-]
  3. Addedv1.5.0

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the description's 'Idempotent' claim largely restates structured data. It does add one behavioral fact beyond the annotations — the no_change return value when nothing differs — which is genuinely useful, but it omits what the destructive write actually changes and that confirmation via token is required.

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 short sentences, front-loaded with the action, with no filler or repetition. It is arguably under-sized for a destructive six-parameter mutation, but nothing in it is wasted.

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

Completeness3/5

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

For a destructive, open-ended mutation with no output schema, the description is thin: it never explains the approval/confirmation flow that the confirmationToken parameter implies, nor the scope of 'global' versus router-specific (routerId). The schema carries that load, so the definition is functional but not self-sufficient.

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 the six parameters (including dryRun and confirmationToken) are already fully documented in the schema; baseline 3 applies. The description adds no syntax, default, or interaction detail about any parameter.

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+resource: 'Update global container settings', which is clear enough to separate it from get_container_config and the per-container manage_container_env/manage_container_mount siblings. It does not, however, name any sibling or explain the 'global vs per-container' split explicitly, so the differentiation is inferential rather than stated.

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?

No guidance on when to use this versus get_container_config (read) or the other container settings tools, and no mention of prerequisites such as needing a prior APPROVAL_REQUIRED token before the destructive apply. The dryRun parameter exists in the schema but the description never tells the agent to use it first.

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