NextDNS-Agent-MCP

delete_profile

Destructive

Permanently delete a NextDNS profile and its query logs, requiring double confirmation to prevent accidental removal.

Instructions

DELETES a whole profile and its logs. Devices using it stop being filtered. Only when the user asked. Needs a double confirmation: the first call deletes nothing and gives a code; ask the user, and only after they say yes, call again with confirm_code. undo can make a new profile with the same settings and lists, but with a new ID (devices must be set up again), and the logs are gone for good.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`profile`	Yes	The profile's ID or name.
`confirm_code`	No	Leave empty on the first call. After the user says yes, pass the code the first call gave you.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 21, 2026

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 / profile / description
```
Added value: +"The profile's ID or name."
```

First observedv0.8.1Oct 20, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already mark the tool destructive and non-idempotent, but the description adds crucial behavior beyond them: a double-confirmation workflow, no deletion on the first call, permanent log loss, devices becoming unfiltered, and the fact that undo creates a new profile ID requiring device setup again. This is exactly the behavioral context an agent needs for a destructive tool.

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 destructive action and scope, then proceeds through usage constraints and confirmation mechanics. Every sentence contributes necessary safety or recovery information.

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?

The tool is complex and destructive, but the description covers the deletion scope, confirmation flow, recovery limitations, and permanent consequences. With annotations and an output schema also present, nothing essential 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 schema already defines both parameters. The description adds meaningful workflow semantics for confirm_code: leave it empty first, then pass the code returned by the first call only after user confirmation.

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 gives a specific verb and resource: it deletes a whole profile and its logs, and it states the effect that devices stop being filtered. It also distinguishes the action from recovery via undo, making the destructive scope clear.

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?

It explicitly says to use this only when the user asked, describes the required two-step confirmation flow, and explains that the first call deletes nothing while the second call must include confirm_code. It also names undo as the recovery path but clarifies its limitations.

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