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 of behavioral disclosure, yet it provides none. It does not mention that operations like remove and replace are destructive, what permissions are required, whether changes are reversible, or how the profile state is affected. The word 'manage' weakly implies mutation but adds no real transparency.

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 a single front-loaded sentence with no wasted words. Its conciseness is efficient, but the extremely sparse content leaves the definition under-specified rather than optimally focused.

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?

An output schema exists, so return values need not be explained, but this is a 6-parameter, multi-operation mutation tool with no annotations and 0% schema description coverage. The description does not come close to covering the operational and parameter complexity an agent needs to invoke it correctly.

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?

The schema has 6 parameters with 0% description coverage, and the tool description mentions none of them—not list_type, operation, profile_id, entry, entries, or entry_id. The presence of enums for list_type and operation helps the schema, but the description adds no semantic meaning beyond what is structurally encoded.

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 names a specific resource domain (allow/deny/block lists for a NextDNS profile) and implicitly distinguishes itself from siblings like manageProfiles and manageSettings. However, the verb 'manage' is broad and does not specify the supported operations (get/add/replace/update/remove) defined in the schema. An agent knows the general area but not the tool's actual capabilities.

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?

There is no guidance on when to use this tool versus alternatives such as manageRewrites or manageSettings, nor any prerequisites or exclusions. The description only states the domain, leaving the agent to infer usage context entirely.

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, and it does not disclose that 'clear' is destructive and irreversible or that 'download' returns a file payload. Auth requirements, rate limits, and whether log clearing can be undone are entirely absent, leaving a mutation-capable tool opaque.

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 short sentence is efficient in word count but is under-specified rather than concise; it leaves the only real information (the three operations and their differing behavior) unstated. Being terse is not a virtue here because there is essentially nothing front-loaded beyond the resource name.

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?

An output schema exists so return values needn't be explained, but for an 8-parameter tool with a destructive 'clear' operation and zero annotations, the description is far too thin. It should at minimum explain the operation modes and warn about irreversible log clearing.

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 8 parameters, and the description supplies no parameter meaning whatsoever. Nothing explains how 'operation' gates the relevance of raw/user/device/limit/from_time/to_time, so the agent must guess at filter semantics and time format (string vs integer).

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 names the resource (query logs) and the scope (a NextDNS profile), but the verb 'manage' is vague and hides that the tool actually performs three distinct operations (get, clear, download) declared only in the enum. It gives partial differentiation from analytics siblings by naming 'query logs', but an agent cannot tell from the text what capability it actually exposes.

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?

There is no statement of when to use this tool versus siblings like queryAnalytics or plotAnalytics, and no prerequisites. The only usage signal is implicit in the tool name, leaving the agent to infer that this is for raw log retrieval/clearing rather than aggregated analytics.

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, and it discloses almost no behavior. It does not mention that the delete operation is destructive and irreversible, what permissions are required, or that cursor implies pagination for list. The profile-domain explanation is context, not behavioral disclosure.

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?

Three short sentences, front-loaded with the purpose and followed by domain context and the cross-tool dependency note. Nothing is padded, though the brevity comes at the cost of substance.

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?

An output schema exists, so return values needn't be explained, but for a multi-operation CRUD tool with no annotations and zero schema coverage the description is far too thin. It omits operation-specific requirements (name for create, profile_id for get/update/delete) and any warning about the destructive delete path.

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 four parameters, and the description only obliquely explains profile_id. The operation enum's five values, the name parameter, and the cursor parameter are entirely undocumented in both schema and description, leaving the agent to guess which parameters apply to which operation.

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 resource is named specifically (NextDNS profiles) and the description explains what a profile is, which is genuinely helpful. But the verb is the generic 'manage' and the fact that this tool multiplexes five distinct operations (list/create/get/update/delete) is never surfaced, so an agent cannot tell what it actually does beyond 'profile things'.

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 line 'Most other tools require a profile_id from this tool' is a real workflow hint that implies list/get should come first to obtain an ID. Beyond that there is no guidance on which operation to pick, when not to use it, or how it relates to manageSettings/manageLists which presumably operate on the same profiles.

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 exist, so the description carries the full behavioral burden. It explains the effect of a rewrite (custom answer, 0.0.0.0 blocking), which is useful domain context, but says nothing about whether deletes are irreversible, whether add fails on duplicates, whether changes require confirmation, or rate limits.

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 purpose in the first sentence, followed by a short explanatory block. The bullets are slightly redundant with the first sentence but still short and readable; nothing is bloated.

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?

An output schema exists so return values need no explanation, but this is a multi-operation read/write tool with no annotations and zero parameter documentation. The per-operation contract (required fields for add vs delete vs list) is essential information an agent needs to invoke it correctly and 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% across five parameters, so the description must compensate and it largely does not. The uses hint at a hostname/answer pairing (implying name and content) and entry_id for targeting, but the crucial mapping of which parameters are required for which of the list/add/delete operations is left entirely undocumented.

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 and resource: 'Manage DNS rewrite entries for a NextDNS profile.' The resource (rewrites) is clearly distinct from the sibling tools (lists, profiles, settings, logs, analytics), so an agent can route correctly 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 bullets describe what rewrites are used for ('point a hostname to a private IP', 'block a domain'), not when to call this tool instead of manageLists or manageSettings. There is no guidance on which operation to pick or under what conditions to add versus delete.

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 does not disclose that the tool can mutate settings, whether updates replace or merge existing values, permission requirements, or the risk of changing profile behavior; "manage" obscures the read-versus-write distinction.

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 a single front-loaded sentence with no filler, but it is so terse that concision costs clarity. The structure is fine; the content is insufficient.

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 four-parameter mutation-capable tool with no annotations and 0% schema description coverage, the description is inadequate. It leaves critical gaps around get versus update behavior, required settings for updates, and the category enum, even though an output schema exists to cover return values.

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 should compensate but adds no meaning for any parameter. It does not explain the category enum values, the operation enum's get/update semantics, how profile_id is used, or what shape the settings argument expects.

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 gives a verb and resource ("Manage a settings category for a NextDNS profile"), so an agent can tell it is about profile settings rather than lists or rewrites. However, "manage" is vague and does not clarify that the tool supports both reading and updating settings, nor how it differs from siblings beyond the resource name.

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?

There is no guidance on when to use this tool versus siblings, nor on when to choose get versus update. The only implied usage is that the target is a settings category on a NextDNS profile.

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 so well: it discloses that limit is rejected above 500 rather than clamped, that no value is forwarded to the ;series endpoint, that interval is bounded 60–86400, that ranges over 2000 intervals are rejected, and that violations raise invalid_argument errors naming the limit. It also documents time-parsing rules (relative offsets, case-sensitive unit letters, UTC default for zoneless timestamps) and the no-data error path.

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 bulleted limit list is well front-loaded and scannable, but the preceding paragraph on the ';series' endpoint and 'published surface' is convoluted and repeats the limit-500 rule that the bullets state again. Implementation rationale crowds out parameter meaning.

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 no annotations and no output schema, the description covers error behavior and range limits thoroughly but leaves four parameters (profile_id, partials, alignment, timezone) unexplained. An agent could call it, but only by guessing on those fields.

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 covers metric values, limit, interval bounds, and from/to time formats, but never explains profile_id, partials, alignment, or the timezone parameter's effect. Roughly half the surface remains 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?

States a specific verb and resource plus the output format: 'Generate a PNG line chart for a NextDNS analytics time-series metric.' An agent immediately knows this is a visualization tool, not a raw-data tool. However, it never explicitly contrasts itself with the closely named sibling queryAnalytics, so differentiation is left to inference.

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?

Offers 'Use this to visualize query trends over time' and a precondition that the profile must have recent query history or an error is returned. That is useful context, but there is no guidance on when to prefer queryAnalytics over this charting tool, nor when profile_id should be supplied versus omitted.

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 and discloses nothing: not pagination behavior despite cursor/limit parameters, not default time windows, not rate limits, not whether results are aggregated or raw. For a 15-parameter read tool with zero annotation coverage this is a serious gap.

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?

It is a single short sentence with no padding, but at this level of complexity brevity is under-specification rather than conciseness. Nothing is front-loaded beyond the bare verb and resource.

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?

Although an output schema exists and need not be described, the input side is completely undocumented: 15 parameters, an 11-value metric enum, and no annotations. An agent cannot determine valid filter combinations, time-range semantics, or pagination from this description.

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 15 parameters, and the description adds no parameter meaning at all. Ambiguous fields such as metric, series, partials, alignment, interval, destination_type, and the from_time/to_time dual string-or-integer types are left entirely unexplained.

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 names a specific verb ('Query') and resource ('NextDNS analytics metrics'), so the general purpose is graspable. It does not distinguish itself from the sibling plotAnalytics, which also operates on analytics data, leaving the boundary between 'query' and 'plot' to inference.

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?

There is no guidance on when to use this versus plotAnalytics, no prerequisites (e.g. needing a profile_id), and no mention of what to do when no time range is supplied. The single sentence implies only that it is for analytics retrieval.

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