Un servidor MCP de UniFi Network enfocado y de solo lectura que proporciona vistas limitadas de salud, dispositivos y clientes activos. Extraído del commit 2e63f009d8f4642e17398685baef0251811d6637 de spectrenet-mcp; este repositorio es autónomo.
Exactamente tres herramientas de lectura: network_health, devices y clients; sin herramientas de configuración, comando, adopción, reinicio, bloqueo u otras herramientas de mutación.
Las solicitudes de datos del dispositivo usan solo HTTP GET (la autenticación necesariamente usa POST /api/auth/login).
La verificación del certificado TLS y del nombre de host está habilitada por defecto.
Las redirecciones de autenticación y de datos del dispositivo se rechazan en lugar de seguirse.
El sitio configurado se codifica como un segmento de ruta URL, y los sufijos de endpoint están en una lista blanca cerrada.
Los bytes de respuesta HTTP, las longitudes de las listas devueltas, los campos proyectados y los campos de auditoría están limitados.
Las credenciales y las respuestas completas no se auditan.
Related MCP server: UniFi MCP Server
Esto apunta a las rutas de proxy de la consola UniFi OS /api/auth/login y /proxy/network/api/s/{site}/..., observadas en dispositivos modernos con UniFi OS. Los controladores UniFi Network autoalojados más antiguos suelen usar /api/login y /api/s/... sin proxy; esos no son compatibles. Ubiquiti cambia los endpoints privados/internos entre versiones de dispositivo y de Network Application. No se certifica ninguna matriz de versiones: prueba esta versión alfa contra tu firmware de consola y versión de Network Application exactos en un entorno que no sea de producción, y fija las actualizaciones operativamente.
uv sync --extra test
uv run unifi-safe-mcp --help
uv run unifi-safe-mcpEl servidor usa MCP stdio y no carga .env. Trata .env.example como documentación falsa únicamente; inyecta una cuenta dedicada de solo lectura a través de un supervisor/gestor de secretos.
uv sync --locked --extra test
uv run --locked pytest
uv run --locked python -m compileall -q src tests
uv buildConsulta arquitectura, compatibilidad y seguridad. MIT © 2026 Ben Gauger.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0clientsdevicesnetwork_healthScored across 3 tools
The three tools—network_health, devices, and clients—each address a distinct aspect of a UniFi network with no overlap in purpose. An agent can easily differentiate between them based on their names.
All three tool names are single nouns following a consistent pattern (no verbs or mixed conventions). While this differs from the common verb_noun style, the naming is internally consistent and predictable.
With only three tools, the server is minimal but within the acceptable range for a focused network management utility. The count feels proportionate to the narrow scope of health, device, and client visibility.
The server covers only basic read‑only operations for network health, devices, and clients. It lacks essential UniFi features such as site management, configuration changes, or traffic monitoring, leaving significant gaps for most real‑world use cases.
Read-only MCP access to a documented IT fleet: state, changes, posture. 15 tools.
Governed MCP gateway: one endpoint for your tools, with credential custody and audit log.
XFA's remote MCP server — query device posture, compliance, policies & CVEs. Read-only.
Read-only MCP access to sessions, funnels, campaigns, errors, live visitors, and anomalies.
