Skip to main content
Glama

Write SwOS Blob

write_swos_blob
DestructiveIdempotent

Mutate a SwOS .b endpoint on a MikroTik switch by merging fields into the full blob and writing it back; preview with dryRun first and rollback if needed.

Instructions

Mutate a SwOS '.b' endpoint on a MikroTik switch. The full endpoint blob is read, the given fields are merged in, and the entire blob is written back (the firmware only accepts whole-blob writes); untouched fields are re-sent byte-for-byte, and a field this firmware does not expose is refused rather than injected. dryRun defaults to true — preview first. Every result reports whether the schema has been verified against the switch's firmware. The pre-write blob is snapshotted, so the change can be undone with rollback_change. Returns no_change when the values already match.

Input Schema

NameRequiredDescriptionDefault
dryRunNoPreview the resulting blob without writing to the switch.
fieldsYesValues to set, keyed by decoded field name (from list_swos_endpoints) or by a raw wire key already present in the blob — anything else is rejected. Option fields take the enum name (e.g. 'auto'); IP fields take a dotted quad (192.168.88.1) and MAC fields six hex pairs (64:d1:54:00:00:01); other text becomes a UTF-8 hex string; numbers and '0x...' strings are written as hex, padded to the width of the value they replace. A per-port field given a single value applies it to EVERY port.
endpointYes'.b' endpoint to write
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
    • changedInput schema / properties / fields / description
      Previous value: -"Values to set, keyed by decoded field name (from list_swos_endpoints) or by a raw wire key already present in the blob — anything else is rejected. Option fields take the enum name (e.g. 'auto'); text becomes a UTF-8 hex string; numbers and '0x...' strings are written as hex, padded to the width of the value they replace. A per-port field given a single value applies it to EVERY port."New value: +"Values to set, keyed by decoded field name (from list_swos_endpoints) or by a raw wire key already present in the blob — anything else is rejected. Option fields take the enum name (e.g. 'auto'); IP fields take a dotted quad (192.168.88.1) and MAC fields six hex pairs (64:d1:54:00:00:01); other text becomes a UTF-8 hex string; numbers and '0x...' strings are written as hex, padded to the width of the value they replace. A per-port field given a single value applies it to EVERY port."
  2. Addedv1.9.0

TDQS

A4.7/5.0
Behavior5/5

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

Discloses behavior well beyond the annotations: whole-blob write with byte-for-byte re-send of untouched fields, refusal of fields the firmware does not expose, the snapshot/rollback guarantee, and a no_change return when values already match. This is exactly the context a mutation tool with destructiveHint=true needs.

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?

The mutation and its mechanism are front-loaded, then safety (dryRun, rollback, refusal), then result reporting. Nearly every clause carries information an agent needs; there is no filler.

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?

With no output schema, the description correctly covers return semantics (schema-verification status, no_change). Combined with annotations that already declare destructiveness and idempotency, an agent has everything needed to call this correctly and safely.

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 description coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: that 'fields' are merged into the read blob rather than replacing it, and that dryRun previews rather than writes. It does not restate the field encoding rules the schema already covers, which is appropriate.

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 precise verb and resource ('Mutate a SwOS .b endpoint on a MikroTik switch') and immediately describes the read-modify-write mechanism. It clearly differentiates from read-side siblings like get_swos_endpoint, get_swos_config and list_swos_endpoints, and from apply_swos_config, so an agent can place it without opening a schema.

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 concrete operational guidance ('dryRun defaults to true — preview first') and names the recovery path ('the change can be undone with rollback_change'). It lacks an explicit statement of when to prefer this over apply_swos_config, so it falls short of full when/when-not coverage.

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