Skip to main content
Glama
enuno

UniFi MCP Server

by enuno
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

connector_network_get

Proxy a GET request to the Network Application via Cloud Connector.

Instructions

Proxy a GET request to the Network Application via Cloud Connector.

Forwards the request to https://api.ui.com/v1/connector/consoles/{console_id}/proxy/network/{path} and returns the raw response.

Args: console_id: UniFi console/host identifier (from list_hosts) path: Network API sub-path, e.g. api/s/default/stat/device settings: Application settings (UNIFI_SITE_MANAGER_ENABLED required) params: Optional query parameters

Returns: Raw response from the proxied Network API endpoint

Raises: ValidationError: If console_id or path is empty ValueError: If Site Manager API is not enabled

Input Schema

NameRequiredDescriptionDefault
pathYes
paramsNo
console_idYes
controllerNoController to run against (see list_controllers). Defaults to the controller chosen with select_controller, then the server default.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.6.0
    • addedInput schema / properties / controller
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Controller to run against (see list_controllers). Defaults to the controller chosen with select_controller, then the server default."
+}
  2. First observedv0.2.0

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden and it does disclose meaningful behavior: the request is forwarded to a specific upstream URL, the raw unprocessed response is returned, and it documents two failure modes (ValidationError on empty inputs, ValueError when Site Manager API is disabled). It omits auth requirements, rate limits, and idempotency, but covers prerequisites and errors better than most.

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?

The docstring-style Args/Returns/Raises layout is front-loaded with the core operation and endpoint before listing details. It is appropriately sized with little padding, though the Returns section partially duplicates what the output schema already provides.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a passthrough proxy tool with an output schema present, the description covers the operation, endpoint, required inputs, and error conditions adequately. The main gap is the absent 'controller' parameter and the phantom 'settings' entry, plus no explicit read-only safety statement given the lack of annotations.

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 coverage is only 25%, so the description is expected to compensate. It documents path (with example sub-path), console_id (with sourcing hint), and params, adding real value the schema lacks — but it also lists a 'settings' argument that does not exist in the input schema, while the actual 'controller' parameter goes unmentioned, creating a discrepancy that could mislead an agent.

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 (proxy a GET request) and resource (Network Application via Cloud Connector), even giving the exact upstream URL template. The verb+resource combination clearly distinguishes it from the sibling connector_network_post/put/patch/delete tools.

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

Usage Guidelines3/5

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

It points the agent to list_hosts for console_id and gives a concrete path example, which is useful context. However, it never states when to choose this tool over connector_network_post/put/patch or the list_integration_* alternatives, leaving selection to inference from the HTTP verb.

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

Deploy Server

Other Tools