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 어플라이언스에서 관찰된 UniFi OS 콘솔 프록시 경로 /api/auth/login 및 /proxy/network/api/s/{site}/...를 대상으로 합니다. 오래된 자체 호스팅 UniFi Network Controller는 일반적으로 /api/login 및 비프록시 /api/s/...를 사용합니다. 이러한 경로는 지원되지 않습니다. Ubiquiti는 어플라이언스 및 Network Application 버전 간에 비공개/내부 엔드포인트를 변경합니다. 인증된 버전 매트릭스는 없습니다. 이 알파 버전을 정확한 콘솔 펌웨어 및 Network Application 버전에 대해 비프로덕션 환경에서 테스트하고, 업그레이드를 운영적으로 고정하십시오.
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.
