Skip to main content
Glama
AliKarami

MikroMCP

by AliKarami
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Apply SwOS Config

apply_swos_config
DestructiveIdempotent

Apply a SwOS switch config safely: plan every change first, default to dry run, snapshot endpoints for rollback, and block risky management or lockout changes unless explicitly allowed.

Instructions

Apply a switch config document (the format get_swos_config exports) to a SwOS switch. Plans every change against the switch first; dryRun defaults to true. Writes only the endpoints that change: the VLAN table grows first (new VLANs and members), then the per-port settings (VLAN, isolation, storm and flood control), port names/negotiation/enabled, LAG and SNMP, then the table shrinks (removed VLANs and members), then system — so no port loses its VLAN mid-apply. Refuses management changes (address, allow-from) unless includeManagement is true, and any plan that would cut a linked port off (its untagged VLAN moved or dropped, a trunk losing tagged VLANs or becoming an access port, a forced VLAN, a port that starts filtering VLANs, the port disabled, renegotiating, isolated from another linked port or moved in or out of a LAG, every linked port dropped from allow_from_ports; only risks the plan introduces) unless acceptLockoutRisk is true. All six endpoints are snapshotted before a real apply, so rollback_change restores the previous state; the result names any endpoint whose snapshot failed, and says so when none was recorded. A document that moves management to another VLAN (allow_from_vlan) and changes a port's VLAN settings or the VLAN table's membership at the same time is refused, because that cannot be written in a safe order (sys.b goes last and cuts the session): apply the VLAN changes first, then the move. snmp.community may reference only the secrets bound to the switch (its secrets list in routers.yaml); a switch without a list may reference none.

Input Schema

NameRequiredDescriptionDefault
configYesThe switch config: a YAML document (as text) or the same structure as an object. `version: 1`, then any of `system`, `ports`, `vlans`, `snmp`; only the settings it names are changed. `snmp.community` may be `${NAME}`, replaced by the server's MIKROMCP_SECRET_<NAME> value; no other field may reference a secret.
dryRunNoPlan and show every change without writing to the switch.
routerIdNoRouter ID; omit to use the default router.
pruneVlansNoWhen the config has a `vlans` list, remove VLANs the switch has but the list does not.
acceptLockoutRiskNoApply a plan whose warnings show a linked port being cut off (its VLAN, untagged traffic, link, isolation or LAG changing). Refused unless this is true; a dry run shows the warnings without it.
confirmationTokenNoToken from a prior APPROVAL_REQUIRED response. Re-submit the identical call with this token to confirm the destructive action.
includeManagementNoAllow changes to how the switch is reached: address acquisition, static IP and the allow-from settings. Refused unless this is true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.14.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare destructive/idempotent; the description adds the write ordering (VLANs first, table shrink last), the full list of lockout-risk conditions, the six-endpoint snapshot before a real apply, the rollback_change recovery path, the management-change refusal, the safe-order refusal for management moves, and the secrets binding rule for snmp.community.

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?

It is a single dense paragraph, but it is front-loaded with the core action and the dryRun default, and the chronological ordering gives it structure. Nearly every clause carries a distinct rule, so the length is justified by the tool's complexity, though the run-on semicolon chains hurt scanability.

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 high-risk, 7-parameter tool with no output schema, the description covers the missing surface: result reporting on snapshot failures, refusal conditions, secret scoping, ordering constraints, and the rollback path. An agent has everything needed to call it 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: the dryRun default, the refusal semantics behind includeManagement/acceptLockoutRisk, the confirmationToken approval flow, and that pruning/table shrink is tied to the vlans list. The parameter-to-behavior mapping is clearer here than in the schema alone.

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+resource: 'Apply a switch config document (the format get_swos_config exports) to a SwOS switch.' It ties itself to its siblings get_swos_config (producer of the format) and rollback_change (which reverses it), so an agent can distinguish it without opening another schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use and when-it-refuses: dryRun defaults to true, includeManagement gates management changes, acceptLockoutRisk gates plans that cut off linked ports, and confirmationToken handles the APPROVAL_REQUIRED flow. It even gives ordering advice for the multi-step management-move case ('apply the VLAN changes first, then the move').

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