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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description doesn't need to repeat those. It adds context about the scope of the assessment (policies, named lists, etc.) and the return contents, which is useful but not deep behavioral disclosure. No additional constraints like pagination or permission requirements are mentioned, so a mid-score is appropriate.

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 tightly packed: a one-line purpose, explicit usage guidance, alternative tool references, return value summary, and example. Every sentence earns its place with no redundancy or 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?

Given zero parameters, a read-only annotation, and a separate output schema, the description covers all necessary context: what the tool does, when to use it, what it returns, and how it differs from related tools. No gaps remain for the agent to operate effectively.

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 baseline is 4. The description provides an example call with no arguments, clarifying that the tool takes no input. There is nothing more to explain beyond what the schema already shows (empty properties).

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?

Description clearly states the tool assesses overall DNS security posture with specific areas (policies, named lists, category filters, compliance, analytics). It distinguishes from sibling tools like investigate_threat and triage_security_insight by explicitly naming them as alternatives.

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?

Explicitly instructs to use for security audits and compliance reporting, and provides direct alternatives for active threat investigation and triage actions. This gives clear when-to-use and when-not-to-use guidance, referencing sibling tools by name.

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?

Annotations already declare readOnlyHint and openWorldHint, so the bar is lower. The description adds meaningful context by specifying the three service clients checked, the diagnostic purpose (API key validation, connectivity), and that response times are returned. No contradictions with 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 well-organized with clear sections (purpose, usage, returns, example). It is slightly repetitive in phrases like 'Verify connectivity' and 'verify the MCP server can reach Infoblox,' but overall it is 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 tool's simplicity (no params, output schema exists, annotations cover safety), the description fully covers purpose, usage, and output. It is complete for an agent to select and invoke correctly, especially with the explicit alternative.

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 schema coverage is 100% (empty schema), so the baseline is 4. The description adds relevant context about the scope (all three service clients) even though there are no parameters to explain.

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 verifies Infoblox API connectivity for three specific service clients (DDI, Insights, ATCFW). It explicitly distinguishes itself from the sibling check_infrastructure_health, making its 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 provides explicit usage guidance: 'USE THIS to diagnose connection issues, check if API keys are valid, or verify the MCP server can reach Infoblox.' It also names the alternative tool for infrastructure health, giving clear when-to-use and when-not-to-use instructions.

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?

Annotations already declare readOnlyHint true. The description adds specific context about the scope (which infrastructure components are covered) and the nature of the output (health report with statuses and recommendations), which supplements the annotations without contradiction.

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 efficiently organized: purpose statement first, clear usage callout, alternative named, return description, and an example. Every sentence adds value and the structure is scannable.

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

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

Given the low complexity (no parameters, output schema available, read-only annotation), the description provides all necessary context: what it checks, return content, and use case. There is no missing information that would hinder correct tool selection or 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 tool has zero parameters and the input schema has 100% coverage. The baseline for zero parameters is 4 per the rubric. The example invocation confirms no arguments are needed, and no additional parameter explanation is necessary or possible.

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: 'Check the health of all DDI infrastructure components' and enumerates exact component types (HA groups, DHCP hosts, DNS zones, DNS views, IP spaces). It clearly distinguishes from sibling tools by noting alternatives for capacity and security.

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?

Explicit guidance is provided: 'USE THIS for operational health monitoring and alerting.' It also names alternatives for capacity planning (get_ip_utilization) and security health (assess_security_posture), covering both when to use and when not to 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?

The description goes beyond the destructiveHint annotation by explaining the dry_run default, what gets deleted (IPAM host, DNS records, IP addresses), and the return value (list of resources deleted). It also includes an explicit warning about setting dry_run=False, which is critical behavioral context 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?

The description is well-structured and front-loaded: the first sentence gives the core purpose, followed by usage direction, an important warning, parameter docs, return info, and examples. Every sentence adds value, and the examples clarify edge cases without being 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?

Given the tool's destructive nature and the presence of an output schema, the description still provides complete context: it defines all parameters, explains return values, includes multiple examples, and notes the dry_run safety mechanism. It leaves no ambiguity about how to invoke the tool for either dry-run or actual decommission.

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 only lists 'identifier' and 'dry_run' with types, but the description adds meaning: identifier can be a hostname, FQDN, or IP address, and dry_run defaults to True with clear semantics. Since schema description coverage is 0%, the description fully compensates by defining each parameter's purpose and acceptable values.

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 a clear action: 'Decommission a host: removes IPAM host, DNS records, and releases IP addresses.' This states the specific verb, resource, and scope, and distinguishes it from sibling tools by explicitly naming alternatives for partial cleanup (manage_dns_record, manage_ip_reservation).

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?

Usage guidance is explicit: 'USE THIS to fully remove a host. For partial cleanup use manage_dns_record() or manage_ip_reservation().' It also clearly explains the dry_run default behavior and how to execute the actual decommission, giving an agent clear decision criteria.

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?

Beyond the readOnlyHint annotation, the description discloses the flush_cache behavior, which mutates DNS cache state, and instructs to ASK the user before flushing. It also notes when 'view' is required, adding contextual constraints not in 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 well-organized with sections for summary, usage, args, returns, and examples. Every sentence provides necessary information, and examples clarify usage without 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?

Given the tool's complexity (3 params, one required) and presence of output schema, the description still summarizes the return report. It covers alternatives, parameters, side effects, and examples, making it fully self-contained for correct invocation.

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

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

Schema has 0% description coverage, but the description fully documents each parameter: domain with examples, view with requirement context, and flush_cache with usage and caution. This adds substantial 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 states a specific action: diagnose DNS resolution problems, and specifies the scope (zone, records, security policies). It distinguishes from sibling tools by pointing to diagnose_ip_conflict for IP-level issues and check_infrastructure_health for infrastructure-wide health.

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?

Explicitly states when to use: 'USE THIS when a domain isn't resolving or has DNS issues.' It names alternatives for IP-level and infrastructure-wide issues, giving clear context for tool selection.

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?

Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds behavioral context beyond this, detailing exactly what is checked (overlapping subnets, duplicate reservations, DHCP usage, host associations) and what the return report contains. No contradictions with annotations are present.

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

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

The description is well-structured with a clear purpose statement, usage guidance, argument definition, return summary, and examples. It is moderately detailed but every section serves a purpose; the examples are practical and avoid redundancy. It is not excessively wordy.

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 read-only diagnostic tool, the description covers all essential context: what it does, when to use it, alternatives, parameter format, and return value. The presence of an output schema reduces the need to enumerate return fields. The examples further anchor correct usage.

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 only a type for 'address' with no description (0% schema coverage). The description fully compensates by defining 'address' as 'IP address to check' and giving concrete examples ('10.20.3.50', '192.168.1.1'). This adds essential meaning for correct invocation.

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 tool's purpose: 'Check an IP address for conflicts' and enumerates the specific conflict types it covers (overlapping subnets, duplicate reservations, DHCP usage, host associations). This level of specificity distinguishes it from sibling tools like diagnose_dns and check_infrastructure_health.

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 states when to use the tool: 'USE THIS when troubleshooting IP conflicts or verifying an IP is safe to use.' It also provides clear alternatives: 'For DNS-level issues use diagnose_dns(). For infrastructure-wide health use check_infrastructure_health().' This gives the agent direct guidance on selection.

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?

Annotations already indicate readOnlyHint=true and openWorldHint=true, so the description doesn't need to disclose safety. It adds context about returning a hierarchical view with utilization percentages, and clarifies that depth controls detail. Minor gap: it doesn't explicitly say whether the operation is safe or has side effects, but annotations cover that.

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

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

The description is well-organized with clear sections (Args, Returns, Examples) and is appropriately sized for the tool's complexity. Every sentence adds value—no fluff or repetition of schema details. Examples are compact and illustrative.

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 moderate complexity (3 optional params, output schema), the description is complete: it explains the hierarchy, usage boundaries, parameter semantics, and return expectations. Sibling tools are distinguished, and examples show typical calls. No missing critical information.

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

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

Schema description coverage is 0%, so the description carries full responsibility for explaining parameters. It does so effectively: scope is described as optional IP space name with examples ('prod', 'corp'), depth explains the three levels, and limit explains default and meaning. Examples illustrate usage combinations.

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: 'Browse the IP hierarchy tree (Spaces → Blocks → Subnets) with utilization data.' It uses a specific verb ('browse') and resource, and distinguishes itself from siblings by naming alternatives for other use cases, such as get_network_summary and search_infrastructure.

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?

Explicit guidance is provided: 'USE THIS to navigate and drill into network structure.' It also states when NOT to use it and points to alternatives: 'For executive dashboards use get_network_summary(). For keyword search use search_infrastructure().' This exceeds basic requirements.

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?

Annotations already declare readOnlyHint and openWorldHint, and the description adds contextual detail about returning a utilization report with percentages per space/block/subnet and scope behavior. It does not contradict annotations and provides extra value beyond them, though it does not cover edge cases like invalid scope.

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

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

The description is well-structured with sections for purpose, usage, arguments, returns, and examples. Every sentence contributes useful information without fluff 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 simple read-only tool with one optional parameter and an output schema available, the description covers purpose, usage, parameter meaning, return value characteristics, and sibling differentiation. It is sufficiently complete for an AI agent to select and 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 schema has one parameter 'scope' with no description (0% coverage). The description fully compensates by explaining 'Optional IP space name to focus on. If not set, shows all' and provides concrete examples for both usage patterns.

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 'Get IP address utilization percentages for capacity planning' with a specific verb and resource. It also distinguishes itself from siblings by naming explore_network() and check_infrastructure_health() as alternatives.

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 says 'USE THIS to find overutilized subnets and plan expansions' and provides direct alternatives: 'For hierarchy browsing use explore_network(). For infrastructure health use check_infrastructure_health().' This gives clear when-to-use and 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?

Annotations already declare readOnlyHint and openWorldHint. The description adds useful context about the return type (counts, utilization, health) and optional scope behavior. No contradictions found.

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 compact and well-structured: purpose, usage, args, returns, examples. Every sentence adds value with 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?

This is a simple tool with one optional parameter and an output schema. The description covers purpose, scope semantics, return type, and examples comprehensively. No meaningful gaps remain.

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 lone parameter 'scope' is clearly defined: 'Optional IP space name to focus on. If not set, summarizes everything.' Examples demonstrate usage (e.g., scope='production'). This fully compensates for the 0% 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 uses a specific verb ('Get') and resource ('executive dashboard') with clear scope ('all DDI infrastructure'). It explicitly distinguishes from siblings: 'For hierarchy browsing use explore_network(). For keyword search use search_infrastructure().'

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 provides explicit guidance: 'USE THIS for high-level overviews and reporting' and names alternatives for specific use cases (hierarchy browsing, keyword search). Examples further illustrate appropriate contexts.

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?

Annotations include readOnlyHint=true, so the read-only nature is already conveyed. The description adds useful context about aggregation and return content (indicators, affected assets, timeline, recommendations). No behavioral contradictions exist. It doesn't mention rate limits or permissions, but those aren't expected for this kind of tool given the 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 well-structured with sections for purpose, usage guidance, args, returns, and examples. Every section adds value and none are redundant. It is appropriately sized for the tool's complexity.

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 output schema exists and annotations cover read-only behavior, the description is complete. It provides clear usage context, parameter semantics, and examples. It covers the main behavior (aggregating active security threats) and return content sufficiently.

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 0%, so the description fully carries parameter explanation. It defines query as an optional search term or threat type with examples ('malware', 'phishing'), priority as a filter by priority level, and limit as maximum insights with a default of 20. Examples further illustrate usage.

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: 'Investigate active security threats: aggregates SOC insights, indicators, affected assets, and timeline events.' It uses a specific verb and resource, and explicitly differentiates from siblings by referencing assess_security_posture for policy compliance and triage_security_insight for triage actions.

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?

Explicit usage guidance is provided: 'USE THIS for threat investigation and incident response. For policy compliance use assess_security_posture(). For triage actions use triage_security_insight().' This clearly states when to use this tool and direct 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?

Annotations already flag destructiveHint=true. The description adds valuable safety context by documenting the dry_run parameter ('If True (default), delete shows resource only. Set False to execute.'), a behavioral trait not present in annotations. It also clarifies special action assignments like 'bulk_create for mac_item' and 'link/delink for config_profile'. However, it could further disclose permission requirements or side effects of updates, but the dry-run disclosure substantially raises transparency beyond 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?

Despite its length, the description is well-structured into Args, Returns, and Examples. Each sentence adds information, with no filler. Front-loaded purpose and usage guidance make key information immediately accessible. The format is appropriate for a tool with 12 resource types and 15 parameters.

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 complexity, the description is remarkably complete: it covers all parameters, special constraints (dry_run, bulk_create/link/delink), includes extensive examples, and provides alternate tool guidance. The existence of an output schema reduces the need to describe return values in prose, and the description still notes 'Returns: DHCP operation result'.

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

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

Schema description coverage is 0%, so the description carries the full burden. It provides semantics for all 15 parameters, linking each to the relevant resource type/action (e.g., 'mode: HA group mode (e.g., "active-active", "active-passive") — for ha_group create'). The examples further clarify parameter usage, making the tool usable without schema property 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 opens with 'Manage DHCP configuration' and enumerates 12 resource types, clearly distinguishing it from siblings by explicitly directing IP reservations to manage_ip_reservation() and network topology to manage_network(). The verb and resource scope are specific 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?

Provides explicit usage guidance: 'USE THIS for DHCP-specific CRUD' and names two alternative tools for adjacent concerns. Examples illustrate typical calls across multiple resource types and actions, giving the agent clear context for when to choose this tool over 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?

While annotations already flag destructiveHint=true, the description adds crucial context: 'clear permanently removes leases' and 'Runs in dry_run mode by default for clear/resend_ddns. Set dry_run=False to actually execute destructive actions.' This informs the agent of the tool's safety default and the irreversible nature of clear, going well beyond the annotation.

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

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

The description is well-structured with clear sections (overview, usage note, Args, Returns, Examples) and is front-loaded with purpose. It is somewhat longer than strictly necessary, but every sentence contributes useful information, and the examples justify the length.

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 complexity (9 parameters, 4 action modes, destructive behavior), the description covers all parameter semantics, safety defaults, alternatives, and usage examples. The presence of an output schema means the return value is already structurally documented, so no further return explanation is needed. This is a complete and robust description.

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

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

The schema has 0% description coverage for parameters, but the description explicitly defines every parameter (action, address, mac_address, hostname, state, space, resource_id, dry_run, limit). It adds meaning by explaining under what conditions each is required (e.g., 'space is required for clear/resend_ddns to resolve address') and provides concrete usage examples.

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 'Manage DHCP leases: list/search active leases, wipe leases, or resend DDNS updates', which clearly identifies the tool's resource (DHCP leases) and its operations. It also explicitly distinguishes from sibling manage_dhcp by stating 'For DHCP configuration use manage_dhcp()'. This makes the tool's purpose unmistakable and well differentiated.

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: 'USE THIS for DHCP lease visibility and maintenance. For DHCP configuration use manage_dhcp().' It also includes multiple examples for each action, clarifying when to use list, get, clear, and resend_ddns. The dry_run warning further explains safe usage for destructive actions.

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?

The description goes beyond the annotations (destructiveHint=true) by disclosing the dry_run default (True) for delete ('delete shows record details only. Set False to execute'), which is critical safety information. It also transparently states that action='create' routes to provision_dns and 'explains why', adding behavioral context not present in 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 longer than minimal but well-structured: purpose, usage guidance, Args, Returns, and Examples. It front-loads the key purpose and usage rules. While it is verbose due to 11 parameters and 5 actions, every sentence serves a purpose without redundancy. A small deduction for length, but not for waste.

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 complexity (multiple actions, 11 params, smart lookup, dry-run safety), the description is exceptionally complete. It covers all parameters, gives concrete examples for list/get/update/delete, explains inter-tool routing, and includes the output schema expectation. With an output schema present, it does not need to detail return values. Nothing essential is missing.

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

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

With 0% schema description coverage, the description carries the full burden of explaining parameters. The 'Args:' section defines every parameter, including types, defaults, and purpose, plus an example for rdata ('{"address": "10.0.0.1"}'). This fully compensates for the bare input schema and provides more context than a typical 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 and specifically states the tool's function: 'Update, delete, list, or get existing DNS records.' It also distinguishes from sibling tools by explicitly naming `provision_dns()` for creation and `manage_dns_zone()` for zone management. This leaves no ambiguity about what this tool does.

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

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

Usage guidance is explicit: 'USE THIS for record lifecycle after creation' and alternatives are named directly ('For creating new records use provision_dns()', 'For zone management use manage_dns_zone()'). It even explains the fallthrough behavior for action='create' and provides multiple actionable examples.

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?

Annotations already include destructiveHint=true and idempotentHint=false, so the safety profile is known. The description adds the list of operations and parameter scoping, but it does not elaborate on side effects (e.g., unsign removes DNSSEC signatures, delete_key is irreversible) or the exact return format beyond 'DNSSEC operation result'. 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?

The description is well-organized with a concise summary, explicit alternatives, an Args list, Returns line, and representative examples. Every sentence earns its place; there is no fluff or redundancy. It is compact yet comprehensive.

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 5 parameters, 6 actions, and an output schema present, the description covers the key aspects: it lists all operations, documents each parameter, provides usage examples, and clarifies tool boundaries. The lack of detailed keyset structure or per-action side effects is a minor gap, but overall it is nearly complete for a tool of this 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?

Schema description coverage is 0%, so the description must compensate. It does so with an Args section that explains each parameter and maps zone_id vs zone_ids to specific actions. Examples further clarify usage, though the keyset dict is only shown as {'keys': [...]}, leaving some structure implicit. Overall, it adds substantial value beyond the bare 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 the tool's purpose: 'Manage DNSSEC key lifecycle for authoritative zones' and enumerates the specific operations (sign, unsign, status, export trust anchors, delete keys, import keysets). It also differentiates from siblings by explicitly mentioning manage_dns_zone and manage_rpz_policies. This is a specific verb+resource+scope formulation.

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 says when to use alternative tools: 'For zone management use manage_dns_zone(). For RPZ rules use manage_rpz_policies().' This provides clear when-not guidance. Additionally, the Args and Examples sections illustrate how to use each action, reinforcing when to use the tool.

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?

Adds critical behavioral context beyond the annotations: dry_run defaults to True for mutating actions, sign/unsign/dnssec_status restricted to auth_zone, reorder restricted to rpz, and the view scoping requirement with a recommendation to list view names first. No contradiction with the destructiveHint annotation; the dry_run safety is a valuable complement.

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 long but exceptionally well-structured: a purpose statement, routing guide, important notes, args, and examples. Every section provides high-value, non-redundant information. The front-loaded sibling differentiation and routing table make it easy to scan.

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 15 parameters and 12 resource types, the description is remarkably complete. It covers action/resource_type matrices, dry-run safety, view scoping nuances, and provides 11 examples. Since an output schema exists, the terse 'Returns: Zone operation result' is acceptable—return format is documented elsewhere.

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

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

Schema description coverage is 0%, so the description carries the full burden—and it succeeds. The Args section explains all 15 parameters with contextual meanings (e.g., 'primary_type: For auth/rpz zones — cloud or external', 'zone_ids: List of zone IDs for sign/unsign/reorder operations'). Examples further demonstrate parameter usage for different resource types.

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 manages DNS zones and related resources, and explicitly distinguishes it from siblings: 'USE THIS for zone lifecycle operations. For DNS record CRUD use manage_dns_record(). For record creation use provision_dns().' The broad resource list is anchored by a specific directive.

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 an extensive quick routing guide mapping each resource_type to supported actions, explicitly names alternative tools, and gives operational caveats like dry_run behavior and view scoping. This goes far beyond minimal guidance and gives concrete when-to-use and when-not-to-use instructions.

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?

Annotations already indicate destructiveHint=true and idempotentHint=false. The description adds some context by showing create/update/list operations in examples, which align with the destructive hint. However, it does not disclose specific side effects, permissions, or what gets modified beyond the action names.

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

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

The description is well-organized with an overview sentence, Args, Returns, and Examples. The examples are numerous but each adds value by covering a distinct action. It is somewhat long, but the structure keeps it scannable and the content is purposeful.

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 complexity (8 actions, 4 params, output schema present), the description covers all actions with examples and parameter mappings. It does not explicitly explain mutual exclusivity of params or return value details, but the output schema and examples mitigate this. Overall, a solid baseline for an action-dispatching 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?

With 0% schema description coverage, the description compensates by explaining each parameter's role: action as operation selector, fqdn for create_doh_fqdn, data for create_doh_fqdn/create_threat_indicator, and updates for approval updates. This goes well beyond the raw schema and gives actionable mapping to specific actions.

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 manages DoH FQDNs, PoP regions, threat feeds/indicators, and approval lists, which distinguishes it from sibling network/DNS tools. The verb 'Manage' is broad, but the enumerated resources and examples give concrete scope.

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 examples that imply when to use each action (e.g., 'list_pop_regions', 'create_doh_fqdn'), but it does not explicitly state when to prefer this tool over alternatives or when not to use it. Usage guidance is implied through the action list, not stated.

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

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

Annotations already indicate destructiveHint=true, but the description adds essential context: 'Delete runs in dry_run mode by default' and explains that LBDN is the primary resource with pools/servers/policies as supporting configuration. This goes beyond annotations, though it stops short of detailing dependency effects or auth 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 well-structured: clear purpose, usage guidance, a prominent dry-run warning, parameter list, returns, and examples. Every section earns its place, is front-loaded, and avoids fluff.

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 complexity (4 resource types, 5 actions, 8 params) and the presence of an output schema, the description covers core aspects well with examples for list and LBDN create. However, it lacks a matrix of valid resource_type/action combinations and deeper dependency semantics (e.g., whether pools must be linked to an LBDN), which an agent might need 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?

Despite 0% schema description coverage signal, the Args section adds meaning: 'name: Resource name (for create/update)', 'resource_id: Resource ID for get/update/delete', and 'view: DNS view ID (for LBDN create)' clarify parameter roles and conditional usage. It compensates reasonably, though some descriptions remain generic ('Type of DTC resource to manage').

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 'Manage DNS Traffic Control (DTC/GSLB): LBDNs, pools, servers, and policies,' which clearly states the verb and resource scope. It explicitly distinguishes from sibling tools by directing users to manage_dns_zone() and manage_dns_record() for other DNS tasks, making the 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 explicitly says 'USE THIS for global server load balancing and traffic steering' and provides clear alternatives: 'For DNS zones use manage_dns_zone(). For DNS records use manage_dns_record().' It also flags the dry-run default for delete, guiding safe usage.

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?

Annotations already flag destructiveHint=true, and the description adds crucial context by explaining the dry_run parameter defaults to True and that delete only shows the resource unless set to False. It also notes that allocate_next is restricted to blocks. While it doesn't describe every mutation detail, it covers the most salient behavioral aspects beyond what annotations provide.

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

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

The description is well-structured with an intro, usage guidance, an Args list, Returns, and Examples. Every line serves a purpose, and the parameter list is compact yet informative. The examples are practical and demonstrate correct invocation. The length is justified given the tool's complexity.

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 covers all essential aspects: what the tool does, when to use it, what each parameter means, and concrete examples. It even clarifies the default behavior of dry_run. Since an output schema exists, the brief 'Returns: Federation operation result' is sufficient. This description is complete for an agent to correctly select and invoke the 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?

Despite 0% schema description coverage, the description manually documents all 10 parameters with clarifying context. It explains the role of each parameter (e.g., 'cidr: CIDR prefix length for allocate_next', 'address: CIDR address for blocks/delegations') and clarifies constraints like 'allocate_next only for blocks'. This fully compensates for the lack of 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 it manages federated IPAM and enumerates the specific resource types (realms, blocks, delegations, pools, etc.). It also explicitly differentiates itself from sibling tools by saying 'USE THIS for federated/multi-site IPAM operations' and pointing to manage_network() for local IPAM and manage_ip_reservation() for reservations.

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 explicit when-to-use guidance and names alternatives: 'USE THIS for federated/multi-site IPAM operations. For local IPAM use manage_network(). For IP reservations use manage_ip_reservation().' The included examples further illustrate common usage patterns, leaving no ambiguity about when to invoke this tool.

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?

Annotations mark destructiveHint=true, and the description adds a crucial safety detail: 'Release runs in dry_run mode by default — shows host associations before releasing.' This goes beyond the annotation without contradicting it. However, it does not elaborate on other potential side effects (e.g., permanent deletion on release with dry_run=False), so it's not a full behavioral disclosure.

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

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

The description is logically organized into summary, explicit usage note, Args, Returns, and Examples. It is a bit lengthy but every section serves a purpose, and the important dry_run warning is prominently placed. Minor redundancy like 'Reservation operation result' could be trimmed, but it's 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?

Given the tool's complexity (8 params, 5 actions, output schema present), the description covers purpose, when-to-use, parameter semantics, safety behavior, and multiple examples. Output schema exists, so return details are unnecessary. This is a complete, actionable description for an AI agent.

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 are absent (0% coverage), so the description carries the full burden. It defines every parameter in the Args section (action, address, space, mac, hostname, comment, resource_id, dry_run), notes requirements (e.g., 'space required for reserve'), and illustrates usage with concrete examples. This fully compensates for the schema gap.

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

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

The description opens with 'Reserve, release, list, get, or update fixed IP addresses and DHCP static leases,' which is a specific verb+resource pairing. It further orients by saying 'USE THIS for IP reservation CRUD,' explicitly distinguishing from related sibling 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 provides explicit when-to-use guidance: 'USE THIS for IP reservation CRUD. For network topology use manage_network(). For IP conflicts use diagnose_ip_conflict().' It also warns about the default dry_run behavior for release, which is essential usage context.

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?

The annotations only provide destructiveHint and idempotentHint. The description adds valuable behavioral context: delete defaults to dry_run, and next_available_* actions require specific resource_type and params. No contradiction with annotations, though it doesn't cover permission requirements 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?

The description is organized with a summary, usage notes, parameter list, return note, and examples. Each section serves a purpose; the length is justified by the tool's complexity and the lack of schema descriptions.

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?

Covers all 7 actions, explains key constraints (dry_run, required params for next_available), and provides 6 examples across different resource types and actions. The output schema is noted, so return details are not necessary. It is complete for such a versatile 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 has 0% description coverage, so the description must compensate. It explains every parameter (resource_type, action, name, address, space, start, end, resource_id, cidr, count, comment, tags, dry_run) in plain language and includes multiple examples demonstrating usage.

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 starts with 'Manage IPAM network resources: create, update, delete, get, list, and allocate next-available subnets/blocks' — a clear verb+resource statement. It also distinguishes from siblings by naming manage_ip_reservation() and get_ip_utilization() as alternatives.

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?

Explicitly says 'USE THIS for IPAM CRUD operations' and directs to alternatives for reservations and utilization. Also highlights the dry_run default and the required parameters for next_available_* actions, giving clear when-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?

Beyond the annotations (destructiveHint=true, idempotentHint=false), the description explains the dry_run parameter, revealing that delete is non-destructive by default and requires explicit opt-in to execute. This is valuable behavioral context not evident from annotations alone. No contradiction with 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 well-structured with a concise purpose sentence followed by Args, Returns, and Examples. Each section provides necessary information without fluff, and the examples are particularly useful. The length is appropriate given the tool's complexity.

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 covers all actions, parameters, and even provides a fallback to manage_dns_zone for zone lifecycle. With an output schema present, the vague Returns line is acceptable. The tool is fully contextualized within its sibling set and usage scenarios.

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 no parameter descriptions (0% coverage), but the description's Args section compensates fully by explaining every parameter, including required conditions and an example rdata structure. This adds significant meaning 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 the tool manages RPZ rules, defined as the individual DNS override entries within an RPZ zone. It also distinguishes from manage_dns_zone by explicitly directing zone lifecycle operations elsewhere, making the 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?

The description explicitly states when to use this tool instead of manage_dns_zone for RPZ zone lifecycle. The examples also illustrate various actions (list, get, create, update, delete) and parameter combinations, providing clear usage context. The dry_run guidance for delete adds important when-to-use detail.

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?

Beyond destructiveHint, the description discloses the dry_run default for delete, read-only policy access, named_list add/remove semantics (without full replacement), and category filter full-replace behavior. These details are crucial for safe invocation and are not present in 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 well-structured with clear sections (overview, usage notes, args, returns, examples). Every sentence adds operational value; the examples illustrate complex combinations without 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?

Given the tool's complexity (8 resource types, 7 actions, 13 parameters), the description comprehensively covers all resource types, action constraints, parameter semantics, and dry_run behavior. It also points to sibling tools for adjacent use cases, making selection and invocation unambiguous.

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 13 parameters are meaningfully explained in the Args section, including action-specific meanings (e.g., items for add_items vs remove_items) and dry_run default. Since schema description coverage is 0%, the description fully compensates and provides essential context.

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 'Manage DNS security resources' and enumerates specific resource types (policies, named lists, application filters, etc.). It also distinguishes from siblings by explicitly directing posture assessment and threat investigation to other 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 explicitly says 'USE THIS for security policy CRUD' and names alternatives: assess_security_posture and investigate_threat. It also clarifies when not to use it (e.g., policies are read-only) and specific constraints for category filters.

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?

Discloses key behavioral traits beyond annotations: default dry_run mode, automatic zone discovery, view requirement, and value format expectations for different record types. The description clearly states that setting dry_run=False executes actual creation, which aligns with destructiveHint=false since creation isn't destructive.

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?

Although detailed, the description is well-structured with sections for usage, args, returns, and examples. Every sentence adds value, and the examples clarify usage without 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?

Given the tool's complexity (8 parameters, enum, output schema), the description covers purpose, usage vs alternatives, parameter semantics, dry_run behavior, view caveat, return type, and examples. It is complete even without relying on the output schema for return details.

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?

With 0% schema_description_coverage, the description fully compensates by explaining every parameter: name, record_type, value, zone, view, ttl, dry_run, and comment. It even provides per-record-type value formats and illustrative examples: 'IP for A/AAAA, domain for CNAME/MX/PTR/NS, text for TXT.'

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 begins with 'Create a new DNS record with automatic zone discovery and validation,' clearly stating the verb and resource. It also explicitly distinguishes from sibling tools: 'For update/delete/list use manage_dns_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?

Provides explicit usage guidance: 'USE THIS to create records. For update/delete/list use manage_dns_record().' It also states prerequisites like 'Required when a zone exists in multiple views' and examples showing dry_run behavior.

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?

The description adds significant context beyond annotations. It discloses that dry_run=True by default (shows without creating) and how to execute. It explains the atomicity difference between auto_dns=True (records created atomically) and False (separate steps). This is valuable behavioral insight, especially given the openWorldHint annotation which is vague.

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 longer than average but every part serves a purpose: intro, usage directive, important notes, args, return, and examples. It uses clear section breaks and bullets, making it easy to scan. No redundant 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?

Given the tool's complexity (9 parameters, optional behavior, multiple resources affected), the description is complete. It covers purpose, usage, parameter details, return value, and provides three examples. The output schema exists, so the return description is sufficient. No gaps identified.

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?

With 0% schema description coverage, the description fully compensates by providing an 'Args:' section that explains every parameter, including conditions (e.g., subnet required when multiple subnets exist and no IP specified; view required when zone exists in multiple views). It gives examples and types, making the parameter semantics crystal clear.

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: 'Provision a complete host in one step: creates IPAM host + IP + optional DNS A/PTR records.' It uses a specific verb (provision) and resource (host), and explicitly distinguishes from siblings by directing DNS-only changes to provision_dns() and removal to decommission_host().

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 explicit when-to-use guidance: 'USE THIS when adding a new host to the network.' Names alternatives: 'For DNS-only changes use provision_dns(). To remove a host use decommission_host().' Also explains dry_run default and instructs to ask the user about auto_dns, giving clear decision points.

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?

Annotations already indicate readOnlyHint=true, so the description doesn't need to cover safety. It adds useful behavioral details such as searching across all DDI domains, grouping results by type, and the limit per type. This goes beyond what annotations provide, though it doesn't elaborate on openWorldHint implications or potential rate limits, so 4 is appropriate.

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

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

The description is well-structured with a clear summary line, usage guidance, args list, return description, and examples. Every section adds value and there is no filler. It is front-loaded with the core purpose.

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 search tool with multiple optional parameters and an output schema, the description covers purpose, parameters, return format, and usage examples. It provides enough context for an agent to select and invoke it correctly without needing additional information.

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 has zero descriptions, but the description fully explains each parameter. query is clarified as a search term with examples (IP, hostname, domain, comment). types is described as optional and defaults to all types. limit is given a default and maximum. This fully compensates for the schema's lack of 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: 'Find resources by keyword across all DDI domains' and specifies the types of searchable values (IP, hostname, domain, comment). It distinguishes itself from sibling tools by naming alternatives like explore_network and get_network_summary.

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?

Explicit guidance is provided: 'USE THIS when looking for something specific by name or address.' It also gives direct alternative recommendations: 'For hierarchy browsing use explore_network(). For dashboards use get_network_summary().' This leaves no ambiguity about when to use this tool.

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?

The description adds significant behavior beyond annotations: it explains the dry_run default and that bulk_triage shows what would be updated without executing, discloses that insight_ids auto-populate from priority_filter, and notes that priority_filter fetches matching open insights. This complements the destructiveHint annotation by detailing safety mechanisms.

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

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

The description is well-structured: a one-line summary, usage guidance, a compact Args section, a Returns line, and concrete examples. Every sentence is informative and contributes to understanding the tool, with 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?

Given the tool's complexity (7 parameters, 3 actions, a destructive operation), the description covers all necessary context: parameter semantics, operation behavior, the dry_run safety, and examples for each action. An output schema exists, so the return description is sufficient. No gaps are evident.

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 description compensates for the lack of schema descriptions by giving each parameter a clear semantic meaning, including which actions they apply to (e.g., 'insight_id: Single insight ID (for update_status, get_history)'). It also explains the auto-population logic and dry_run behavior, going beyond the schema's raw definitions.

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: 'Triage security insights: update status, bulk triage by priority, or get comment history.' It lists specific operations and explicitly differentiates from siblings by advising to use this for incident response actions, while pointing to investigate_threat() and assess_security_posture() for other contexts.

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 usage guidance: 'USE THIS for incident response actions.' It also names alternatives: 'For investigation use investigate_threat(). For posture review use assess_security_posture().' This is a clear when-to-use and when-not-to-use statement.

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