mcp-unifi-applications

Overview Schema Source Related Servers Discussions Admin

Get Response Sample

get_response_sample

Read-onlyIdempotent

Retrieve the exact sample JSON response for any UniFi API endpoint, with placeholder values as shown in official docs. Quickly see the shape of a successful reply.

Instructions

Get the sample response body published for one endpoint.

Returns raw JSON exactly as the documentation shows it, with placeholder values. About two thirds of endpoints have one; the rest say so plainly. This is the shape of a successful reply — for the field-by-field schema including types and which fields are optional, use get_endpoint.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`slug`	Yes	Endpoint identifier (e.g. 'network/getnetworksoverviewpage').

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.3.0Sep 10, 2026

changedInput schema / properties / slug / description

Previous value: -"Endpoint identifier (e.g. 'listnetworks')."New value: +"Endpoint identifier (e.g. 'network/getnetworksoverviewpage')."

First observedSep 9, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive behavior, and the description adds value by disclosing placeholder values, exact matching to documentation, and that missing samples are communicated plainly. It does not mention auth or rate limits, but these are not strongly demanded given the safe read-only profile.

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 compact and front-loaded with the clear purpose, followed immediately by return behavior and a routing note. Every sentence contributes either scope, capability, expectation-setting, or a pointer to the alternative tool.

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?

There is an output schema, one required parameter documented fully, and complete annotations covering safety and idempotence. The description adds availability expectations and points to get_endpoint for schema details, which leaves an agent with enough to invoke the tool correctly.

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 100% and includes a concrete slug example, so the parameter meaning is already fully established. The description adds only broad context that the tool targets 'one endpoint', which does not go beyond the schema.

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?

Description states a specific verb and resource: 'Get the sample response body published for one endpoint' and clarifies that it returns raw JSON as shown in documentation. It also differentiates itself by directing field-by-field schema needs to get_endpoint, so an agent can pick the right tool.

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 gives context for expected behavior: about two-thirds of endpoints have a sample and the rest say so plainly. It also names the alternative, get_endpoint, for schema/type/optional-field detail, making the choice between sibling tools clear.

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

Deploy Server