mcp-mikrotik

poe_status

Retrieve live PoE status, voltage, current, and power per PoE-capable Ethernet port on a MikroTik device; returns empty list if no PoE hardware.

Instructions

PoE status/consumption per port, for every PoE-capable ethernet port on the device.

Reads /interface/ethernet and keeps only rows that have a poe-out field (i.e. are PoE-capable on this hardware - e.g. the CRS318-16P's high/low PoE ports), then reads /interface/ethernet/poe/monitor once=yes for each one to get its live voltage/current/power/poe-out-status. Each entry looks like {"interface", "poe-out" (configured mode), "poe-out-status", "voltage", "current", "power"} - the monitor fields are omitted for a port whose live monitor call fails (kept resilient rather than failing the whole tool for one bad port).

voltage/current/power are normalized to int | float | None via formatting.coerce_ros_number, never passed through raw: real hardware (CRS318-16P-2S+, ROS6.49.20) mixes int and string-decimal (e.g. "4.7") types for these same three fields within a single monitor reply, and across different ports of the same device - see that helper's docstring. Without this, a caller comparing voltage > 0 (see README's PoE power-cycle walkthrough) could get a string on one port and a number on another.

Returns an empty list (never an error) for a device with no PoE hardware at all - that's a completely normal state, same as wireless_registrations for a wired-only device.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`device_name`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.11.0Sep 13, 2026

TDQS

A4.2/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so richly: it names the underlying endpoints read, discloses the per-port read pattern, states the resilience policy (monitor fields omitted rather than failing the whole tool), explains the numeric coercion of voltage/current/power and the cross-port int/string type hazard it prevents, and declares the empty-list-not-error contract for non-PoE hardware.

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?

Front-loaded with the purpose sentence, then justified detail. Most of the length earns its place (coercion hazard, resilience contract), though it sprawls into internal references (README walkthrough, helper docstring) and restates the return shape that the output schema already covers.

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?

Given no annotations and a single self-evident parameter, the description supplies everything an agent needs: what it reads, what the output contains, the type-normalization guarantee, and the failure semantics. It arguably over-delivers by describing the return shape despite an output schema existing.

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% and the single parameter device_name is never mentioned in the description, so no naming/format convention is added. However, the parameter is a self-evident device identifier in a device-oriented server, so the gap is minor rather than severe.

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 resource and verb scope: 'PoE status/consumption per port, for every PoE-capable ethernet port on the device.' It is immediately distinguishable from set_poe_out (the write sibling) and from interface_monitor, since it declares the exact interface set it enumerates.

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

Usage Guidelines3/5

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

Usage is implied by the description (read live PoE data; safe on non-PoE devices returning an empty list), but there is no explicit 'use this instead of X' or when-not guidance relative to siblings like interface_monitor or interface_traffic. The reader must infer the selection criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server