Skip to main content
Glama
AliKarami

MikroMCP

by AliKarami
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Upgrade SwOS Firmware

upgrade_swos_firmware
DestructiveIdempotent

Upgrade SwOS switch firmware by resolving, downloading, and flashing the correct version, with dry-run and prerelease options.

Instructions

Upgrade a SwOS switch's firmware the way the web UI's Upgrade tab does. Resolves the latest stable version for the model from MikroTik's download server (or takes version), downloads swos--.bin over HTTPS into the server's SwOS folder (or uses file), checks it, then flashes it; the switch reboots. Refuses release candidates unless allowPrerelease is true. A switch still on its preinstalled backup firmware (a version ending in 'p', which cannot save configuration) counts as needing the upgrade. dryRun defaults to true.

Input Schema

NameRequiredDescriptionDefault
fileNoUse this firmware file from the server's SwOS folder instead of downloading one (offline upgrade).
boardNoFirmware board name, e.g. css318g. Derived from the model when omitted.
forceNoFlash a `board` that differs from the one derived from the switch's model.
dryRunNoResolve, download and check the firmware without flashing it.
versionNoTarget version. Defaults to the latest stable release for this model.
routerIdNoRouter ID; omit to use the default router.
allowPrereleaseNoAllow a release candidate or beta version.
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. Addedv1.14.1

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare destructive=true, idempotent, openWorld, so the bar is lower, yet the description adds real behavior: HTTPS download into the SwOS folder, integrity check, flash, and an explicit switch reboot. RC refusal and dryRun-default are also disclosed. Minor gaps (rate limits, rollback of a failed flash) remain.

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?

A dense single paragraph that front-loads the primary purpose and then the resolution/flash sequence. Every sentence carries information; slightly long but not padded.

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, no-output-schema, 8-parameter tool the description covers the workflow, defaults, and safety conditions well. The confirmationToken/APPROVAL_REQUIRED flow is left to the schema, which is acceptable since the schema documents it.

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% (baseline 3), and the description adds meaning beyond the schema by explaining the interplay: version/file/board resolution, download-vs-offline alternatives, and prerelease gating. It clarifies mutual exclusivity that the flat schema does not.

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?

States a specific verb (Upgrade) and resource (SwOS switch firmware) and adds scope detail (resolves latest stable, downloads, flashes). It is clearly distinguishable from siblings like manage_upgrade (RouterOS), get_upgrade_status, and the swOS config/blob tools.

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 actionable conditions: refuses release candidates unless allowPrerelease, dryRun defaults to true, and preinstalled backup firmware (version ending in 'p') counts as needing upgrade. It does not explicitly name alternatives like get_upgrade_status or manage_upgrade, so routing is implied rather than spelled out.

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