一个专注的、只读的 UniFi Network MCP 服务器，提供有界的健康、设备和活动客户端视图。提取自 spectrenet-mcp 提交 2e63f009d8f4642e17398685baef0251811d6637；此仓库是自包含的。
恰好三个只读工具：network_health、devices 和 clients；没有配置、命令、采用、重启、阻止或其他变更工具。
设备数据请求仅使用 HTTP GET（身份验证必然使用 POST /api/auth/login）。
默认启用 TLS 证书和主机名验证。
拒绝身份验证和设备数据重定向，而不是跟随。
配置的站点编码为一个 URL 路径段，端点后缀采用封闭白名单。
HTTP 响应字节、返回列表长度、投影字段和审计字段均有界。
不审计凭据和完整响应。
Related MCP server: UniFi MCP Server
这针对 UniFi OS 控制台代理路径 /api/auth/login 和 /proxy/network/api/s/{site}/...，在现代 UniFi OS 设备上观察到。较旧的自托管 UniFi Network Controller 通常使用 /api/login 和非代理的 /api/s/...；这些不受支持。Ubiquiti 在设备和 Network Application 版本之间更改私有/内部端点。没有经过认证的版本矩阵：在非生产环境中，针对您的确切控制台固件和 Network Application 版本测试此 alpha 版本，并在操作上固定升级。
uv sync --extra test
uv run unifi-safe-mcp --help
uv run unifi-safe-mcp服务器使用 MCP stdio，不加载 .env。将 .env.example 仅视为虚假文档；通过监督者/密钥管理器注入专用的只读账户。
uv sync --locked --extra test
uv run --locked pytest
uv run --locked python -m compileall -q src tests
uv build| 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.
