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

With no annotations, the description carries the full burden of disclosing side effects. It does reveal that the zone is created automatically for Primary type, which is a useful behavioral trait. However, it omits other important behaviors, such as the overwrite parameter's effect, what happens when a zone doesn't exist for non-Primary types, or any permissions 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?

The description is extremely concise, using two short sentences to convey the core purpose and a key side effect. Every sentence earns its place, with the front-loaded action verb making the tool's function immediately clear.

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?

Despite having 7 parameters and no output schema or annotations, the description remains minimal. It fails to cover essential contextual details like return values, overwrite behavior, or handling of non-Primary zones without existing zones. For a tool with this complexity, more context is needed to guide 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 100%, with each parameter having a description. The description itself adds no additional parameter-level meaning beyond the schema, 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?

The description clearly states the action ('Add a DNS record to a zone') with a specific verb and resource, and adds a distinguishing behavioral note about automatic zone creation for Primary type. This effectively differentiates it from sibling tools like dns_update_record and dns_delete_record.

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 implies usage for adding DNS records, but provides no explicit guidance on when to use this tool versus alternatives like dns_update_record or when not to use it. The note about 'Primary type' hints at a condition but doesn't clarify behavior for non-Primary zones or recommend alternative tools.

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 behavioral burden. It discloses the core effect (bypasses block lists) and implies whitelisting, but does not state reversibility, side effects, or permission requirements. This is a modest but incomplete 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?

Two concise sentences, front-loaded with the action. No unnecessary words or repetition.

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 single-parameter tool with no output schema, the description adequately covers what it does and when to use it. However, it could mention related operations (e.g., removal via dns_remove_allowed) for fuller context. Still, given the simplicity, it is largely complete.

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 already provides full coverage (100%) for the single parameter with an example ('e.g. plex.direct'). The description adds no additional parameter-specific meaning, 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?

The description clearly states the verb 'Allow' and resource 'domain name', and specifies the effect 'bypassing any block lists'. This distinguishes it from siblings like dns_block_domain and dns_remove_allowed.

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?

Provides clear usage context: 'Useful for whitelisting false positives.' This indicates when to use the tool, but it does not explicitly mention alternatives or when not to use it, so it does not reach a 5.

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 must disclose behavior. It states the effect (queries denied) but does not mention reversibility, permissions, idempotency, or side effects. It provides basic transparency but leaves gaps.

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?

Two sentences, no filler, front-loaded with the action. Every word earns its place.

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 simple one-parameter tool with no output schema, the description covers the main action and effect. It lacks detail on return values or edge cases, but given the low complexity, it's largely sufficient.

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 already provides a full description for the only parameter ('Domain name to block'), so the description adds little beyond that. Baseline 3 is appropriate.

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 uses a specific verb 'Block' and resource 'domain name', and clarifies the consequence ('Queries to this domain will be denied'), which clearly distinguishes it from sibling tools like dns_allow_domain or dns_remove_blocked.

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 implies when to use the tool (to block a domain) but does not explicitly mention alternatives or exclusions. It lacks guidance on when not to use it or how it differs from related tools like dns_allow_domain.

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. The verb 'Check' implies a read-only operation, but the description does not explicitly confirm that no changes are made, nor does it mention network dependencies or what the response will look like.

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 unnecessary words. It conveys all essential information about the tool's purpose without any filler.

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 simple no-parameter tool, the description states the core function, but it lacks an output schema, so it doesn't explain what the agent can expect as a result (e.g., a boolean, a version string, or an error). This leaves some ambiguity about how to interpret the outcome.

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 tool has zero parameters and an empty input schema, so there is nothing for the description to add. With zero params, the baseline is 4, which is appropriate here since the schema already fully covers the absence of parameters.

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 clearly states the tool's function: checking for a newer version of Technitium DNS Server. The verb 'Check' and the resource 'newer version' are specific, and it is distinct from sibling tools that manage zones, records, or settings.

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 a clear purpose but does not explicitly state when to use this tool versus alternatives. Since there is no direct sibling tool for update checking, the usage is implied but not elaborated with context such as 'before upgrading' or 'periodically.'

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 present, so the description must carry the full behavioral disclosure burden. It only hints at parameter behavior ('Primary' vs 'Forwarder') and omits side effects, prerequisites, duplicate handling, or confirmation of what 'create' entails. The mutation is implied but not disclosed further.

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?

Two sentences, front-loaded with the core action. The first sentence states the purpose; the second adds critical usage nuance. No filler or repetition.

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 simple create operation with two parameters and no output schema, the description plus schema is nearly sufficient. It explains the main action and clarifies the most important type choice. It could improve by mentioning behavior on duplicate zones or expected response, but overall it covers the essentials for a straightforward tool.

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 descriptions cover both parameters (zone, type) at 100%, so baseline is 3. The description adds value by explaining the intended use of two enum values ('Primary' for local hosting, 'Forwarder' for conditional forwarding), which is beyond the schema's generic 'Zone type' description. It doesn't cover Secondary and Stub, but the additional context is meaningful.

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 opens with 'Create a new DNS zone,' a clear, specific verb+resource statement. It distinguishes this creation tool from sibling tools like dns_list_zones, dns_delete_zone, and dns_set_zone_options by focusing solely on the act of creating.

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 provides explicit guidance on choosing zone types, advising 'Primary' for local record hosting and 'Forwarder' for conditional forwarding. It does not mention when not to use the tool or name alternatives, but for a creation operation the context is 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 the full burden. It discloses that the action is targeted (removes only the specified domain) and not a full flush, which adds valuable context. However, it does not mention potential side effects (e.g., whether the cache repopulates, error behavior for nonexistent domains) or authorization requirements. For a simple delete operation this is acceptable but not fully transparent.

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 sentence that is both concise and information-dense. It states the core purpose and the key differentiator without any redundant words. The structure is front-loaded with the action.

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 tool's simplicity (one parameter, no output schema), the description is mostly complete. It covers the operation and the distinction from flush. However, it could briefly mention what happens when the domain isn't cached or confirm that the action is immediate, which would improve completeness. Still, it's a well-specified tool relative to its complexity.

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 input schema has 100% description coverage for the single 'domain' parameter, fully documenting its type and example. The description adds no extra parameter semantics beyond what the schema already provides, so the baseline score 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?

The description clearly states the action: 'Delete a specific domain from the DNS cache' with a specific verb and resource. It also distinguishes itself from a sibling tool by explicitly referencing 'flush' and noting that it only removes the specified domain, which differentiates it from dns_flush_cache.

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 implies when to use this tool by contrasting it with flush: use this for a single domain removal rather than clearing the entire cache. It clearly names the alternative (flush) and the distinguishing condition, though it doesn't provide explicit 'when not to use' beyond that.

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 burden of disclosing behavioral traits. It notes the confirm=true gate, which implies a safety mechanism and that deletion will not occur without it. However, it does not explicitly mention irreversibility or potential impacts of deleting the record, leaving room for more 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 one concise, front-loaded sentence covering the essential action and key requirement. No wasted words.

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 description is minimal but sufficient for a delete operation: it states the action and the critical confirm parameter. However, with no annotations and no output schema, it does not elaborate on preconditions or consequences of deletion, making it only minimally complete.

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 covers 100% of parameter descriptions, including the confirm parameter's behavior. The description adds emphasis on confirm=true but does not provide additional meaning beyond the schema. Baseline 3 is appropriate.

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 clearly states 'Delete a specific DNS record from a zone' with a specific verb and resource. It distinguishes itself from sibling tools like dns_delete_zone or dns_update_record by specifying a single record deletion. The addition of the confirm requirement further clarifies the operation.

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 mentions the confirm=true requirement but does not explicitly explain when to use this tool versus alternatives like dns_update_record or dns_add_record. The intended use is implied by the name and description but lacks explicit 'when not to use' 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?

With no annotations provided, the description carries the full burden. It discloses the destructive nature ('all its records'), the confirm=true requirement, and the safe behavior without confirmation. This is strong disclosure, though it leaves out irreversibility and permission requirements.

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 sentence of 13 words, efficiently packing both purpose and the guard condition. No filler or repetition.

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 simple two-parameter tool with no output schema, the description covers purpose, scope, and safety guard. An explicit note about irreversibility would make it fully complete, but the current level is 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 coverage is 100%, so baseline is 3. The description adds meaning to the zone parameter by clarifying that deleting the zone also deletes all records, which is not stated in the schema's parameter description. The confirm behavior is already fully described in the schema, so no extra credit there.

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 uses a specific verb 'Delete' with resource 'DNS zone' and explicitly states scope 'all its records', clearly distinguishing it from sibling tools like dns_delete_record and dns_disable_zone. This makes the tool's purpose 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?

It clearly implies use when permanent zone deletion is needed. However, it does not explicitly mention alternatives like dns_disable_zone for temporary disabling, so it falls short of full usage 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?

With no annotations provided, the description carries the disclosure burden. It discloses two key behavioral outcomes: the zone stops responding to queries and records are preserved. This goes beyond a simple restatement and helps the agent understand the tool's side effects. However, it does not mention reversibility (e.g., via dns_enable_zone) or any prerequisites, so it is not fully transparent.

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 two sentences with no padding. It leads with the action, then provides the critical behavioral consequence. Every word earns its place; it is appropriately sized for the tool's simplicity.

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 tool's simplicity (one parameter, no output schema, no annotations), the description covers the essential behavior: disabling the zone and preserving records. It does not explain how to re-enable it or what happens to existing queriers, but that is not strictly necessary for this operation. The description is complete enough for an agent to use the tool 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?

Schema description coverage is 100% for the single parameter 'zone', so the schema already fully documents the parameter. The description does not add any parameter-specific semantics beyond the schema, but the schema's description ('Zone domain name to disable') is sufficient, resulting in a baseline score of 3.

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 uses a specific verb ('Disable') and resource ('DNS zone'), and clearly distinguishes the action from related siblings like dns_delete_zone and dns_enable_zone by noting that records are preserved. The statement 'The zone will stop responding to queries but its records are preserved' adds scope and makes the purpose unmistakable.

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 implies a usage context: use this when you want to take a zone offline but retain its records. However, it does not explicitly compare against alternatives such as dns_delete_zone or dns_enable_zone, nor does it state when to prefer this over those. The implied usage is clear but no explicit guidance or exclusions are given.

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 burden of behavioral disclosure. It only says 'Get', implying a read-only operation, but does not mention response format, error behavior, permissions, or whether the zone is modified. This is a significant gap for a tool without annotations.

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 sentence, front-loaded with 'Get DNSSEC properties', and lists key result categories without unnecessary elaboration. Every word earns its place.

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 tool's low complexity (one parameter, no output schema), the description is reasonably complete, mentioning the returned categories (signing status, key details, algorithm info). However, it lacks details on failure modes or output structure, making it slightly incomplete for fully autonomous use.

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 input schema already fully describes the single parameter 'zone' as 'Zone domain name', and the description merely says 'for a zone' without adding syntax or formatting details. With 100% schema coverage, the baseline of 3 applies, and the description adds no extra meaning.

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 clearly states it retrieves DNSSEC properties for a zone, naming the specific details returned (signing status, key details, algorithm info). This distinguishes it from siblings like dns_get_ds, which only fetches DS records, and other zone-related tools.

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?

No guidance is given on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description only states what the tool does, leaving the agent without explicit selection cues among many DNS sibling tools.

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 of behavioral disclosure. It states the primary state change (disabled to enabled) but reveals no side effects, error conditions, permission requirements, or what happens if the zone is already enabled.

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, concise sentence with no unnecessary words. It immediately states the core purpose without filler, making it highly efficient.

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 simple tool with one parameter and no output schema, the description is minimally sufficient. However, it lacks context about its relationship to dns_disable_zone or behavior in edge cases, which would enhance completeness.

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 input schema already provides a clear description for the 'zone' parameter ('Zone domain name to enable') with 100% coverage. The tool description adds no additional meaning beyond the schema, 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?

The description clearly specifies the action (enable) and the target (a disabled DNS zone), using a specific verb and resource. This distinguishes it from related tools like dns_disable_zone or dns_create_zone.

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 provides no guidance on when to use this tool versus alternatives. It does not mention that this reverses dns_disable_zone, nor any prerequisites or situations where it should not be used.

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 burden. It discloses the return format ('text') and the output type ('zone file'), but it does not explicitly state whether the operation is read-only or whether any side effects occur. Although 'export' implies non-destructive, explicit disclosure would be stronger.

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 two concise sentences, front-loaded with the action and resource, and contains no filler. Every word contributes 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 one-parameter tool with no output schema and no annotations, the description covers the primary purpose and return value adequately. However, it lacks explicit side-effect disclosure and usage guidance, leaving a small gap but not a major one given the tool's simplicity.

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 coverage is 100% with a clear description for the 'zone' parameter ('Zone domain name to export'). The description adds no additional parameter semantics beyond what the schema already provides, so it falls at the baseline.

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 clearly states the action ('Export') and the specific resource ('DNS zone file') with format ('standard BIND format'). It also clarifies the return type ('text'), and the verb+resource combination distinguishes it from sibling tools like dns_list_records or dns_list_zones.

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 implies when to use the tool (to obtain a zone file in BIND format) but does not explicitly state alternatives or when not to use it. For example, it does not mention that users should use dns_list_records for individual records or dns_list_zones for zone summaries. With multiple DNS tools present, this is a clear gap.

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. It discloses the destructive effect ('All allowed domains will be removed') and the confirmation requirement ('Requires confirm=true to execute'). However, it does not mention whether the action is reversible or how the system responds when confirm is false, though the schema partially covers this.

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?

Two concise sentences front-load the primary action and effect, then add the safety condition. No wasted words or redundant details.

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 simple, destructive flush operation, the description adequately covers purpose, effect, and the single parameter's behavior. No output schema is needed, and the existing schema completes the parameter context.

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 coverage is 100%, and the schema already fully describes the confirm parameter. The description adds no new semantic information beyond restating that confirm=true is required, so it does not exceed the baseline for high schema coverage.

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 clearly states the tool flushes the entire allow list and that all allowed domains will be removed. It uses a specific verb ('flush') and resource ('allow list'), distinguishing it from related tools like dns_remove_allowed.

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 implies usage for removing all allowed domains, but it does not explicitly contrast with dns_remove_allowed or other alternatives. No when-not-to-use guidance is provided.

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. It explicitly states the destructive effect ('All manually blocked domains will be removed') and the safety mechanism ('Requires confirm=true to execute'). This gives an agent the critical information that the tool is irreversible and requires confirmation, which is essential for safe invocation.

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 exactly two sentences, front-loaded with the action verb and resource. Every word serves a purpose: stating the action, scope, consequence, and prerequisite. There is no redundancy or filler, making it highly efficient and easy to parse.

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 simple tool with one parameter, a full schema, and no output schema, the description covers all essential aspects: what it does, what it affects, and the confirmation requirement. It does not explain return values, but given the tool's simplicity and the schema's detail about the warning behavior, this is not a significant gap. The description is complete enough for an agent to invoke the tool 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 already documents the confirm parameter with 100% coverage, describing both the required value and the warning behavior without it. The description only reiterates 'confirm=true' without adding new semantic detail. Thus the baseline of 3 applies, as the schema does the heavy lifting and the description adds little beyond emphasis.

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 uses a specific verb ('flush') and resource ('entire custom block list'), clearly distinguishing it from sibling tools that remove individual blocked domains (dns_remove_blocked) or flush other lists (dns_flush_allowed). It also clarifies scope with 'All manually blocked domains', leaving no ambiguity about what action is performed.

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 clearly states the action and scope ('Flush the entire custom block list'), making it evident when the tool should be used. It does not explicitly name alternatives like dns_remove_blocked, but the context is sufficiently clear. The requirement for confirm=true is also stated, giving a clear precondition for use.

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. It discloses the destructive nature ('flush the entire DNS cache'), the behavioral consequence ('forces all subsequent queries to be resolved fresh'), and a safety requirement ('Requires confirm=true to execute'). It does not mention permissions or reversibility, but these are less critical for a cache flush.

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?

Two sentences, each earning its place. The first states the action and scope; the second explains the confirmation requirement and expected effect. Zero wasted words and the main verb is front-loaded.

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 tool is simple: one required-confirm parameter, no output schema, and a straightforward side effect. The description covers what it does, the scope, the consequence, and the confirmation requirement. It lacks mention of return values or potential side effects like temporary cache miss delays, but these are not essential 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?

The input schema has 100% coverage for the confirm parameter, explicitly describing that it must be true to confirm and that without it a warning is returned. The description's 'Requires confirm=true to execute' adds minor emphasis on execution but provides no substantial new meaning beyond the schema.

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 'Flush the entire DNS cache' uses a specific verb and resource, clearly distinguishing it from sibling tools like dns_flush_blocked, dns_flush_allowed, and dns_list_cache. It also communicates the full scope ('entire') and the purpose ('forces all subsequent queries to be resolved fresh').

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 implies when to use the tool: when the entire DNS cache needs clearing and fresh resolution is desired. It provides clear context but does not explicitly mention alternatives or exclusions (e.g., use dns_delete_cached for per-record removal). This is strong implied guidance, though not as explicit as naming 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely states 'Get the configuration' without mentioning permissions, side effects, return format, or any prerequisites such as the app being installed. This is minimal but not misleading.

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 one concise sentence with no filler. It is appropriately front-loaded and easily parsed.

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 tool is simple with a single parameter and no output schema, so the description is minimally adequate. However, it lacks any detail about what the configuration contains or how to interpret the result, which would be helpful given no annotations or output schema.

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% (the 'name' parameter is described as 'Name of the installed app'). The tool description adds no additional meaning beyond the schema, so it meets the baseline but does not improve on it.

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 clearly states the verb 'Get' and the resource 'configuration for an installed DNS app'. It is specific and distinguishes itself from siblings like dns_list_apps (which lists apps) by focusing on retrieving configuration for a single app.

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 provides no guidance on when to use this tool versus alternatives. There are many sibling tools (e.g., dns_install_app, dns_list_apps), but no mention of when this tool is appropriate or when a different tool should be used instead.

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 must carry the behavioral burden. It indicates this is a get/read operation and constrains the zone to be DNSSEC-signed, which is useful. However, it does not disclose return format, error behavior for unsigned zones, or any permission/rate-limit considerations, leaving some transparency gaps.

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 two short sentences, front-loaded with the action and resource, followed by a brief contextual note. No wasted words; every sentence earns its place.

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 simple one-parameter tool with no output schema, the description adequately conveys the purpose and the DNSSEC context. It could mention the return format or behavior for unsigned zones, but given the simplicity, it is largely complete.

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 input schema documents 'zone' as 'Zone domain name', and the description adds that the zone must be DNSSEC-signed, clarifying a key qualification beyond the schema. This adds meaningful context to the parameter semantics.

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 clearly states the action (Get) and the specific resource (DS records for a DNSSEC-signed zone). It also explains the purpose ('needed by the parent zone registrar'), distinguishing it from most sibling tools that handle general DNS operations.

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 provides clear context for when to use the tool: when DS records are required by the parent zone registrar. However, it does not explicitly mention alternatives or exclusions, though the specific resource (DS records) implicitly distinguishes it from tools like dns_dnssec_info.

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 available, so the description carries the transparency burden. The verb 'Get' clearly implies a read-only, non-destructive operation, which is helpful. However, it does not disclose any authentication requirements, rate limits, or return format details. The listed setting categories describe output scope rather than behavioral traits, adding limited transparency beyond the explicit read-only intent.

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, well-structured sentence that front-loads the main purpose ('Get the current DNS server settings') and then efficiently lists the relevant categories without unnecessary filler. Every word contributes to the meaning, making it concise and effectively organized.

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 no output schema and no annotations, the description must compensate for missing structured information. It adequately covers the high-level content areas (forwarders, blocking, protocols, logging, cache, proxy), which is reasonable for a simple getter. However, it does not detail the exact structure or format of the response, leaving some ambiguity for the agent regarding the output shape.

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 tool has zero parameters, so parameter explanation is unnecessary; the baseline for 0 params is 4. The description adds value by outlining the categories of settings returned, which helps the agent anticipate the output structure, even though no parameter-specific semantics are needed.

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 clearly states the tool's function with the verb 'Get' and the resource 'DNS server settings', and enumerates specific setting categories (forwarders, blocking, protocols, logging, cache, proxy). This distinguishes it well from sibling tools like dns_set_settings (the setter) and dns_get_stats (metrics).

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 implies a read operation for viewing current configuration but does not explicitly state when to use this tool over alternatives, nor does it mention exclusions or prerequisites. No guidance is provided on when to prefer dns_get_settings over related tools, so usage is only implied.

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 the output content (counts and top lists) and the operation is clearly a read-only 'Get', but it does not mention side effects, authentication, rate limits, or any caveats. This is adequate but not rich.

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?

Two concise sentences front-load the verb and resource, immediately followed by the return value composition. There is no redundant or filler content; every sentence adds value.

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 tool's simplicity (one parameter, no output schema, no annotations), the description adequately covers the purpose and return values. It could be improved by noting the default period (LastDay) or any aggregation limits, but these are already in the schema or are minor.

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 input schema already covers the single 'period' parameter with enum values and a description (100% coverage). The tool description adds no additional information about the parameter, so the baseline of 3 is appropriate.

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 uses a specific verb ('Get') and resource ('DNS query statistics') and enumerates the return categories (total queries, cached, blocked, failure counts, top clients, top domains, top blocked domains), which clearly distinguishes it from sibling tools like dns_query_logs or dns_health_check.

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 implies the tool is for retrieving aggregated statistics over a time period, but does not explicitly state when to use it versus alternatives such as dns_query_logs for detailed logs. No exclusions or alternative tool references are provided.

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 present, so the description carries the full burden. It discloses what the tool returns, which strongly implies a read-only, safe operation. However, it does not explicitly mention permissions, error behavior, or side effects (though none are expected for a health check). The listed outputs give substantial transparency beyond a simple 'health check' label.

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: 'Quick health check of the DNS server.' It efficiently lists the returned data in a compact list without fluff or repetition. Every word earns its place.

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 tool's simplicity (no parameters, no output schema), the description is largely complete: it clearly states the purpose and return contents. It could be slightly more complete by specifying the data format or stating that it is read-only, but these are not critical for a basic health check tool.

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 tool has zero parameters and the schema coverage is trivially 100%. With no parameters, the description does not need to explain parameter semantics. The baseline for zero parameters is a 4, and the description adds no unnecessary information.

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 uses a specific verb ('health check') plus a clear resource ('DNS server') and explicitly lists returned data (version, uptime, forwarder config, blocking status, failure rate). This clearly distinguishes it from sibling tools like dns_get_stats, which implies detailed statistics, and other DNS management tools.

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 implies a use case ('quick health check') which is understandable but does not explicitly state when to use this tool instead of alternatives such as dns_get_stats or dns_get_settings. No exclusions or alternative tool references are provided.

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 states the install action but does not disclose whether the operation requires permissions, is reversible, what happens if the app is already installed, or what the response looks like. For a mutation tool this is a significant 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?

Two sentences: first states the purpose, second gives a practical pointer to a related tool. No fluff, and the key information is front-loaded.

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 tool is simple (one param, no output schema) and the description explains the action and how to get the app name. However, it lacks any mention of return behavior, error conditions, or post-install effects, so it is minimally adequate but not fully complete.

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 covers the single parameter 'name' with a detailed description ('exactly as shown in the app store'), so the baseline is 3. The tool description adds little beyond mentioning the app store, which is already implied by the schema.

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 uses specific verbs 'Download and install' and identifies the resource as 'a DNS app from the Technitium app store'. This clearly distinguishes it from siblings like dns_uninstall_app, dns_get_app_config, and dns_list_app_store.

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 explicitly directs the agent to use dns_list_app_store to see available apps before invoking this tool. This provides clear context for when to use this tool versus the listing alternative, though it does not mention 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?

With no annotations, the description carries the transparency burden. It discloses the return format (hierarchical tree) and the key behavior of using an optional domain to drill into subdomains. This goes beyond a simple 'list' and provides useful operational detail, though it doesn't mention permissions, errors, or side effects.

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?

Two sentences, front-loaded with the core purpose, then the hierarchical usage pattern. Every word adds value; no fluff or repetition.

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 simple one-parameter tool with no output schema and no annotations, the description fully covers what the tool does, how to use it, and what it returns. It explains the hierarchical tree and the navigation process, making it complete for an agent to invoke 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?

Schema coverage is 100% and the parameter description in the schema already explains the optional domain parameter and the top-level behavior. The main description adds some context about the tree structure but is largely redundant with the schema, so it adds marginal value beyond the baseline.

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 clearly states the tool lists allowed DNS zones (domains that bypass block lists), which is a specific verb+resource and distinguishes it from siblings like dns_list_blocked and dns_list_zones. It also describes the hierarchical tree behavior, making the purpose unmistakable.

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 provides clear usage context by explaining how to navigate the tree: call with no domain for top-level zones, then pass a domain to drill down. It doesn't explicitly name alternatives or when-not-to-use, but the 'allowed' vs 'blocked' context makes the intended use obvious.

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 of behavioral disclosure. It states the action ('List') and the result ('current status') but does not mention that this is a read-only operation, whether any permissions are needed, or what side effects (if any) might occur. This is a minimal description with no extra 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 a single, concise sentence that is front-loaded with the verb and resource, then adds the status detail. Every word contributes meaning, with no wasted or redundant phrasing.

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 that there are no parameters and no output schema, the description provides a reasonable summary of the return value: installed apps and their status. However, it does not specify what constitutes 'status' (e.g., running, stopped, error) or the format of the returned list, so it is not fully complete, but adequate for a simple list operation.

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 tool takes zero parameters, and the schema is empty. The baseline for no parameters is 4, and the description adds no parameter details (none are needed). It does not attempt to describe parameters that don't exist, so it fully satisfies this dimension.

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 uses a specific verb ('List') and resource ('installed DNS apps') plus the added detail of 'current status'. This clearly distinguishes it from siblings like dns_list_app_store (which lists available apps in the store) and dns_get_app_config (which retrieves a specific app's config).

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 context of 'installed' implies this is for checking what is already on the server, as opposed to dns_list_app_store for available apps. However, the description does not explicitly state when to use this tool vs. alternatives or provide any exclusion criteria, leaving the guidance merely implied.

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 provides minimal behavioral context but accurately states the tool's read-only listing function. It does not mention potential nuances like network dependencies or response structure, but for a simple listing operation this is acceptable.

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 sentence that concisely captures the tool's action, object, and meaningful output fields. There is no unnecessary verbosity, making it well-structured.

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?

While the description does not elaborate on response format or other metadata, it covers the essential aspects for a no-input, listing tool. The mention of versions and descriptions gives the agent a clear idea of what to expect in the output.

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 tool has zero parameters, so the description has no parameter semantics to add. According to the baseline for zero-parameter tools, a score of 4 is warranted.

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 clearly identifies the tool as a listing operation for available apps in the Technitium DNS app store, and specifies the included fields (versions, descriptions). This distinguishes it from sibling tools like dns_list_apps, which likely lists installed apps rather than store-available ones.

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?

No explicit guidance is provided about when to use this tool versus alternatives such as dns_list_apps. The purpose implies usage when browsing the app store, but no direct comparison or exclusion is offered, so the guidance remains implicit.

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 burden. It discloses the key behavioral trait: the hierarchical tree structure and the two calling modes (top-level vs. drill-in). It could also mention that this is a read-only operation, but 'list' implies it. The added context is meaningful beyond what the schema provides.

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?

Two sentences, front-loaded with purpose, and no unnecessary words. Every sentence adds functional value: first defines what it lists, second explains the drill-down mechanism. Highly efficient.

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 simple list tool with one optional parameter, the description is quite complete: it explains both call modes and the hierarchical nature of the output. A bit more detail on what each tree node contains (e.g., whether subdomains are shown as strings) would be useful since there is no output schema, but this is a minor gap.

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 coverage is 100% for the single 'domain' parameter. The description adds value by explaining the parameter's role in the hierarchical traversal ('omit for top-level zones, pass domain to list children'), which goes beyond the schema's basic 'optional parent domain' 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 description states a specific verb and resource: 'List blocked DNS zones (domains that are denied).' It accurately distinguishes the tool from siblings like dns_list_allowed by specifying 'blocked'. The hierarchical tree detail adds further clarity.

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 usage context for the hierarchical drill-down: 'call with no domain to see top-level zones, then pass a domain (e.g. 'com') to drill into subdomains.' It does not explicitly name alternatives like dns_list_allowed, so it doesn't fully meet the 'when-not' criterion, but it's clear enough for the intended use.

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 burden of behavioral disclosure. It explains the hierarchical tree return format and the two-step drill-down behavior, which goes beyond the tool name and schema. It does not mention side effects, but as a 'list' operation, this is likely safe.

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 two sentences, front-loaded with the core purpose, and every sentence adds value. No filler or redundancy.

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 read-only list tool with one optional parameter and no output schema, the description sufficiently covers purpose, usage, and the general return shape (hierarchical tree). The drill-down pattern is clearly explained, making the tool usable without further clarification.

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 sole parameter 'domain' is fully described in the schema (100% coverage), including its optionality and meaning. The description's mention of calling with no domain and then passing a domain reiterates the schema rather than adding new semantic value.

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 clearly identifies the tool's action and resource: 'List zones in the DNS cache'. It also adds a distinctive behavior (hierarchical tree) that sets it apart from sibling list tools like dns_list_zones or dns_list_records.

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 provides explicit drill-down instructions ('call with no domain to see top-level zones, then pass a domain'), which is useful. However, it does not mention when to use this tool over alternatives such as dns_list_zones or dns_list_records, or when not to use it.

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?

There are no annotations, so the description carries the burden of disclosing behavior. It explains the subtle distinction that omitting the domain returns records across all matching zones including subzones, while specifying a domain returns only that exact domain. This adds valuable transparency beyond simple parameter descriptions.

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 highly concise, consisting of two sentences that front-load the core purpose and then add necessary filtering details. Every sentence earns its place with no redundancy.

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 tool with only two parameters and no output schema, the description provides sufficient context about the tool's behavior. It could mention the return format or pagination, but for a straightforward list operation, the current description is adequate and complete.

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 coverage is 100%, so parameters are already described. The description adds extra semantics by clarifying that zone can match subzones and how the domain filter applies, which is not fully captured in the schema descriptions.

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 clearly states the tool lists DNS records in a zone, with an optional filter by domain. It uses a specific verb ('List') and resource ('DNS records'), and distinguishes itself from sibling tools like dns_list_zones by focusing on records within zones.

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 provides clear context on when to use the tool with or without the domain parameter, explaining the behavior for both cases. However, it does not explicitly mention when not to use it or name alternative tools for different tasks.

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. It communicates that the tool lists zones and returns specific fields, which implies a read-only operation, but it doesn't mention any side effects, permission requirements, pagination, or output format beyond the field names. It adds some value but leaves behavioral details unstated.

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 sentence that front-loads the purpose and then lists the return fields. Every word adds value, with no redundancy or irrelevant details. It is appropriately sized for a parameterless list tool.

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 tool's simplicity (0 params, no output schema), the description is complete. It states exactly what the tool does and what it returns, which is sufficient for an agent to select and invoke it correctly. No additional context is needed.

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 tool has zero parameters, so the description doesn't need to explain parameter semantics. The 100% schema coverage (empty) is sufficient, and the description adds no parameter-related info. Baseline for 0 parameters is 4.

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 uses a specific verb ('List'), identifies the resource ('DNS zones'), and clarifies the scope ('all zones configured on the server'). It also specifies the returned fields (name, type, status, record count), clearly distinguishing it from sibling tools like dns_list_records or dns_get_stats.

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 implies when to use the tool—when you need an overview of all DNS zones—but it doesn't explicitly contrast it with alternatives or provide exclusion criteria. It lacks statements like 'for records within a zone, use dns_list_records', so guidance is implied rather than 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, the description must disclose behavior itself. It mentions that the tool returns recent queries and responses and requires an app installation, but it does not state whether the operation is read-only, how errors are handled, or any rate limits. The 'recent' qualifier adds some temporal context but is not fully detailed.

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 exactly two sentences, front-loaded with the verb 'Query' and the resource, and contains no redundant information. Every word earns its place.

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 six-parameter schema with no output schema and no annotations, the description provides a high-level purpose and prerequisite but lacks details on return structure, the exact time window for 'recent', and filter combination behavior. It is adequate but not fully complete.

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?

All six parameters are fully described in the schema (100% coverage), so the description adds minimal value beyond that. The phrase 'optional filters' is only a generic summary and does not clarify parameter usage or relationships beyond the schema.

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 clearly states 'Query DNS server logs' and 'Returns recent DNS queries and their responses', identifying the specific action and resource. This distinguishes it from sibling tools like dns_get_stats or dns_list_records.

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 provides clear context for when to use the tool (when querying DNS logs) and includes a prerequisite ('Requires the Query Logs app to be installed'). It does not explicitly mention alternatives or exclusions, but the context is sufficiently 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?

With no annotations, the description carries the full burden of disclosing behavior. It states that the domain will no longer bypass block lists, indicating a state change. However, it does not mention idempotency, error handling, reversibility, or whether the domain must currently exist in the allow list, leaving gaps in behavioral 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 two sentences, front-loaded with the primary action, and contains no trivial or redundant information. Every word contributes to clarifying the tool's function and effect.

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 simple one-parameter tool with no output schema, the description conveys the purpose and effect clearly. It is complete enough for an agent to understand what the tool does and what will happen. However, the lack of usage guidance and edge-case behavior keeps it from being fully comprehensive.

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 input schema provides 100% coverage for the single 'domain' parameter, so the description adds no additional parameter-level meaning. Per the rubric, a baseline of 3 applies when schema coverage is high and the description does not compensate with extra detail.

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 clearly identifies the action as removing a domain from the allow list and specifies the consequence (the domain will no longer bypass block lists). This distinguishes it from sibling tools like dns_remove_blocked, which operates on a different list.

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 implies usage when one wants to undo an allow-list operation, but it does not explicitly state when to use it versus alternatives or mention any prerequisites. There is no exclusions or contrast with sibling tools, so guidance is implied rather than 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 provided, the description must disclose behavioral traits. It states the immediate effect ('will no longer be denied') but does not mention whether the action is reversible, whether it affects DNS resolution immediately, or any permissions or side effects. This is a mutation tool, and the description carries a thin behavioral burden.

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 two short sentences, front-loaded with the verb and resource. Every word earns its place; there is no filler, redundancy, or unnecessary detail.

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 simple one-parameter tool with no output schema, the description covers the core action and consequence. However, it lacks any usage guidance or behavioral context beyond the basic effect, making it merely adequate rather than complete for an agent that needs to select and invoke the tool 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?

Schema description coverage is 100%: the schema already fully describes the 'domain' parameter as 'Domain name to remove from block list'. The description adds no additional semantic detail beyond what the schema provides, so the baseline score of 3 is appropriate.

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 uses a specific verb ('Remove') and resource ('a domain from the block list'), clearly distinguishing this from sibling tools like dns_remove_allowed (which operates on the allow list) and dns_block_domain (which adds to the block list). It is concise and 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 provides no explicit guidance on when to use this tool versus alternatives. It does not mention that it should be used to unblock a previously blocked domain, nor does it contrast with dns_remove_allowed or dns_block_domain. The usage context is only implied by the tool name and sibling list, not by the description.

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 a key behavioral trait: the ability to resolve via the server itself or an external server. However, it does not mention side effects, read-only nature, or output format. Since the tool is a diagnostic test, the lack of explicit non-destructive language is a minor 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?

The description is two concise sentences with no redundant words. It front-loads the main verb and resource, and quickly covers the key variance (server selection). Every word contributes to understanding.

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 tool's simplicity (4 params, no output schema), the description sufficiently covers the core functionality and the main variant (server). It does not explain return values, but the schema's param descriptions and the obvious nature of DNS resolution make this acceptable. It is complete enough for an agent to invoke 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 input schema provides 100% coverage with descriptions for all four parameters, including enums for type and protocol. The description itself does not add additional parameter semantics, but the schema already does the heavy lifting. Baseline score of 3 is appropriate.

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 clearly states the tool's purpose: testing DNS resolution for a domain name. It specifies the verb 'resolve' and the resource 'domain name', and distinguishes itself from sibling tools by emphasizing the ability to use either the Technitium server or an external server.

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 implies a diagnostic use case: 'Test DNS resolution' suggests when an agent needs to verify DNS resolution. However, it does not explicitly mention alternatives or when not to use this tool, though the context is clear enough to differentiate from management tasks like list or update operations.

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 must carry the full burden of behavioral disclosure. It states the tool updates settings and supports partial updates via key/value pairs, but does not mention side effects, permanence, required permissions, return values, or whether changes are immediately applied. This is a significant gap for a mutation 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?

The description is two sentences with no redundancy. The first sentence states purpose, the second provides essential usage guidance. Every word contributes meaning, making it appropriately sized and front-loaded.

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 8 optional parameters are fully documented in the schema and the description provides a usage prerequisite, the description is adequate. However, for a mutation tool with no output schema or annotations, it would benefit from stating what the success response looks like, whether changes require a service restart, or any side effects on existing settings. These gaps keep it from being complete.

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 coverage is 100%, so the baseline is 3. The description adds value by clarifying that only settings to change need to be passed, reinforcing the partial-update behavior. It also suggests using dns_get_settings to discover available keys, which aids parameter understanding beyond the raw schema.

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 clearly states 'Update DNS server settings', using a specific verb and resource. It distinguishes from sibling tools like dns_get_settings and zone-specific tools by focusing on global server settings, and provides concrete examples of what can be changed.

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 provides explicit guidance to use dns_get_settings first to see current values and available keys, indicating a recommended workflow. It implies this tool is for server-wide settings rather than zone/record-specific changes, though it does not explicitly name alternatives like dns_set_zone_options.

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 burden of disclosing behavioral traits. It clearly implies a mutation operation, but it does not explain whether the update merges with existing options or replaces them, what permissions are required, or whether there are side effects (e.g., triggering zone transfers). The description adds only minimal behavioral context beyond the fact that options are updated.

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 two sentences with the core purpose front-loaded ('Set configuration options for a zone') and the rest providing concise, non-redundant detail. Every sentence earns its place, and there is no excess verbiage.

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 tool has a simple parameter set (4 params, 1 required) with full schema coverage and no output schema, so the description need not explain return values. The description clearly communicates the purpose and the update semantics, making it sufficiently complete for an agent to select and invoke the tool. Minor gaps are in usage alternatives and side effects, but these are not critical given the overall clarity.

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 already provides 100% coverage with explicit descriptions for all four parameters, so the baseline is 3. The description adds value by framing the parameters as 'option key/value pairs to update', which implies partial update semantics and clarifies that only explicitly passed options are changed. This meaning goes slightly beyond the schema descriptions.

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 clearly states the tool's function as setting configuration options for a zone, using a specific verb ('Set') and resource ('zone'). It also gives concrete examples (notify settings, zone transfer ACLs) that distinguish it from sibling tools like dns_enable_zone/dns_disable_zone or dns_zone_options.

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 provides basic usage instructions ('Pass the zone name plus any option key/value pairs to update') but does not explicitly state when to prefer this tool over alternatives such as dns_enable_zone/dns_disable_zone for the disabled flag, nor does it mention any exclusions or prerequisites. Usage is implied rather than explicitly contrasted with siblings.

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 the key behavior: the temporary disable state and automatic re-enablement after the timer. It adds context beyond the name but omits details like scope (all blocking vs. specific domains) and any side effects.

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?

Two sentences, zero waste. The description is front-loaded with the primary action and includes the critical auto-re-enable behavior. Every word earns its place.

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 one-parameter tool with no output schema, the description covers the purpose, duration, and automatic re-enablement. It is nearly complete, though it could further clarify the scope (global vs. specific domain) and what happens to existing blocked domains during the window.

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 coverage is 100% since the single parameter 'minutes' is described with a default. The description reinforces the meaning ('specified number of minutes', 'timer expires') but does not add extra constraints like min/max or units beyond what the schema provides.

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 clearly states a specific action: temporarily disabling domain blocking with an auto re-enable timer. It uses a specific verb and resource, and the temporary nature distinguishes it from sibling tools like dns_remove_blocked (permanent) and dns_block_domain (blocking).

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 provides clear context for when to use the tool (when you need a temporary override that auto-reverts) without explicit exclusions. It implies a scenario but does not name alternatives, so it doesn't reach the level of explicit 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?

With no annotations, the description must disclose behavioral traits. It mentions the confirm=true requirement, hinting at the destructive nature, but it does not explicitly state that uninstalling is permanent, irreversible, or what happens to associated data. The word 'uninstall' implies removal, but consequences are not disclosed. This is a significant gap for a destructive operation.

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?

Two short sentences, no fluff. Every word earns its place. The key information (what it does and the confirm requirement) is front-loaded and concise.

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 tool is simple with only 2 params, and schema covers both completely. However, it is a destructive operation with no annotations or output schema, so the description could be more explicit about side effects or reversibility. The confirm requirement is helpful, but the overall context feels minimally sufficient rather than complete.

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 coverage is 100%, so baseline is 3. The description repeats what the schema already states for confirm ('Requires confirm=true') but adds no new semantic meaning beyond the schema's existing 'Must be true' description. For the name parameter, the description adds 'DNS app' context already obvious from the schema. No extra value.

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 the action clearly: 'Uninstall a DNS app from the server.' This uses a specific verb (uninstall) and resource (DNS app), distinguishing it from sibling tools like dns_install_app, dns_list_apps, and dns_get_app_config. No ambiguity.

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 clearly indicates that confirm=true is required for execution, which is a critical usage prerequisite. However, it does not explicitly contrast with alternatives or state when to prefer this over other tools, though the name and context make that obvious. No exclusions are given, but the confirm requirement conveys a safety gate.

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 burden. It states the action and frequency context but does not disclose potential side effects (e.g., service disruption, download time), return behavior, or any prerequisites. This is acceptable for a simple operation but leaves gaps.

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 two short sentences, front-loaded with the action. Every word contributes meaning, and there is no redundant information.

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?

This is a simple, zero-parameter tool with no output schema. The description explains the purpose and normal cadence, which is largely sufficient. Missing details about post-update confirmation or failure behavior are minor given the tool's simplicity.

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?

There are zero parameters, and the schema coverage is 100% vacuously. The description does not need to elaborate on parameter semantics, and the baseline of 4 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?

The description uses a specific verb 'Force an immediate update' and clearly identifies the resource 'all configured block lists'. It distinguishes itself from sibling tools like dns_check_update by emphasizing the forced/immediate nature.

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 explains the normal 24-hour update cycle, implying this tool is for when an immediate update is needed. However, it does not explicitly state when not to use it or mention alternatives like dns_check_update for checking status.

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 burden of behavioral disclosure, but it only restates the tool's name. It does not mention whether the operation is destructive, requires specific permissions, or what happens if the record does not exist. The description adds zero value beyond the tool's name.

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 concise sentence with no wasted words. It is front-loaded with the primary action, but it is so brief that it misses opportunities to include high-value context without becoming verbose.

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?

Despite having 7 parameters and 5 required, the description provides no overview of how parameters interact (e.g., the relationship between 'value' and 'newValue', or that 'newDomain' renames a record). With no annotations and no output schema, the description is inadequate for an agent to understand the full scope of the update operation.

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 every parameter already has a description. The tool description adds no additional meaning to the parameters, maintaining the baseline of 3 as per the rubric.

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 'Update an existing DNS record' clearly states the action and resource, distinguishing it from sibling tools like dns_add_record and dns_delete_record. However, it lacks any scope detail such as which fields are updatable, so it does not fully differentiate from all possible update-like tools.

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?

No guidance is provided on when to use this tool versus alternatives like dns_add_record or dns_delete_record. There is also no mention of dns_check_update for validation or any prerequisites, leaving the agent without contextual direction.

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 states the tool 'Get's options and lists the covered setting groups, but it does not disclose the response format, whether settings are returned in a single structure, or any prerequisites such as zone existence.

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 sentence that front-loads the verb and includes only essential information, with no filler or redundancy. It is concise and easy to parse.

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 simple read tool with one well-documented parameter, the description adequately explains what the tool does and what settings are included. It lacks mention of return structure, but the absence of an output schema and the narrow scope make this a minor gap.

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 already fully describes the only parameter 'zone' as 'Zone domain name' (100% coverage). The description only says 'specific zone', adding no extra meaning beyond what the schema provides.

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 uses the specific verb 'Get' and clearly identifies the resource as 'configuration options for a specific zone', naming DNSSEC, transfer, and notify settings. This distinctly separates it from the sibling dns_set_zone_options, which modifies options.

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 implies usage for retrieving a zone's settings but provides no explicit when-to-use guidance or exclusions relative to siblings like dns_get_settings or dns_dnssec_info. The context is clear but no alternatives are mentioned.

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