unifi-console-mcp

Overview Schema Source Related Servers Discussions Admin

unifi_console_static_dns

Destructive

Preview and apply changes to a UniFi gateway's local DNS records (A, AAAA, CNAME, MX, SRV, TXT) with a two-step confirm and fingerprint verification.

Instructions

Preview, then apply, a change to the gateway's Local DNS records (A, AAAA, CNAME, MX, SRV, TXT).

Two steps, always: call with confirm=false to get a read-only preview (before, after, diff, warnings, a fingerprint); call again with the same fields plus confirm=true and that fingerprint to apply. The record is re-read first, so a stale preview is refused. The gateway answers these names for every client, so the preview warns when a name is outside example.home (it replaces the public answer), refuses duplicates, the CNAME rule and names a client already publishes, and lists CNAME records that point at a record you change or remove. The console only accepts the whole record, so updates send all of it. Applying also needs UNIFI_CONSOLE_ENABLE_WRITES=true and 'static_dns' in UNIFI_CONSOLE_WRITE_ENTITIES. After applying, the record is read back and the result reports verified true/false, the diff, and the exact rollback call. Every write is journalled.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "params": "<params>"
    },
    "name": "unifi_console_static_dns"
  }
}

Input Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 18, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations declare the safety profile (destructive, non-idempotent, not read-only), but the description adds substantial context beyond them: the mandatory preview/apply handshake, fingerprint staleness enforcement, the write-enable env vars (UNIFI_CONSOLE_ENABLE_WRITES, static_dns), read-back verification with a verified flag, a rollback call, and journaling. It also explains that the console only accepts the whole record, which is essential for a mutation tool.

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?

Front-loaded with the core two-step workflow, then layers on validation, prerequisites, and post-apply behavior. It is a dense block rather than short, but nearly every sentence conveys actionable information; only the warnings enumeration is slightly list-like.

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?

For a destructive mutation tool with an output schema, the description supplies everything an agent needs: the two-phase call sequence, prerequisites, validation behavior, and post-apply verification/rollback. Return-value details are correctly left to the output schema.

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?

Schema coverage is reported at 0% for the wrapper object, so the description carries weight here, and it does add meaning: confirm/fingerprint semantics, the full-record update rule, and the impact of applying (re-read, verified, rollback). It does not restate per-field rules (target, ttl, record_type), which the nested schema does document, so it stops at 4 rather than fully compensating.

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+resource: managing the gateway's Local DNS records, and enumerates the record types (A, AAAA, CNAME, MX, SRV, TXT) it covers. The 'Local DNS' scoping cleanly separates it from the sibling unifi_console_dynamic_dns, so an agent can pick the right tool without opening either schema.

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

Usage Guidelines4/5

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

Gives explicit procedural guidance: call with confirm=false for a preview, then call again with the same fields plus confirm=true and the fingerprint, with the note that stale previews are refused. It also lists the refusal/validation conditions (duplicates, CNAME rule, names a client already publishes). It never names an alternative tool or says when NOT to use this one, so it stops short of a 5.

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