Skip to main content
Glama
enuno

UniFi MCP Server

by enuno
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

connector_protect_get

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

Instructions

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

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

Args: console_id: UniFi console/host identifier (from list_hosts) path: Protect API sub-path, e.g. v1/cameras settings: Application settings (UNIFI_SITE_MANAGER_ENABLED required) params: Optional query parameters

Returns: Raw response from the proxied Protect 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.7/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses the enablement prerequisite (Site Manager API required), the exact upstream URL, that the raw response is returned, and two named failure modes (ValidationError on empty console_id/path, ValueError when Site Manager is disabled). It omits read-only confirmation, rate limits, and pagination behavior.

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?

Purpose and target URL are front-loaded, followed by cleanly separated Args/Returns/Raises sections. Slightly verbose in the URL restatement but every block serves a purpose.

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?

An output schema exists, so return-value detail is not required, and the description still characterizes the response as raw upstream output. For a proxy tool it covers prerequisites and errors adequately, missing only pagination/limits and the param-list discrepancy noted above.

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 only 25% (just 'controller'), so the description must compensate and largely does: console_id (from list_hosts), path (e.g. 'v1/cameras'), params (optional query params). However, it documents a 'settings' argument that does not exist in the schema while never addressing the schema's 'controller' parameter, creating a mismatch that could confuse an agent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Proxy a GET request to the Protect Application via Cloud Connector') and pins the exact target URL, so it is clearly distinct from connector_protect_post/put/patch/delete and connector_network_get. It never names a sibling explicitly, but the HTTP-method framing makes the family separation unambiguous.

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?

No explicit when-to-use or when-not-to-use guidance against the sibling connector_* tools. It does imply workflow context by noting console_id comes 'from list_hosts' and that UNIFI_SITE_MANAGER_ENABLED is required, which is useful but falls short of routing guidance.

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