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

No annotations are provided, so the description carries the full behavioral burden. 'Lookup' implies a non-mutating read, which is useful, but nothing is said about authentication requirements, rate limits, whether the profile must pre-exist, or how the default-profile fallback behaves at runtime.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with no waste. It is efficient, though the brevity edges toward under-specification rather than optimal conciseness.

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

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

The output schema exists, so return-value explanation is not required, and the three parameters are fully covered by the schema. However, with no annotations and no usage or behavioral context, the definition is only minimally sufficient for an agent to invoke this confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents domain, profile_id (including the NEXTDNS_DEFAULT_PROFILE fallback), and record_type. The description adds no parameter meaning beyond what the schema provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (lookup) and resource (DNS-over-HTTPS via a NextDNS profile), which an agent can distinguish from the manage*/analytics siblings. It stops short of saying anything that would differentiate it from a hypothetical non-DoH DNS lookup, but the purpose is unambiguous.

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

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

The description gives no indication of when to use this tool versus the sibling tools (queryAnalytics, manageLogs) or when a DoH lookup is the right approach. There are no prerequisites or exclusion conditions stated.

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

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

With no annotations, the description carries the full burden and does well: it discloses that 'replace' overwrites the entire list (destructive), that 'remove' deletes one entry by entry_id, and that 'update' only toggles entries for a subset of list types. It omits auth/permission requirements and failure behavior, which keeps it below 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Content is well front-loaded with purpose, then list types, then operations, then examples. It is longer than typical, but the length is justified by 0% schema coverage and the examples are load-bearing; a small amount of redundancy exists between the operation prose and the examples.

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

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

For a complex six-parameter, five-operation tool with an output schema already present, the description covers list taxonomy, per-operation argument shapes, and the update-support restriction. 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does: it defines entry (id dict or plain string), entries (list of dicts for replace), entry_id (delete target), and the semantics of every operation enum. The four worked examples pin down exact argument shapes that the bare schema leaves ambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb and resource ('Manage allow/deny/block lists for a NextDNS profile') and the enumerated list types make the domain unmistakable versus siblings like manageRewrites or manageSettings. An agent can identify the tool's scope without opening the schema.

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

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

The Operations section maps each operation to its semantics and even states the condition where 'update' is invalid (only allowlist/denylist/parental_categories/parental_services), which is real when-to-use guidance. It does not, however, name alternative tools or state when not to use this tool at all.

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

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

With no annotations, the description carries the full burden and mostly meets it: it warns that clear deletes all stored logs, that download ignores time filters, and that raw bypasses dedup/noise filtering. It omits any permission/auth requirements and return-volume or pagination behavior for get.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the one-line purpose, then operations, then time semantics, then examples. Well-structured with no filler, though the four copy-paste examples are somewhat repetitive with the operation bullets above them.

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

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

For a multi-operation tool with an output schema present, the description covers operation semantics, filter interactions, and time formats adequately. The remaining gap is the unexplained user/device filters, which an agent would have to guess at.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains operation, limit, raw, from_time and to_time meaningfully, but the user and device parameters are never mentioned, leaving two of eight parameters undocumented in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first line states the resource (query logs for a NextDNS profile) and the operation set (get/clear/download) is enumerated immediately after. 'Manage' alone is vague, but the bulleted operations make the tool's scope unambiguous and separable from siblings like queryAnalytics or manageProfiles.

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

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

Each operation's purpose is spelled out, and the description explicitly says from_time/to_time are ignored by the download endpoint and only used by get, which prevents a common misuse. It stops short of saying when to prefer this over queryAnalytics for log retrieval, so no exclusions or named alternatives.

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

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

With no annotations provided, the description carries the full behavioral burden but barely addresses it. It implies mutation for create/update/delete but never states that delete is destructive or irreversible, whether cascading effects occur, or what permissions/API-key scope is required beyond an incidental mention of 'the API key can access'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is front-loaded with the resource overview, then a clean operation list, then examples. The examples are somewhat redundant with the operation list but do earn their place by showing parameter placement, so length is justified.

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

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

Given an output schema exists, return values need not be explained, and the per-operation parameter requirements are covered. The main gap is behavioral disclosure around the destructive delete operation, which the absent annotations leave unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it largely does: it maps each operation to its required inputs (name for create/update, profile_id for get/update/delete) and shows them in examples. Only the exact format/constraints of profile_id and name are left unspecified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource (NextDNS profiles) with a concrete verb (manage) and immediately enumerates the exact operations available (list, create, get, update, delete). It also distinguishes itself from siblings by noting other tools require a profile_id from this one, so an agent can place it in the workflow.

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

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

Each operation is scoped with its required parameters and concrete invocation examples, and the note that 'most other tools require a profile_id from this tool' gives real when-to-use context. However, there is no guidance on when NOT to use it or on alternatives for profile-like operations, so it falls short of explicit exclusions.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that delete consumes an entry_id obtained from list and that add requires name+content, but says nothing about whether delete/add are irreversible, what permissions the profile requires, or rate-limit behavior — a real gap for a mutating tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with a one-line purpose followed by scannable operation and example blocks; each line earns its place. The examples are somewhat repetitive of the operation list, which keeps it short of a 5.

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

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

With an output schema present, return values need no explanation, and the description covers purpose, operations, parameter roles, and concrete calls. It is nearly complete for a 5-param multi-operation tool, missing only mutability/safety context that no annotations supply.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it largely does: it defines the enum values of operation, the meaning of name/content, and the provenance of entry_id ('from list'). profile_id is only shown by example rather than explained, leaving a small residual gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Manage DNS rewrite entries for a NextDNS profile') and explains what a rewrite actually is, so an agent can distinguish it from manageProfiles, manageSettings, and the other siblings without opening the schema.

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

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

Enumerates the three operations and states the required fields for each ('add' needs name+content, 'delete' needs entry_id from list), which is clear routing context. It does not say when to prefer this tool over a sibling or when not to use it, so it stops short of full when/when-not guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses that update requires a settings payload, that settings can be a dict or JSON string, and that you should retrieve first to see the schema. It doesn't describe permissions, reversibility, or rate limits, but for a settings-management tool, the get-before-update guidance and payload format are substantial behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear purpose statement, a bulleted category list, a bulleted operation list, and concrete examples. Every sentence earns its place; the formatting makes it easy to scan for the relevant category or operation.

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

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

Given the complexity (4 parameters, 2 enums, no annotations, but an output schema exists), the description is complete enough. It covers all categories, both operations, the settings payload format, and the recommended workflow. The output schema handles return values, so the description doesn't need to explain them.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does: it enumerates all category values with meanings, lists the two operations with their effects, explains the settings argument format (dict or JSON string), and provides examples showing exact parameter usage. This fully compensates for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource: managing a settings category within a NextDNS profile. It enumerates all categories and operations, so the agent understands the exact scope. It doesn't explicitly distinguish from siblings like manageProfiles or manageLogs, though the category list implicitly covers some overlap.

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

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

The description gives clear when-to-use guidance: 'first call get to see the current schema, then send only the fields you want to change.' It explains the get-then-update workflow, which is a strong usage guideline. It doesn't state when not to use this tool or name alternatives, but the workflow guidance is explicit.

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

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

With no annotations present the description carries the full burden, and it does disclose the failure mode (error when no data is available) and the return shape (MCP ImageContent PNG or an error dict). It omits read-only/safety framing and any auth or rate-limit notes, which holds it below 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well front-loaded: purpose, usage, metrics, time format, then two worked examples. The metric list and example block are useful rather than filler, though the Returns section partly duplicates what the opening sentence already implies.

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

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

For a 9-parameter tool with zero schema description coverage and no output schema, the description covers purpose, return type, and two of the trickier parameters, but leaves five parameters unexplained, which is a meaningful gap for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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. It usefully documents the metric values and that time inputs accept Unix timestamps or relative strings like '-1d', but limit, interval, partials, timezone, and alignment remain undocumented anywhere.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource: 'Generate a PNG line chart for a NextDNS analytics time-series metric.' It is clearly a visualization tool, implicitly distinct from the sibling queryAnalytics, but it never names or contrasts with that sibling explicitly, so an agent must infer the boundary.

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

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

States when to use it ('visualize query trends over time') and gives a concrete precondition that failure depends on ('the profile should have recent query history; otherwise the tool returns an error'). It does not name alternatives such as queryAnalytics for raw data, so selection guidance is incomplete but clear.

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

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

No annotations are provided, so the description carries full burden. It discloses key behavioral constraints: series=true is unsupported for metric=domains, destinations requires destination_type, time values accept Unix timestamps or relative strings like '-1d'. These are useful non-obvious behaviors. However, it doesn't disclose rate limits, auth requirements, or the response shape.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose, then structured sections (Metrics, Optional filters, Examples). The examples section adds real value. Some verbosity in per-metric explanations, but the structure makes it scannable.

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

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

Has an output schema so return value explanation isn't needed. For a 15-parameter tool, the description covers the semantic meaning of metric values and the important conditional constraints. Missing explanations for several parameters (interval, alignment, partials, timezone) is a gap, but overall adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains meaning for many parameters: metric (with full enumeration of 11 values and their semantics), series, cursor, device, status (scoped to domains metric), root (scoped to domains metric), destination_type. Several parameters remain unexplained (limit, to_time, from_time, interval, partials, timezone, alignment) but the ones that matter most for correct invocation are covered.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (query) and resource (NextDNS analytics metrics), and clearly enumerates the available metrics. Doesn't differentiate from the sibling plotAnalytics, but the metric enumeration and emphasis on aggregate totals vs time-series gives an agent a clear sense of what this tool does.

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

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

Explains usage context implicitly: series=true for time-series, cursor for pagination, device for filtering. However, it never explains when to use this versus plotAnalytics, which appears to be the natural alternative for visual analysis. No explicit when-not guidance.

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