Skip to main content
Glama
dmeiser

nextdns-mcp

by dmeiser
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Plotanalytics

plotAnalytics

Generate a PNG line chart for NextDNS analytics time-series metrics to visualize query trends over time. Requires recent query history; returns error if no data.

Instructions

Generate a PNG line chart for a NextDNS analytics time-series metric.

Use this to visualize query trends over time. The profile should have recent query history; otherwise the tool returns an error explaining that no data is available.

Supported metrics: status, devices, protocols, queryTypes, ipVersions, dnssec, encryption, reasons, ips.

Time values can be Unix timestamps or relative strings like -1d.

The ;series endpoint takes no limit parameter: limit is part of this tool's published surface, is rejected above 500 rather than clamped, and is never forwarded, so the requested range is the only thing that bounds the response. Three server-side limits are enforced before the request is built, and each is rejected with an invalid_argument error naming the limit rather than silently adjusted:

  • interval must be between 60 and 86400 seconds.

  • limit must not exceed 500.

  • The range must be interpretable (a Unix timestamp, an ISO 8601 timestamp, now, or a relative offset such as -7d; a relative unit letter is read case-sensitively and a timestamp with no timezone is read as UTC), must end after it starts, and spans at most 2000 intervals (at most 2000 points per series), so a wide range needs a proportionally larger interval.

Examples: - plotAnalytics(metric="status", profile_id="abc123", from_time="-1d") - plotAnalytics(metric="devices", profile_id="abc123", from_time="-7d", interval=86400) - a year of data: plotAnalytics(metric="status", profile_id="abc123", from_time="-1y", interval=43200)

Returns: An MCP ImageContent PNG chart, or an error dict if data is unavailable.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
metricYes
to_timeNonow
intervalNo
partialsNonone
timezoneNoGMT
alignmentNoend
from_timeNo-1d
profile_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.0.1

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses the failure mode (error when no data), the return type (ImageContent PNG or error dict), and the exact server-side enforcement behavior — limits rejected ('invalid_argument' naming the limit) rather than silently clamped, plus the 60–86400s interval and 2000-interval span caps. This is behavior an agent genuinely needs and could not infer from the schema.

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?

Purpose and metric list are front-loaded, and the bulleted limits plus concrete examples make the dense content scannable. The middle paragraph about the ';series' endpoint and the limit being 'never forwarded' is somewhat convoluted and could be tightened, but the overall structure earns its length.

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?

There is no output schema, but the description names the return form (PNG chart or error dict), and with no annotations it supplies the safety/behavioral context itself. Only the unexplained secondary parameters keep it from being fully complete for a 9-parameter tool.

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 0% across 9 parameters, so the description must compensate, and it does for several: metric values, from_time/to_time timestamp and relative-offset formats, the interval range, and the limit ceiling. However, partials, alignment, and the timezone parameter are never explained, leaving a meaningful share of the surface undocumented in either place.

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 opening states a specific verb and resource: 'Generate a PNG line chart for a NextDNS analytics time-series metric,' immediately separating it from a data-returning sibling like queryAnalytics. The follow-up 'visualize query trends over time' pins the distinct job down without ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states when to use it ('visualize query trends over time') and gives a real precondition (the profile needs recent history or it errors). It stops short of naming an alternative tool or an explicit when-not-to-use condition, so it is clear context rather than full routing guidance.

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

Deploy Server

Other Tools