mcp-mikrotik

security_audit

Inspect a MikroTik router's configuration in read-only mode for insecure services, firewall gaps, exposed SNMP/DNS, outdated RouterOS, open wireless, and expiring certs; return prioritized findings.

Instructions

Read-only security audit of a device's configuration - gives an LLM caller (or operator) a structured list of findings to review, so it can "look at the security of this router" without an operator manually walking every menu.

Aggregates several independent, defensive checks - see src/mcp_mikrotik/security.py for the full list and reasoning: insecure management services (/ip/service: telnet/ftp/www/api enabled, and whether they're open to any address), whether the firewall's input chain ends in a drop/reject rule (heuristic), SNMP community exposure (/snmp/community), an open DNS resolver (/ip/dns allow-remote-requests), outdated RouterOS (/system/package/update), open wireless/wifi networks (no security profile / no passphrase), a count of users with a write/full policy, and (v1.6) an expired or soon-to-expire (<=30 days) certificate (/certificate).

Each check reads its own menu(s) and skips itself (contributing no findings) if that menu doesn't exist on this device/RouterOS generation - one missing/unsupported menu never fails the whole audit. NEVER a scanner, NEVER definitive - this is a heuristic, best-effort read meant to prompt a human decision, not to replace one; see README's "Security audit" section for the full disclaimer.

READ-ONLY: does not change anything on the device, and is not gated by MIKROTIK_ALLOW_WRITE.

NO SECRET IS EVER RETURNED: no finding ever includes a password, passphrase, or SNMP community string - see security.py's module docstring for exactly how each check avoids that.

Returns {"findings": [{"severity", "category", "title", "detail", "recommendation"}, ...], "summary": {"high", "medium", "low", "info"}} - findings sorted by severity (high first), summary always including all four keys (0 for a severity with no findings).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`device_name`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.11.0Sep 13, 2026

TDQS

A4.4/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 thoroughly: read-only, not gated by MIKROTIK_ALLOW_WRITE, no secret/passphrase/community string ever returned, per-check graceful skip on missing menus, and one missing menu never failing the whole audit. This is exactly the behavioral context an agent needs before calling.

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?

Well front-loaded (purpose first, then checks, then caveats, then READ-ONLY and NO SECRET headers) and structured with clear emphasis. It is somewhat verbose and spends sentences pointing at source files and README sections that an agent cannot use.

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 multi-check aggregate audit tool, the description enumerates the checks, the failure mode, the safety profile, and the return shape. With an output schema also present, nothing an agent needs to call this correctly is missing.

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 the description adds no meaning beyond the schema. However, the parameter is trivially self-describing by name, which keeps this at a minimum-viable 3 rather than lower.

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+scope: 'Read-only security audit of a device's configuration'. It immediately distinguishes itself from siblings like firewall_filter, security_events, and certificates by being an aggregate audit rather than a raw menu dump.

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

Usage Guidelines4/5

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

Gives clear context for use ('look at the security of this router' without an operator manually walking every menu) and a firm boundary ('NEVER a scanner, NEVER definitive... meant to prompt a human decision'). It does not explicitly route the agent to or away from specific sibling tools, so it stops short of a 5.

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

Deploy Server