NextDNS-Agent-MCP

catalog

Read-only

List NextDNS blocklists, native tracking protection, services, categories, or TLDs to find the right ID before changing a profile. Read-only; returns matches with key details.

Instructions

List what NextDNS offers to pick from (privacy blocklists, native tracking protection, parental control services and categories, or top-level domains), with the IDs that privacy, security and parental_control take. Use it to find the right ID before a change; use profile to see what a profile already has on. Changes nothing. Returns how many matched and one line per item (blocklists also with size, update date and description).

Input Schema

TableJSON Schema

Name	Required	Description
`kind`	Yes	What to list: blocklists, natives (native tracking protection), services (apps parental control can block), categories or tlds.
`limit`	No	How many to show, 1 to 2000.
`search`	No	Words to look for in the IDs, names and descriptions.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.8.3Oct 21, 2026
- changedInput schema / properties / limit / description
```
Previous value: -"How many to show."New value: +"How many to show, 1 to 2000."
```

Changed3 schema fields changedOct 21, 2026

addedInput schema / properties / kind / description

Added value: +"What to list: blocklists, natives (native tracking protection), services (apps parental control can block), categories or tlds."

addedInput schema / properties / limit / description
```
Added value: +"How many to show."
```

addedInput schema / properties / search / description

Added value: +"Words to look for in the IDs, names and descriptions."

First observedv0.8.1Oct 20, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so "Changes nothing" is largely redundant. However, the description adds return-shape context (count of matches, one line per item, extra fields for blocklists), which annotations and schema do not convey in prose.

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?

Content is front-loaded with the what, then the when, then the return shape. Slightly dense with parentheticals and a run-on final clause, but every sentence carries distinct 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?

For a read-only lookup tool with a full output schema, the description covers purpose, usage routing, side-effect-free behavior, and output shape. Nothing an agent needs to invoke it correctly 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, but the description adds genuine meaning: it explains that the returned IDs are the values privacy, security and parental_control accept, clarifying the parameter's downstream role beyond the schema's kind enumeration.

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 (list) and resource (catalog of NextDNS offerings), enumerating the kinds available (blocklists, natives, services, categories, tlds). It goes further by explaining the purpose of the IDs returned, which distinguishes it from lookup siblings like profile.

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?

"Use it to find the right ID before a change; use profile to see what a profile already has on" gives explicit when-to-use plus an alternative sibling with the condition that selects it. The routing decision is unambiguous.

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