NextDNS-Agent-MCP

security

Idempotent

Toggle NextDNS profile protections (threat feeds, AI threat detection, Safe Browsing, cryptojacking, typosquatting, NRD) and block/unblock top-level domains. Changes are saved and reversible.

Instructions

Turn a profile's security protections on or off (threat feeds, AI threat detection, Google Safe Browsing, cryptojacking, typosquatting, newly registered domains and more) and block or unblock whole top-level domains. profile(section='security') shows the switches with their keys and catalog(kind='tlds') the TLD IDs; use privacy for blocklists and list_entries for single domains. Changes the profile and records it, so undo can put it back; unknown keys or TLDs are refused, and ones already set are skipped. Returns what changed and the change ID.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

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

Input Schema

Name	Required	Description
`profile`	No	The profile's ID or name. Leave empty for the only profile, or the default one.
`turn_on`	No	Protection keys to switch on, like threatIntelligenceFeeds, aiThreatDetection, googleSafeBrowsing, cryptojacking, typosquatting or nrd. profile with section security lists them all.
`turn_off`	No	Protection keys to switch off, same names as turn_on.
`block_tlds`	No	Top-level domains to block entirely, like zip or xyz (from catalog, kind tlds).
`unblock_tlds`	No	Top-level domains to stop blocking.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 21, 2026

addedInput schema / properties / block_tlds / description

Added value: +"Top-level domains to block entirely, like zip or xyz (from catalog, kind tlds)."

addedInput schema / properties / profile / description

Added value: +"The profile's ID or name. Leave empty for the only profile, or the default one."

addedInput schema / properties / turn_off / description

Added value: +"Protection keys to switch off, same names as turn_on."

addedInput schema / properties / turn_on / description

Added value: +"Protection keys to switch on, like threatIntelligenceFeeds, aiThreatDetection, googleSafeBrowsing, cryptojacking, typosquatting or nrd. profile with section security lists them all."

addedInput schema / properties / unblock_tlds / description
```
Added value: +"Top-level domains to stop blocking."
```

First observedv0.8.1Oct 20, 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 (not read-only, not destructive, idempotent, closed-world), and the description adds real context on top: changes are recorded and reversible via undo, unknown keys/TLDs are refused, already-set values are skipped, and the response reports what changed plus a change ID. This is exactly the behavioral detail structured fields don't carry.

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 action, then discovery pointers, then mutation semantics and return shape. Dense but every clause carries information; the only mild redundancy is restating the key/TLD discovery hints already present in the schema.

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 multi-mode mutation tool with five optional parameters, the description covers what it changes, how to find valid inputs, which sibling tools to use instead, error/skip behavior, reversibility, and the return payload (with an output schema also present). An agent has everything needed to invoke it 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%, so each of the five parameters is already documented with examples (threatIntelligenceFeeds, googleSafeBrowsing, zip/xyz, etc.). The description largely echoes the schema's pointers to profile(section='security') and catalog(kind='tlds') rather than adding syntax or constraints beyond them, so the baseline 3 is appropriate.

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 concrete verb+resource pair: toggling a profile's security protections on/off and blocking/unblocking TLDs. It also distinguishes itself from siblings by name ('use privacy for blocklists and list_entries for single domains'), so an agent can route correctly without opening other schemas.

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?

Gives explicit prerequisites and alternatives: profile(section='security') to discover protection keys, catalog(kind='tlds') for valid TLD IDs, and privacy/list_entries for the adjacent but different operations. Nothing about when to choose this tool is left to inference.

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