Skip to main content
Glama
Sign In
MikroTik MCP

MikroTik MCP

by wiresage
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

list_bridge_ports

Read-onlyIdempotent

List bridge ports and their PVIDs on a MikroTik device, with optional bridge and interface filters to inspect VLAN port assignments.

Instructions

Lists bridge ports on the MikroTik device, including each port's PVID.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_bridge_ports"
  }
}

Input Schema

NameRequiredDescriptionDefault
deviceNo
bridge_filterNo
interface_filterNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.27.0

TDQS

B3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds that PVID is included in results, which is mild value-add context, but says nothing about filtering behavior, empty results, or device selection semantics.

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 single front-loaded sentence with no filler or redundancy. It is efficient, though its brevity is part of why usage and parameter gaps remain.

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 explained, and the read-only nature is covered by annotations. Still, for a three-parameter tool with zero schema coverage, the description omits how the filters interact and when an agent should reach for this listing instead of related bridge tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All three parameters (device, bridge_filter, interface_filter) have 0% schema description coverage, so the description carries the full burden of explaining them and explains none. Their names are reasonably self-explanatory, which keeps this above a 1, but filter matching semantics (exact vs substring) and the device string format are 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?

States a specific verb and resource (lists bridge ports) plus an extra returned field (PVID), which is more than a restatement of the name. It does not explicitly distinguish itself from nearby siblings such as list_bridge_vlans or update_bridge_port, so sibling routing is left implicit.

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, no mention of prerequisites (e.g. a bridge must exist, a device selected), and no pointer to update_bridge_port or list_bridge_vlans for adjacent tasks. Usage can only be inferred from the tool name.

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