librenmsctrl

Active

Your LibreNMS UI shows you a wall of green and one red row, but your agent cannot read it and your scripts have to hand-roll REST calls against the token. librenms-mcp gives shells, cron, and any MCP client a typed command surface over your monitored network: devices, ports, port health, alerts, alert history, and events, with every write gated behind an explicit confirm.

13 tools10 reads / 3 gated writeswrite-gatedNode 20+MIT

See it work

one question, the tools it calls, the answer

representative session · claude + librenms-mcp
What is alerting right now, and which port on the worst device is actually the problem?
librenms_list_alerts{ state: 1 }
2 active 7 core-sw1 (203.0.113.4) port errors_in above threshold active 8 edge-rtr2 (203.0.113.9) device down active
librenms_port_health{ device: "core-sw1", metric: "errors_in", limit: 5 }
Gi1/0/24 errors_in 4213/s utilization 91% uplink to edge-rtr2
librenms_ack_alert{ id: 7 }
WriteGateError: write requires confirm: true
core-sw1 Gi1/0/24 is the uplink to the down edge-rtr2, and it is pegged at 91% with rising input errors. That one link explains both alerts. I stopped short of acking alert 7 since the gate needs confirm: true, so it is yours to approve.

Representative session. Illustrative values, RFC 5737 addresses. Reads are open, writes need confirm: true, and your token never leaves the box.

What it does

Point any MCP client, or a plain shell, at librenms-mcp and your LibreNMS instance becomes a scriptable control surface instead of a UI you have to click through. It authenticates with a LibreNMS API token, talks to the `/api/v0` REST API under the hood, and exposes 13 named tools that emit structured data an agent can reason over or human-readable tables you can pipe. It differs from handing an agent a generic HTTP tool and the raw token in the way that matters once a write is possible: every write is refused unless the call carries `confirm: true`, every argument is bounds- and enum-checked against a published TypeBox schema before a URL is built, and the token is redacted from all output, so a hallucinated tool call cannot change your monitoring state by accident. The read-only `librenmsctrl` CLI shares the same client core for cron and CI.

Capabilities

13 tools across the monitoring surface

Devices & inventory3 tools
Instance status, list monitored devices, fetch a single device by id.
Ports & health3 tools
List ports across devices, pull one port detail, view port health and utilization.
Alerts & events4 tools
List and fetch current alerts, read alert history, tail the device event log.
Safe writes (gated)3 tools
Acknowledge an alert, unmute an alert, set device maintenance. Each needs confirm: true.
Full reference on GitHub →

Set it up

npm install -g @solomonneas/librenms-mcp

Needs Node 20+ and two env vars: LIBRENMS_URL and LIBRENMS_TOKEN (start with a Read Only token role). LIBRENMS_TLS_INSECURE=true is optional for homelab self-signed certs.

MCP client config
{ "mcpServers": { "librenms": { "command": "npx", "args": ["-y", "@solomonneas/librenms-mcp"], "env": { "LIBRENMS_URL": "https://librenms.example.local", "LIBRENMS_TOKEN": "<your-api-token>" } } } }
[ shield ]

Writes are gated in three tiers. Reads (tier 1) are open. Safe writes (tier 2: ack, unmute, set maintenance) require an explicit `confirm: true` argument, so a call missing the flag throws `WriteGateError` before any HTTP traffic leaves the host. Destructive operations (tier 3: device deletion, alert-rule removal, bulk port resets) are intentionally not implemented in v1. Every argument is validated against its TypeBox inputSchema and interpolated path and query values are URL-encoded, so a malformed or injection-style argument is rejected up front. The API token is registered with a redactor on startup and masked from all log and error output.

13
MCP tools
10
open reads
3
confirm-gated writes
0
destructive ops in v1
MIT
license