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

With no annotations, the description fully discloses behavior: it is read-only, requires no API key, and is rate-limited. It lists the return fields but does not mention error handling (e.g., if query is invalid or not found), which would improve 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 concise and well-structured: purpose first, then usage guidance, then constraints and return fields. No redundant or unnecessary 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?

Given there is no output schema, the description sufficiently lists the return fields (operator, prefixes, classification, abuse contact) and constraints (read-only, rate-limited, no API key). It covers all essential context for a simple lookup tool with good sibling differentiation.

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 single parameter 'query' is already well-described in the schema. The description restates the same information (IP address or AS number format) without adding new semantic 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 uses the specific verb 'Look up' and clearly identifies the resource (Autonomous System / BGP information) and the returned data (operator, prefixes, classification, abuse contact). It explicitly distinguishes from the sibling 'reverse_dns' by stating when to use that instead.

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 context for when to use the tool ('identify who runs a network or whether an IP is cloud/CDN-hosted') and when not to (use reverse_dns for host-level PTR). It also notes that it is read-only, requires no API key, and is rate-limited.

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 'Read-only; requires no API key or authentication; subject to rate limiting' and describes the return format (text report with status, KPI, issues, actions). This provides good behavioral context, though specific rate limits or error handling are not mentioned.

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 concise (three sentences) and well-structured: first sentence states purpose and capabilities, second provides usage guidance, third covers behavioral traits and return format. Every sentence adds essential 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?

The tool has one parameter and no output schema, but the description sufficiently explains that it returns a text report with status, KPI, issues, and actions. It covers the main behavioral aspects (read-only, no auth, rate limiting). However, it does not describe error handling or what happens for invalid domains.

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 'domain' parameter. The description adds value by explaining what the tool does with the domain (querying specific record types and validating email records), which enriches the parameter meaning beyond the schema alone.

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 that the tool queries DNS records (A, AAAA, MX, TXT, NS, SOA, CAA) and validates email-related records, including DNSSEC and SPF/DMARC. It distinguishes itself from sibling tools like dns_propagation and email_auth by stating its unique 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?

Provides explicit guidance: 'Use this for a single authoritative answer about one domain. Use dns_propagation instead when you need to compare answers across multiple global resolvers... or email_auth for a full SPF/DKIM/DMARC deliverability assessment.' This clearly tells the agent when to choose this tool over 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 fully covers behavioral traits. It discloses that the tool is read-only, requires no API key, is rate-limited, queries across 8+ resolvers, and returns per-resolver values and a consistency verdict. These details exceed what an agent would infer from the schema alone and provide a clear operational picture.

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 long, front-loading the core functionality in the first sentence and adding usage guidance and sibling differentiation in the second. Every sentence serves a purpose with 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?

Despite having no output schema, the description implies the return structure (per-resolver values and a consistency verdict). It also covers rate limiting, authentication, and appropriate use cases. Given the moderate complexity (2 parameters, 1 required), the description provides enough contextual detail for an agent to understand, invoke, and interpret results 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 has 100% description coverage for both parameters (domain and type), so the baseline is 3. The tool description adds value by noting that the default type 'A' is 'the most common propagation check,' providing context beyond the schema description. This extra semantic guidance justifies a score above 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 it queries one DNS record across 8+ global resolvers and reports stale vs updated values. It uses a specific verb ('Query') and resource ('DNS record'), and distinguishes itself from the sibling tool dns_lookup by noting its focus on propagation confirmation rather than authoritative answers with SPF/DMARC validation.

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: 'Use this after changing a record to confirm worldwide propagation.' It also contrasts with the sibling dns_lookup, saying 'Use dns_lookup instead for a single authoritative answer with SPF/DMARC validation,' and mentions the tool is read-only, requires no API key, and is rate-limited.

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 read-only nature, no API key requirement, rate-limiting, and output format: 'Returns a text report: score, per-mechanism KPIs, issues, and actions.' No annotations provided, so description carries full burden and does so thoroughly.

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?

Description is a single paragraph but efficiently structured: front-loads purpose, then lists mechanisms, usage guidance, alternatives, and limitations. Slightly lengthy but each sentence adds value; no 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 complexity (multiple checks, scoring) and no output schema, description explains return value in detail: '0-100 deliverability score... text report: score, per-mechanism KPIs, issues, and actions.' Covers all necessary context for an AI agent to understand behavior.

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 parameter 'domain'. Description adds meaning beyond schema: specifies format (part after '@'), example, and accepts IP for reverse/PTR checks. This clarifies usage beyond simple schema definition.

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 its purpose: 'Assess a domain's email authentication and deliverability posture' and lists specific mechanisms (MX, SPF, DMARC, etc.). It distinguishes from siblings like dns_lookup and email_header_analysis by specifying focus and 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?

Explicit usage guidance: 'Use this for a full sending/receiving readiness review of a domain.' Also provides when-not and alternatives: 'Use dns_lookup instead if you only need raw TXT/MX records, or email_header_analysis to diagnose a specific message that was already sent.'

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 fully covers behavior: read-only, no API key required, rate-limited, and details the input format and output contents, ensuring the agent understands side effects and constraints.

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 concise, front-loaded with the core action, and every sentence adds value. It covers purpose, usage, and key details 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 and absence of output schema, the description adequately specifies all major outputs (hop route, auth results, delays, encryption) and covers input format, rate limits, and use cases, making it complete for agent understanding.

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% and already provides detailed instructions for the 'headers' parameter. The main description only reiterates 'INPUT is the full raw header block' without adding new semantic value 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 the tool parses raw email headers to reconstruct the delivery path, extract authentication results, measure delays, and flag unencrypted hops. It distinguishes itself from the sibling email_auth by specifying different use cases.

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 (diagnose a specific delivered message) and when not to (use email_auth for domain configuration assessment), providing clear context and 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 provided, so description fully carries burden. Clearly states read-only nature (GET-style probe, no payload), no API key requirement, rate-limiting, and return type (text report with grade, issues, actions).

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?

Concise, front-loaded with core action, then details, then alternatives. Every sentence adds value 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?

Despite no output schema, the description thoroughly covers return content (grade, header findings, redirect trace, issues, actions). Given low parameter count (1) and complexity of security audit, description is 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% for the single param 'url'. Description adds value by noting scheme default (https) and redirect behavior, going beyond schema. Baseline 3, plus extra context makes 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?

Description explicitly states it follows HTTP redirects and audits security headers, grading A+ to F. Clearly distinguishes from sibling tools by naming alternatives (ssl_check, security_scan).

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 context (HTTP-layer/header posture) and when-not-to-use alternatives (ssl_check for TLS, security_scan for full 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?

With no annotations provided, the description carries the full burden and delivers thoroughly. It discloses that the tool reflects the MCP server's egress IP (not the end user's), states it is read-only, requires no API key, and is rate-limited. All critical behavioral traits are explicitly covered.

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 long, front-loads the key information, and every sentence adds value. No unnecessary words or repetition. 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?

Given no output schema, the description fully compensates by listing all types of returned information (address, ISP, ASN, geolocation, heuristics). It also covers scope (server's IP vs user's IP), safety (read-only), authentication (no key), and limits (rate-limited). For a zero-parameter tool, this is complete and leaves no gaps.

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%. The description explains it takes no input, which adds value by confirming the tool is input-free. Baseline 4 is appropriate since there is nothing to add beyond that.

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 reports information about the caller's own public IP, listing specific data points (IPv4/IPv6, ISP, ASN, geolocation, proxy/VPN heuristics). It distinguishes from siblings like asn_lookup by noting that ip_info reflects the server's egress IP, not a specific known IP.

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 (discover server's outbound IP, test connectivity) and when not (to inspect a specific known IP). It names two alternative tools (asn_lookup, reverse_dns) for the latter case. Provides clear decision guidance.

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

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

No annotations are provided, so the description fully carries the behavioral disclosure burden. It explains the tool makes active TCP connections, is non-intrusive (connect probe only, no authentication/exploits/data transfer), is read-only but visible in target logs. It also notes rate limiting and lack of API key requirements, providing complete 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 efficiently structured, starting with the core action, then behavioral notes, usage guidelines, and constraints. Every sentence adds unique value without redundancy, and it is appropriately sized 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?

Despite no output schema, the description explains return type (per-port open/closed list with service names). It covers input, behavior, constraints (authorization, visibility in logs), and rate limits. All necessary context for an agent to select and invoke the tool correctly is present.

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 only one parameter and 100% schema description coverage, the baseline is 3. The description adds value by clarifying the host parameter can accept a 'host:port' form to hint a specific port and emphasizes authorization, but the schema already describes the parameter well.

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 probes a host for common TCP ports and reports open ports, service names, and response times. It uses specific verbs like 'probe' and 'report', and distinguishes from siblings by naming ssl_check and http_security as alternatives for specific service configuration assessment.

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 ('confirm which services are exposed') and when not to ('use ssl_check or http_security instead'). It also includes authorization requirements and rate limits, guiding appropriate 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?

Despite no annotations, the description discloses key traits: read-only, no API key, rate-limited, and the return values (PTR hostname, FCrDNS pass/fail, provider guess). Lacks details on error scenarios or edge cases, but sufficient for most use cases.

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?

Single, well-structured paragraph. Front-loaded with the main action, then details, usage guidance, and notes. Every sentence serves a purpose 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 simple single-parameter tool without output schema, the description fully covers functionality, usage context, return values, and sibling differentiation. 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?

Schema coverage is 100% with a descriptive parameter comment. The description adds the constraint 'Must be an IP, not a hostname', which goes beyond the schema and prevents misuse.

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 resolves PTR records and verifies FCrDNS, with a specific verb ('resolve') and resource ('PTR record'). It distinguishes itself from the sibling tool 'asn_lookup' by specifying when to use each.

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 provides use cases ('validate mail-server rDNS or identify a single IP's host') and alternatives ('Use asn_lookup instead for network/BGP ownership'). Also notes read-only nature, no API key requirement, and rate limiting.

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 provided, but description fully covers behavior: includes active port scan (authorization needed), read-only otherwise, no API key, rate-limited, and what it returns (score, breakdown, actions, summaries).

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 concise and front-loaded; every sentence adds value. It is appropriately sized for the complexity of the 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?

Despite no output schema, the description explains what is returned (score, per-area breakdown, top actions, summaries). Given the single parameter, the description is complete and leaves no ambiguity.

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 is only one parameter (domain) with 100% schema description coverage. The tool description repeats the information from the schema, adding no new meaning beyond what the schema already 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 states the tool performs a one-shot comprehensive audit of a domain with multiple specific checks (DNS, SSL, etc.) and computes a health score and grade. It clearly distinguishes from sibling tools by naming alternatives for depth.

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 to use as default starting point and advises to call individual tools for depth on one area. Gives when to use and when not to use, with alternatives.

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

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

With no annotations provided, the description fully covers behavioral traits: it states it is read-only, completes a TLS handshake but sends no application data, requires no API key, and is rate-limited. It also discloses the grading weights (40% certificate validity, etc.) and what the return report contains.

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 concise at about five sentences, all directly contributing to understanding the tool. It starts with the main purpose and includes usage guidance, behavioral transparency, and return format. 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?

Given the tool has only 2 simple parameters, no output schema, and no annotations, the description is complete. It explains the input (host, port), the process (TLS handshake, grading), the output (text report with grade, KPIs, issues, actions), and the constraints (read-only, no API key, rate-limited). No 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?

Schema coverage is 100% and both parameters have descriptions. The tool description adds value by clarifying the port default (443) and advising to change only for non-standard ports, which is helpful beyond the schema. It does not add much additional semantics for the host parameter but the schema already covers 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 tool inspects a host's TLS/SSL certificate and connection, providing a detailed report including grade. It explicitly distinguishes itself from sibling tools 'http_security' and 'security_scan', making its unique purpose clear.

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 diagnose certificate or HTTPS-handshake problems for one host' and provides direct alternatives: 'Use http_security instead to audit response security headers, or security_scan for an all-in-one domain report.' This provides 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?

Description fully discloses local computation, no network calls, handling of /31 and /32 per RFC 3021, and that it requires no API key and is not rate-limited. No annotations provided, so description carries full burden and meets it thoroughly.

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 paragraph of 4 sentences, front-loads the main action, and covers all necessary details without redundancy. 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 (1 param, no output schema), the description is complete: it explains the computation, special cases, return fields, and constraints. It compensates for the lack of output schema by describing results.

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 single parameter 'cidr' has full schema coverage (100%) with a clear description. The tool description adds context about IPv4 only and special cases but does not significantly augment schema semantics. 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 clearly states the tool computes IPv4 subnet details from CIDR notation locally, listing specific outputs like network/broadcast addresses and usable host range. It distinguishes from sibling tools (e.g., dns_lookup, ip_info) by emphasizing it's purely computational with no network call.

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 'Use this for IPv4 address planning' and notes it does not query DNS or contact any host. Also mentions no API key needed and not rate-limited, guiding when to choose this over network-dependent 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?

Description discloses read-only nature, no API key required, rate-limiting, and fallback behavior. Since no annotations exist, description fully bears the burden and does so effectively. No contradictions.

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 concise: two sentences front-loaded with the main action and return fields. Each sentence adds value—purpose, data returned, risk highlights, usage guidance, alternatives, and behavioral notes. 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?

Given a single parameter, no output schema, and no annotations, the description covers purpose, usage, output details, alternatives, and behavioral notes. It is complete for an 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?

Schema coverage is 100% for the single parameter 'domain'. The description adds critical context: 'A subdomain is normalized to its registrable domain', which is beyond the schema description. This aids correct 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 retrieves domain registration data via RDAP with WHOIS fallback, listing specific data fields (registrar, dates, nameservers, EPP status flags) and risk states. It distinguishes itself from siblings dns_lookup, reverse_dns, and asn_lookup.

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: use for ownership, lifecycle, and expiry questions. Alternatives are named: dns_lookup for live DNS, reverse_dns/asn_lookup for IP-level ownership. This clarifies when to use this tool versus siblings.

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