Skip to main content
Glama
Sign In
MikroTik MCP

MikroTik MCP

by wiresage
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

add_bridge_vlan

Adds a bridge VLAN table entry to define tagged and untagged port membership for specified VLAN IDs, enabling VLAN configuration on MikroTik bridges.

Instructions

Adds an entry to the bridge VLAN table defining tagged/untagged port membership.

Notes: vlan_ids: single ID, comma list, or range e.g. "10", "10,20", "100-199" tagged: comma-separated ports carrying these VLANs tagged e.g. "ether1,ether2" untagged: comma-separated ports carrying these VLANs untagged

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "bridge": "<bridge>",
      "vlan_ids": "<vlan_ids>"
    },
    "name": "add_bridge_vlan"
  }
}

Input Schema

NameRequiredDescriptionDefault
bridgeYes
deviceNo
taggedNo
commentNo
disabledNo
untaggedNo
vlan_idsYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.27.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=false and openWorldHint=false, so the safety profile is covered. The description adds the semantic meaning of the created entry but omits useful behavior: what happens on duplicate VLAN IDs, whether it requires the bridge to exist, and any permission or rate-limit context. A moderate addition over annotations.

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?

The main sentence is front-loaded and specific, followed by a compact notes block with format examples. The structure is efficient, though the unexplained parameters mean the notes could have been extended rather than trimmed.

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?

An output schema exists, so return values need not be described. But for a 7-parameter mutation on a network device, the definition leaves prerequisites, the role of bridge/device, and the effect of disabled/comment unstated, which is a meaningful gap even for an expert agent.

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 0%, so the description must compensate, and it does explain the three trickiest string parameters with concrete syntax examples for vlan_ids, tagged, and untagged. However, four parameters (bridge, device, comment, disabled) receive no explanation at all, leaving half the surface undocumented.

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?

The description names a specific verb and resource ("Adds an entry to the bridge VLAN table") and clarifies the entry's meaning as tagged/untagged port membership. It doesn't explicitly distinguish itself from siblings like update_bridge_vlan or create_vlan_interface, but the add-vs-update-vs-remove split is inferable from the name and phrasing.

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?

There is no statement of when to use this tool versus alternatives such as update_bridge_vlan or create_vlan_interface, and no prerequisites are given (e.g. that the bridge and VLAN interfaces must already exist). Usage is only implied by the word "Adds".

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