NextDNS-Agent-MCP

analytics

Read-only

Count a NextDNS profile's DNS queries over a chosen time span and retrieve paginated reports for status, top domains, block reasons, devices, IPs, or protocols. Changes nothing.

Instructions

Count a profile's DNS queries over a time span, one report at a time: allowed or blocked, top domains, block reasons, devices, IPs, protocols and more. Use chart for the same numbers as a picture, logs for single queries and watch_logs for queries happening now. Changes nothing. Returns one line per row with its count (counts over time with series), and a cursor line when there are more rows.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`root`	No	domains report only: true groups subdomains under their root domain.
`limit`	No	How many rows, 1 to 500.
`cursor`	No	The cursor from the last answer, to get the next page.
`device`	No	Only this device: a device ID from the devices report, or __UNIDENTIFIED__.
`report`	No	Which report: status, domains, reasons, ips, devices, protocols, queryTypes, ipVersions, dnssec, encryption or destinations.	status
`series`	No	true: counts over time, split by interval and timezone.
`status`	No	domains report only: just blocked, allowed or default queries.
`profile`	No	The profile's ID or name. Leave empty for the only profile, or the default one.
`to_date`	No	Where to stop, not included: an ISO date, Unix time or relative like -1h. Empty means now.
`interval`	No	With series: the step between points, like 1h, 1d or 3600 (seconds).
`timezone`	No	With series: the time zone for the steps, like Europe/Lisbon.
`from_date`	No	Where to start, included: an ISO date, Unix time or relative like -6h, -7d or -1M.	-7d
`destination`	No	destinations report only: countries or gafam.	countries

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed13 schema fields changedOct 21, 2026

addedInput schema / properties / cursor / description

Added value: +"The cursor from the last answer, to get the next page."

addedInput schema / properties / destination / description

Added value: +"destinations report only: countries or gafam."

addedInput schema / properties / device / description

Added value: +"Only this device: a device ID from the devices report, or __UNIDENTIFIED__."

addedInput schema / properties / from_date / description

Added value: +"Where to start, included: an ISO date, Unix time or relative like -6h, -7d or -1M."

addedInput schema / properties / interval / description

Added value: +"With series: the step between points, like 1h, 1d or 3600 (seconds)."

addedInput schema / properties / limit / description
```
Added value: +"How many rows, 1 to 500."
```

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 / report / description

Added value: +"Which report: status, domains, reasons, ips, devices, protocols, queryTypes, ipVersions, dnssec, encryption or destinations."

addedInput schema / properties / root / description

Added value: +"domains report only: true groups subdomains under their root domain."

addedInput schema / properties / series / description

Added value: +"true: counts over time, split by interval and timezone."

addedInput schema / properties / status / description

Added value: +"domains report only: just blocked, allowed or default queries."

addedInput schema / properties / timezone / description

Added value: +"With series: the time zone for the steps, like Europe/Lisbon."

addedInput schema / properties / to_date / description

Added value: +"Where to stop, not included: an ISO date, Unix time or relative like -1h. Empty means now."

First observedv0.8.1Oct 20, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so 'Changes nothing' largely restates structured data. The description does add genuine behavioral context beyond the annotations: one line per row with its count, series-mode behavior, and a cursor line signaling pagination. It stops short of stating auth or rate-limit behavior, so not a 5.

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?

Three tightly packed sentences that are front-loaded with the core purpose, then routing guidance, then output/pagination behavior. For a 13-parameter tool this is compact, and every sentence carries distinct information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-parameter read-only reporting tool with a full output schema and complete parameter descriptions, the description supplies the missing framing: what the reports cover, how it differs from siblings, and how results paginate. Only the redundant 'Changes nothing' keeps it from being fully tight.

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 all 13 parameters (report, series, interval, cursor, profile defaults, etc.) are already documented in the schema. The description only gestures at report contents and series mode ('counts over time with series'); it adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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 and resource ('Count a profile's DNS queries over a time span') and enumerates the concrete report dimensions (allowed/blocked, top domains, block reasons, devices, IPs, protocols). It also names the sibling tools it is not (chart, logs, watch_logs), so an agent can distinguish it 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 routes the agent: 'Use chart for the same numbers as a picture, logs for single queries and watch_logs for queries happening now.' Each alternative is paired with the condition that selects it, leaving nothing to inference.

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