NextDNS-Agent-MCP

restore_backup

Destructive

Put a saved NextDNS backup back as a new profile or over an existing profile; confirm overwrites before applying.

Instructions

Put a saved backup back, either as a new profile (new_profile_name, overwrites nothing) or over an existing one (by default the profile it was taken from); take the ID from backups. Overwriting asks twice: the first call changes nothing and gives a code; ask the user, and only after they say yes, call again with confirm_code. Either way it's recorded, so undo can reverse it (undoing a new profile deletes it). Returns what was restored, any parts that didn't come back, and the change ID.

Input Schema

TableJSON Schema

Name	Required	Description
`profile`	No	The profile to overwrite. Empty means the one the backup was taken from.
`backup_id`	Yes	The backup's ID, from backups.
`confirm_code`	No	Leave empty on the first call. After the user says yes, pass the code the first call gave you.
`new_profile_name`	No	Make a new profile with this name from the backup instead, so nothing is overwritten.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 21, 2026

addedInput schema / properties / backup_id / description
```
Added value: +"The backup's ID, from backups."
```

addedInput schema / properties / confirm_code / description

Added value: +"Leave empty on the first call. After the user says yes, pass the code the first call gave you."

addedInput schema / properties / new_profile_name / description

Added value: +"Make a new profile with this name from the backup instead, so nothing is overwritten."

addedInput schema / properties / profile / description

Added value: +"The profile to overwrite. Empty means the one the backup was taken from."

First observedv0.8.1Oct 20, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, and the description goes well beyond them: it discloses the two-phase confirmation gate, that the first call changes nothing and returns a code, that overwriting destroys the target profile, that new-profile mode destroys nothing, that the action is logged so undo can reverse it (and undo of a new profile deletes it). This is precisely the destructive/auth/irreversibility context an agent needs.

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 action and the two modes, and it ends with return-value coverage. However, the long parenthetical clauses make it denser and more run-on than necessary; a few sentences could be tightened.

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 four parameters, full schema coverage, a destructive annotation profile, and an existing output schema, the description covers everything else an agent needs: the two-step confirmation protocol, the undo relationship, and the shape of the result (restored items, parts that failed, change ID). Nothing material is missing.

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 100%, so the baseline is 3; the description still adds meaning by explaining that profile defaults to 'the profile it was taken from' and by framing confirm_code as the output of the first call rather than a user-supplied value. It does not add syntax detail beyond the schema, so it stays modestly above baseline.

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 ('Put a saved backup back') and immediately distinguishes the two operating modes (new profile vs. overwrite). An agent can separate this from siblings like backup, backups, delete_profile, and undo without opening any schema.

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?

Explicitly prescribes when to use each path: new_profile_name overwrites nothing, while the overwrite path defaults to the source profile. It also routes the agent to the 'backups' sibling for the ID and gives an explicit two-step call protocol (first call, ask user, second call with confirm_code).

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