Locate a field by name across every endpoint, including inside discriminator variants.

Returns one line per occurrence: endpoint slug, dotted path, and which schema section it sits in (request body, parameters, or response). Common names appear hundreds of times; the reply is capped at 50 and states the true total and how many endpoints are involved, so a short list is never mistaken for a complete one. Paths from here can be passed straight to get_field_schema. A name that matches nothing returns close alternatives.

Report what documentation this server is serving.

Returns one line per application: API version, when it was scraped, and how many endpoints and guides it holds. Worth checking before trusting an answer about a recent API change — the documentation is a point-in-time copy, not a live view.

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.

See every operation on one resource at once, grouped by API path.

Returns each matching resource path with its endpoints beneath it — method, slug, title and a one-line description — so the available verbs on a resource are visible together rather than found one at a time. Matching is a substring of the path, so 'networks' also finds nested paths, and one query can span applications.

Get a runnable request for one endpoint, in one language, as published by Ubiquiti.

Returns a heading naming the endpoint, language and mode, followed by a single code block. The request shape is authoritative; host addresses, site ids and API keys are placeholders to fill in. Bodies show the schema's default values, not a worked example — combine with get_endpoint or get_field_schema when the payload matters. If the requested language and mode pair does not exist, the reply lists the pairs that do instead of failing.

Drill into a specific field's schema within an endpoint.

Instead of fetching the full 70KB endpoint schema, use this to get just the subtree you need. Paths from find_field output work directly.

Read a prose guide page: filtering syntax, error handling, getting started, response formats.

Returns the page as markdown with its title and source URL. Omit the topic to list what is available. Topics resolve by slug first, then by title; when the same slug exists in several applications the reply lists them and asks for an app rather than picking one. These pages carry the conventions that endpoint schemas assume but do not repeat.

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.

Browse the endpoint catalogue: one line per endpoint with method, path, slug and title.

Returns at most 200 lines; beyond that the reply says how many were withheld and which filters would narrow it. For finding a specific endpoint, search_endpoints ranks by relevance instead. Unknown filter values are rejected by name rather than returned as an empty result.

Find endpoints by name, path fragment, method or description.

Returns up to ten matches ranked by relevance, each as a slug, method, path, title and a one-line description. Matching is fuzzy but floored: a query that resembles nothing returns no matches rather than the least-bad guess. Pass a result's slug to get_endpoint for the full schema. Unknown filter values are rejected by name.