NextDNS-Agent-MCP

profile_settings

Idempotent

Update a NextDNS profile's general settings—name, query logs, block page, performance, Web3—while changing only supplied fields and allowing undo.

Instructions

Change a profile's general settings: its name, query logs (on or off, how long, where, what to leave out), the block page, performance (ECS, cache boost, CNAME flattening) and Web3 domains. Use profile(section='settings') to see them first; protections are in security, privacy and parental_control. Changes only the inputs given and records it, so undo can put it back; an unknown retention or location is refused. Returns the settings after the change, or says nothing changed.

Input Schema

TableJSON Schema

Name	Required	Description
`ecs`	No	true or false: send EDNS Client Subnet, for faster CDNs. Leave empty to keep it as it is.
`logs`	No	true or false: keep a query log. Leave empty to keep it as it is.
`web3`	No	true or false: resolve Web3 domains like .eth. Leave empty to keep it as it is.
`rename`	No	A new name for the profile.
`profile`	No	The profile's ID or name. Leave empty for the only profile, or the default one.
`block_page`	No	true or false: show a block page instead of failing. Leave empty to keep it as it is.
`cache_boost`	No	true or false: keep answers cached longer. Leave empty to keep it as it is.
`drop_domains`	No	true or false: leave domains out of the logs. Leave empty to keep it as it is.
`log_location`	No	Where logs are stored: us, eu, gb or ch.
`log_retention`	No	How long logs are kept: 1 hour, 6 hours, 1 day, 1 week, 1 month, 3 months, 6 months, 1 year or 2 years.
`drop_client_ips`	No	true or false: leave client IP addresses out of the logs. Leave empty to keep it as it is.
`cname_flattening`	No	true or false: answer with the final address. Leave empty to keep it as it is.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedOct 21, 2026

addedInput schema / properties / block_page / description

Added value: +"true or false: show a block page instead of failing. Leave empty to keep it as it is."

addedInput schema / properties / cache_boost / description

Added value: +"true or false: keep answers cached longer. Leave empty to keep it as it is."

addedInput schema / properties / cname_flattening / description

Added value: +"true or false: answer with the final address. Leave empty to keep it as it is."

addedInput schema / properties / drop_client_ips / description

Added value: +"true or false: leave client IP addresses out of the logs. Leave empty to keep it as it is."

addedInput schema / properties / drop_domains / description

Added value: +"true or false: leave domains out of the logs. Leave empty to keep it as it is."

addedInput schema / properties / ecs / description

Added value: +"true or false: send EDNS Client Subnet, for faster CDNs. Leave empty to keep it as it is."

addedInput schema / properties / log_location / description

Added value: +"Where logs are stored: us, eu, gb or ch."

addedInput schema / properties / log_retention / description

Added value: +"How long logs are kept: 1 hour, 6 hours, 1 day, 1 week, 1 month, 3 months, 6 months, 1 year or 2 years."

addedInput schema / properties / logs / description

Added value: +"true or false: keep a query log. Leave empty to keep it as it is."

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 / rename / description
```
Added value: +"A new name for the profile."
```

addedInput schema / properties / web3 / description

Added value: +"true or false: resolve Web3 domains like .eth. Leave empty to keep it as it is."

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?

Adds substantial context beyond the annotations: partial-update semantics ('Changes only the inputs given'), recording for undo, refusal of unknown retention/location values, and the return contract (settings after change, or a no-op message). Annotations already cover idempotency and non-destructiveness, so the description is not carrying the full safety burden, but the mutation semantics it adds are valuable.

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?

Dense and front-loaded: purpose first, then prerequisites, then exclusions and behavior. Twelve parameters are covered in three sentences with little filler, though the parenthetical expansion of settings is slightly list-heavy and 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?

For a 12-parameter idempotent mutation with no required fields, the description covers purpose, prerequisites, alternatives, partial-update behavior, validation refusals, and return values — and an output schema exists so return-format detail is unnecessary. 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 baseline is 3, but the description adds meaning the schema lacks: the log-related params are framed as a coherent group (on/off, how long, where, what to leave out), and it discloses that an unknown retention or location value is refused — a validation constraint not expressible via the enum-free string schemas.

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?

Opens with a specific verb+resource ('Change a profile's general settings') and enumerates the exact setting families covered (name, query logs, block page, performance/ECS/cache boost/CNAME flattening, Web3). It also explicitly excludes the sibling domains ('protections are in security, privacy and parental_control'), so an agent can route without opening 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 an explicit precondition ('Use profile(section='settings') to see them first') and names the alternative tools for adjacent functionality (security, privacy, parental_control). The when-to-use versus when-to-use-elsewhere split is fully spelled out.

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