mcp-unifi-applications

by KallistoX

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Get Endpoint

get_endpoint

Read-onlyIdempotent

Fetch the full API reference for a single UniFi endpoint: method, path, parameters, request body, and response fields.

Instructions

Get everything documented about one endpoint: method, path, description, path and query parameters, request body and response fields.

Returns readable text: a nested field list with types, required markers and descriptions, discriminator variants in brackets and enum values inline, folded at three levels deep. Large endpoints run to tens of thousands of characters — when you already know which field you need, get_field_schema returns that subtree alone. An unknown slug returns close matches rather than an error.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`slug`	Yes	Endpoint identifier, app-qualified ('network/createnetwork') or bare ('createnetwork') when only one application has it. Use search_endpoints or list_endpoints to find one.
`summary`	No	True (default) returns the folded text above. False returns the raw scraped JSON — complete and unfolded to every depth, several times larger, and only worth it when the folding hides something you need.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.3.1Sep 10, 2026

changedInput schema / properties / slug / description

Previous value: -"Endpoint identifier, app-qualified ('network/createnetwork') or bare\n  ('createnetwork') when only one app has it. Use list_endpoints or\n  search_endpoints to find slugs."New value: +"Endpoint identifier, app-qualified ('network/createnetwork') or bare\n  ('createnetwork') when only one application has it. Use\n  search_endpoints or list_endpoints to find one."

changedInput schema / properties / summary / description

Previous value: -"If True, return a compact field summary. If False, return raw JSON."New value: +"True (default) returns the folded text above. False returns the raw\n     scraped JSON — complete and unfolded to every depth, several times\n     larger, and only worth it when the folding hides something you need."

Changed1 schema field changedv0.3.0Sep 10, 2026

changedInput schema / properties / slug / description

Previous value: -"Endpoint identifier (e.g. 'createnetwork', 'listnetworks').\n  Use list_endpoints or search_endpoints to find slugs."New value: +"Endpoint identifier, app-qualified ('network/createnetwork') or bare\n  ('createnetwork') when only one app has it. Use list_endpoints or\n  search_endpoints to find slugs."

First observedSep 9, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already mark this as read-only and idempotent, and the description adds substantial behavioral context: it returns readable folded text, folds at three levels deep, may be tens of thousands of characters, and returns close matches for unknown slugs. This goes well beyond the annotation signal and prepares the agent for output size and error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, then covers output format, size, the alternative tool, and error behavior in a compact, well-organized set of sentences. Every sentence earns its place and no information is repeated or wasted.

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

Completeness5/5

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

Given that an output schema is present, return-field documentation is not the description's job. It covers tool scope, output format, scale warning, a recommended sibling for narrower use, and unknown-slug behavior, making it complete for an agent to select and invoke the tool confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides full, detailed descriptions for both parameters, so the baseline is a 3. The description adds extra behavioral nuance by mentioning the large-output problem and the get_field_schema fallback, and by explaining that unknown slugs still produce useful matches. It does not deeply re-document the parameters, but what it adds is meaningful.

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?

The description opens with a specific verb and resource: 'Get everything documented about one endpoint' and enumerates exactly what is included (method, path, parameters, request body, response fields). It also implicitly distinguishes itself from siblings by pointing to get_field_schema for narrower field-level queries, so an agent can tell which tool fits.

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

Usage Guidelines5/5

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

The description explicitly says to use get_field_schema when you already know the specific field, giving a concrete when-to-use alternative. It also warns that large endpoints produce very large output, and explains that an unknown slug returns close matches rather than an error, which helps an agent anticipate and handle edge cases.

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

Deploy Server