MailX Email Deliverability

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

Annotations already indicate read-only, open-world, idempotent, and non-destructive behavior. The description adds value by explaining that BIMI is for displaying logos in emails, which provides context beyond annotations, though it doesn't detail rate limits or specific auth needs.

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 front-loaded with the core purpose in the first sentence, followed by a brief explanation of BIMI. Both sentences are necessary and efficient, 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?

Given the tool's low complexity, single parameter, and rich annotations, the description is mostly complete. However, without an output schema, it could benefit from hinting at return values (e.g., validity status), but the context is sufficient for basic use.

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

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

Schema description coverage is 100%, so the schema fully documents the single parameter 'domain_name'. The description does not add any additional parameter details beyond what the schema provides, meeting the baseline for high coverage.

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

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

The description clearly states the specific action ('Check if a domain has a valid BIMI DNS record') and the resource ('domain'), distinguishing it from siblings like 'dkim_check' or 'spf_check' by specifying BIMI records. It also explains what BIMI is, adding context.

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

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

The description implies usage for verifying BIMI records in email authentication contexts, but does not explicitly state when to use this tool versus alternatives like 'dmarc_check' or 'dkim_check'. It provides clear context but lacks explicit exclusions or named alternatives.

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

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

The description adds valuable behavioral context beyond annotations: it implies this is a hosting/serving operation for BIMI files, which suggests it sets up or configures a service. Annotations provide safety hints (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), but the description clarifies the tool's domain-specific purpose without contradicting them. It doesn't detail aspects like rate limits or authentication needs, but with annotations covering core behavioral traits, this is sufficient for a high score.

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, efficient sentence that front-loads the core purpose ('Host and serve your BIMI SVG file') and adds context ('for email authentication'). Every word contributes meaning without redundancy, making it appropriately sized and 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 moderate complexity (2 parameters, no output schema) and rich annotations (covering safety and idempotency), the description is adequate but incomplete. It explains what the tool does but lacks usage guidelines, output details, or error handling context. With annotations handling behavioral transparency, the description meets minimum viability but has clear gaps in guiding the 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?

The description doesn't explicitly mention or explain the parameters (domain_name and bimi_file). However, with 100% schema description coverage (both parameters are well-documented in the schema), the baseline is 3. The description's focus on the tool's overall purpose doesn't add parameter-specific semantics, but it doesn't need to compensate for schema gaps.

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 as 'Host and serve your BIMI SVG file for email authentication', specifying the verb ('host and serve'), resource ('BIMI SVG file'), and context ('for email authentication'). However, it doesn't explicitly differentiate from sibling tools like 'bimi_check' or other email authentication tools, which would be needed for a score of 5.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a BIMI file ready), exclusions, or comparisons to siblings like 'bimi_check' (which might verify BIMI setup) or other email authentication tools. This leaves the agent with minimal 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 provide key behavioral hints (readOnlyHint: true, destructiveHint: false, etc.), but the description adds valuable context by explaining the impact of blacklisting ('severely impact email deliverability'), which isn't covered by annotations. It doesn't contradict annotations and enhances understanding of the tool's significance.

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

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

The description is two sentences, front-loaded with the core purpose and followed by a brief impact statement. Every word contributes meaning without redundancy, making it highly efficient and easy to parse for an AI agent.

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

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

Given the tool's low complexity (1 parameter, no output schema) and rich annotations covering safety and behavior, the description is mostly complete. It could improve by mentioning what the check returns (e.g., list of blacklists), but the annotations and clear purpose compensate well for this gap.

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

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

The input schema has 100% description coverage, fully documenting the single parameter 'domain_name.' The description doesn't add any parameter-specific details beyond what the schema provides, such as format examples or constraints, so it meets the baseline for high schema coverage without extra value.

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

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

The description clearly states the specific action ('Check if a domain or IP address is listed') and resource ('popular email blacklists (DNSBLs)'), distinguishing it from sibling tools like dns_lookup or txt_lookup which perform different DNS operations. It also explains the purpose ('impact email deliverability'), making the tool's function 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 implies usage context by mentioning 'email deliverability,' suggesting it's for email-related checks, but it doesn't explicitly state when to use this tool versus alternatives like spf_check or dmarc_check, nor does it provide exclusions or prerequisites. This leaves some ambiguity in 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, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds useful context about what the tool returns ('Shows where a hostname aliases to'), which isn't captured in annotations. No contradictions with annotations exist.

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

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

The description is two concise sentences with zero wasted words. The first sentence states the core purpose, and the second adds clarifying semantics. It's front-loaded and efficiently 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 low complexity (single parameter, read-only, no output schema), the description combined with rich annotations (readOnlyHint, openWorldHint, idempotentHint) provides sufficient context for an agent to use it correctly. The description could be more complete by mentioning output format or error cases, but annotations cover key behavioral aspects.

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

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

Schema description coverage is 100%, with the single parameter 'domain_name' fully documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides, such as format constraints or examples, so it meets the baseline for high schema coverage.

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

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

The description clearly states the specific action ('Look up CNAME records') and resource ('for a domain'), with additional semantic clarification ('Shows where a hostname aliases to'). It distinguishes from sibling tools like 'dns_lookup' (general) or 'mx_lookup' (specific record type) by focusing exclusively on CNAME records.

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

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

The description implies usage for DNS CNAME record queries but provides no explicit guidance on when to use this versus alternatives like 'dns_lookup' (which might return multiple record types) or other sibling tools for different DNS records. No exclusions or prerequisites are mentioned.

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 this is a read-only, non-destructive, idempotent, and open-world operation. The description adds useful context by explaining DKIM's purpose ('allows the receiver to verify that an email was sent by the domain owner'), which helps the agent understand the tool's role in email authentication without contradicting 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 front-loaded with the core purpose in the first sentence, followed by a brief explanation of DKIM's function. Both sentences are necessary and contribute to understanding without redundancy or 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 moderate complexity (2 required parameters), rich annotations covering safety and behavior, and no output schema, the description is mostly complete. It could improve by mentioning output format or error handling, but it adequately supports the agent's understanding for a read-only check tool.

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

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

Schema description coverage is 100%, with both parameters clearly documented in the schema. The description does not add any additional parameter details beyond what the schema provides, such as format examples or constraints, so it meets the baseline for high schema coverage.

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

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

The description clearly states the specific action ('Check if a domain has a valid DKIM DNS record'), identifies the resource ('domain'), and distinguishes it from siblings by focusing on DKIM rather than other DNS/email protocols like DMARC, SPF, or blacklist checks mentioned in the sibling list.

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

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

The description implies usage for DKIM verification in email contexts but does not explicitly state when to use this tool versus alternatives like dmarc_check or spf_check from the sibling list. No guidance on prerequisites or exclusions is provided.

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

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

Annotations already indicate readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds value by specifying it checks for 'valid' DMARC records (implying validation beyond mere existence) and mentions DNS-based operation, though it could note rate limits or authentication needs. 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 two sentences, front-loaded with the core purpose and followed by explanatory context. Every sentence earns its place by clarifying the tool's function and DMARC's role, with no redundant or 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's low complexity (single parameter, no output schema), rich annotations (covering safety and behavior), and clear purpose, the description is nearly complete. It could improve by hinting at return values (e.g., validation results) or error cases, but it adequately supports agent usage in context.

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

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

Schema description coverage is 100%, with the parameter 'domain_name' fully documented in the schema. The description does not add any parameter-specific details beyond what the schema provides, such as format constraints or examples, so it meets the baseline for high coverage without extra value.

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

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

The description clearly states the specific action ('Check if a domain has a valid DMARC DNS record') and the resource ('domain'), distinguishing it from siblings like dmarc_generate (which creates records) and other DNS-related tools (e.g., dns_lookup, txt_lookup). It includes the full DMARC acronym expansion, adding precision.

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

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

The description provides clear context by explaining DMARC's purpose ('tells receiving servers what to do with emails that fail SPF or DKIM checks'), which implicitly guides usage for email authentication scenarios. However, it does not explicitly state when to use this tool versus alternatives like spf_check or dkim_check, or when not to use it.

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

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

Annotations indicate readOnlyHint=false (write operation), openWorldHint=true (can generate for any domain), idempotentHint=true (safe to retry), and destructiveHint=false (non-destructive). The description adds value by specifying that it 'Returns the record name, value, and type ready to be added to DNS,' clarifying the output format and that it's a generation tool (not a DNS update tool), which aligns with and complements 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 a single, well-structured sentence that front-loads the core action ('Generate a DMARC DNS record for a domain') and efficiently adds output details. Every word serves a purpose, with no redundancy or unnecessary elaboration, making it highly concise and effective.

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 (generating DNS records), rich annotations (covering safety and idempotency), and full parameter schema coverage, the description is largely complete. It specifies the output format, which is helpful since there's no output schema. However, it could slightly improve by mentioning typical use cases or prerequisites (e.g., domain ownership), but it's adequate for the context.

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

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

The input schema has 100% description coverage, with clear documentation for all three parameters (domain_name, email, dmarc_policy), including enum values for dmarc_policy. The description does not add any additional parameter details beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without compensating further.

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 specific action ('Generate a DMARC DNS record') and resource ('for a domain'), distinguishing it from sibling tools like dmarc_check (which verifies rather than creates) and spf_generate (which generates a different type of DNS record). The description explicitly mentions what the tool produces, 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?

The description provides clear context for when to use this tool: when you need to create a DMARC DNS record for a domain. However, it does not explicitly state when not to use it (e.g., for checking existing records, which dmarc_check handles) or name specific alternatives, though the sibling list implies alternatives like spf_generate for different record types.

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 cover key behavioral traits (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true), so the description adds value by specifying the scope ('all DNS records') and listing the exact record types returned. It does not contradict annotations, but it also does not disclose additional traits like rate limits or error handling.

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 front-loaded with the core purpose in the first sentence and adds necessary detail in the second. Both sentences earn their place by clarifying scope and output, with zero wasted words, making it highly efficient and 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 low complexity (1 parameter, no output schema) and rich annotations, the description is mostly complete. It specifies the comprehensive record types returned, which compensates for the lack of output schema. However, it could briefly mention typical use cases or limitations to enhance context further.

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

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

Schema description coverage is 100%, with the parameter 'domain_name' fully documented in the schema. The description does not add meaning beyond what the schema provides, such as format examples or constraints, so it meets the baseline of 3 without compensating for any gaps.

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 specific action ('look up all DNS records') and resource ('for a domain'), distinguishing it from siblings like mx_lookup or txt_lookup that query specific record types. It explicitly lists the comprehensive set of record types returned (A, AAAA, CNAME, MX, NS, TXT, SOA), making the scope 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 implies usage context by specifying 'all DNS records in one query,' suggesting this tool is for comprehensive lookups rather than targeted ones. However, it does not explicitly state when to use alternatives like mx_lookup for MX records only or provide exclusions, leaving some ambiguity in sibling 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?

The description adds context beyond annotations by specifying that it 'attempts to connect and authenticate,' which implies network interaction and authentication behavior. Annotations already cover safety (readOnlyHint: true, destructiveHint: false) and idempotency, so the bar is lower. The description doesn't contradict annotations and provides useful operational context, though it could mention potential outcomes like success/failure states or error handling.

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 front-loaded with the core purpose in the first sentence and usage guidance in the second, with zero wasted words. It's appropriately sized for a straightforward tool, making it easy for an AI agent to parse quickly without unnecessary detail.

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

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

Given the tool's moderate complexity (network testing with authentication), annotations provide good safety and idempotency info, and schema coverage is complete. The description adds purpose and usage context effectively. Without an output schema, it doesn't explain return values, but for a test tool, the implied boolean-like outcome is reasonable. It could be more complete by hinting at output format or error cases.

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

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

Schema description coverage is 100%, with all parameters well-documented in the schema (e.g., imap_host, imap_port with examples). The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3. It implies the tool uses these parameters for connection testing but doesn't elaborate on their semantics further.

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 specific action ('Test an IMAP server connection by attempting to connect and authenticate') and the resource ('IMAP server'), distinguishing it from sibling tools like 'imap_finder' or 'smtp_check' which have different purposes. It explicitly mentions verifying email receiving configuration, which adds context about the use case.

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

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

The description provides explicit guidance on when to use this tool: 'Use this to verify email receiving configuration.' This clearly indicates its primary use case for testing and validation, distinguishing it from alternatives like 'imap_finder' (which likely discovers IMAP servers) or other email-related tools in the sibling list.

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 this is a read-only, non-destructive, idempotent, and open-world operation. The description adds useful context by specifying what is looked up (server settings like host, port, encryption) and the types of providers supported, which goes beyond the annotations. However, it does not mention potential limitations such as rate limits, authentication needs, or data freshness, leaving some behavioral aspects uncovered.

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 front-loaded with the core purpose in the first sentence and uses a second sentence to provide usage context, with no wasted words. It is appropriately sized for a simple lookup tool, making every sentence earn its place by adding clarity and guidance efficiently.

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

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

Given the tool's low complexity (single parameter, no output schema) and rich annotations (read-only, non-destructive, etc.), the description is mostly complete. It covers the purpose and usage well, but lacks details on output format or potential errors, which could be helpful since there is no output schema. However, for a straightforward lookup tool, this is a minor gap.

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

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

The input schema has 100% description coverage, with the single parameter 'imap_provider_name' clearly documented in the schema. The description adds minimal value by providing examples of provider names (e.g., Gmail, Outlook, Yahoo), but does not elaborate on parameter semantics beyond what the schema already states. This meets the baseline score of 3 for high schema coverage.

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

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

The description clearly states the specific action ('look up IMAP server settings') and resource ('for a given email provider'), with explicit examples of what settings are retrieved (host, port, encryption) and which providers are supported (Gmail, Outlook, Yahoo). It distinguishes this tool from siblings like 'imap_check' (which likely tests connectivity) and 'smtp_finder' (which finds SMTP settings).

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

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

The description provides clear context for when to use this tool ('to find the correct IMAP configuration for services like Gmail, Outlook, Yahoo, etc.'), but does not explicitly state when not to use it or name specific alternatives. It implies usage for configuration lookup rather than testing or other email-related operations, though it lacks explicit exclusions or comparisons to siblings like 'imap_check'.

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, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds that it 'returns the mail servers and their priorities', which provides useful output context beyond annotations, but doesn't detail rate limits, auth needs, or error behaviors.

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

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

The description is two concise sentences with zero waste: the first states the purpose, and the second specifies the return value. It's front-loaded and appropriately sized for a simple lookup tool.

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

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

Given the tool's low complexity (single parameter, no output schema) and rich annotations, the description is mostly complete. It clarifies the return content, but could better address usage context relative to siblings. The lack of output schema is mitigated by the description mentioning return values.

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

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

Schema description coverage is 100%, with the parameter 'domain_name' fully documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides, so it meets the baseline for high schema coverage without compensating value.

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

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

The description clearly states the verb ('Look up') and resource ('MX records for a domain'), specifying it returns mail servers and their priorities. It distinguishes from siblings like dns_lookup or txt_lookup by focusing exclusively on MX records.

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

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

The description provides no guidance on when to use this tool versus alternatives like dns_lookup (which might include MX records) or other DNS-related tools. It lacks explicit when/when-not instructions or named alternatives, leaving usage context implied at best.

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 provide readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering safety and idempotence. The description adds valuable context about PTR records being 'important for email sending reputation' which helps the agent understand the real-world significance beyond the technical operation.

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

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

Two concise sentences that are front-loaded with the core functionality followed by important context about PTR record significance. Every word earns its place with zero redundancy or 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?

For a simple lookup tool with excellent annotations (read-only, non-destructive, idempotent) and 100% schema coverage, the description provides sufficient context about what the tool does and why it matters. The main gap is the lack of output format information since there's no output schema, but the annotations mitigate risk.

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

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

Schema description coverage is 100% with a well-documented ip_address parameter including examples. The description doesn't add any parameter-specific information beyond what's in the schema, but the schema documentation is comprehensive enough to warrant the baseline score of 3.

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

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

The description clearly states the specific action ('reverse DNS lookup') and resource ('find the hostname associated with an IP address'), distinguishing it from sibling tools like DNS lookup or MX lookup that perform different DNS operations. The additional context about PTR records and email reputation further clarifies the domain-specific purpose.

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

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

The description implies usage for IP-to-hostname resolution and mentions email reputation as a use case, but doesn't explicitly state when to use this versus alternatives like general DNS lookup or when not to use it. No sibling tool comparisons or exclusion criteria are provided.

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

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

Annotations already provide hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), indicating a safe, repeatable operation. The description adds valuable context beyond annotations by specifying that it 'attempts to connect and authenticate' and 'sends a test email to verify full sending capability,' which clarifies the tool's behavior and scope. No contradiction with annotations exists.

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 front-loaded with the core purpose in the first sentence and adds optional functionality in the second. Both sentences are essential, with zero wasted words, making it efficient and easy to understand.

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 (7 parameters, no output schema), the description is reasonably complete. It covers the main action and optional test email, and annotations provide safety and behavioral hints. However, without an output schema, it could benefit from mentioning what the tool returns (e.g., connection status, test email result), though this is not required for a high score.

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

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

Schema description coverage is 100%, with all parameters well-documented in the schema (e.g., host, port, encryption with enum values). The description adds minimal semantic value beyond the schema, mentioning 'optionally sends a test email' which hints at the optional to_email and from_email parameters but does not provide additional details. Baseline score of 3 is appropriate given high schema coverage.

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

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

The description clearly states the specific action ('Test an SMTP server connection by attempting to connect and authenticate') and resource ('SMTP server'), distinguishing it from sibling tools like smtp_finder (which likely finds SMTP servers) or other email-related checks (e.g., dkim_check, spf_check). It explicitly mentions the optional test email capability, which adds specificity.

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

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

The description implies usage for testing SMTP connections and optionally sending test emails, but does not explicitly state when to use this tool versus alternatives like smtp_finder or other email verification tools. It provides some context (e.g., 'to verify full sending capability') but lacks explicit exclusions or comparisons to sibling tools.

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

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

Annotations already indicate this is a read-only, non-destructive, idempotent, and open-world operation. The description adds context about what is returned (SMTP settings like host, port, encryption) and implies a lookup based on provider names, which is useful but doesn't detail behavioral traits like rate limits, error handling, or data sources beyond what annotations cover.

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 front-loaded with the core purpose in the first sentence and uses a second sentence to clarify usage with examples. Both sentences are essential, with no wasted words, making it highly efficient and easy to parse.

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

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

Given the tool's low complexity (1 parameter, 100% schema coverage, no output schema), the description is reasonably complete. It covers purpose, usage, and output details (SMTP settings), but lacks information on return format or potential limitations (e.g., supported providers). With annotations handling safety and idempotency, it's mostly adequate.

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

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

Schema description coverage is 100%, with the single parameter 'provider_name' fully documented in the schema. The description adds minimal semantics by listing example providers (Gmail, Outlook, SendGrid) and specifying the purpose ('to look up SMTP server settings'), but does not provide additional details beyond what the schema already states.

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 specific action ('look up SMTP server settings') and resource ('for a given email provider'), distinguishing it from sibling tools like smtp_check (which likely tests SMTP connections) or dns_lookup (which handles general DNS queries). It explicitly lists the configuration details returned (host, port, encryption).

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

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

The description provides clear context for when to use this tool ('to find the correct SMTP configuration for services like Gmail, Outlook, SendGrid, etc.'), but does not explicitly state when not to use it or name alternatives (e.g., imap_finder for IMAP settings). The examples help guide usage without being exhaustive.

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 cover key behavioral traits (read-only, open-world, idempotent, non-destructive), so the bar is lower. The description adds context about what SPF is and its purpose (authorizing mail servers), which is useful but does not disclose additional behavioral details like rate limits, error handling, or output format. It does not contradict 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 two sentences, front-loaded with the core purpose and followed by explanatory context about SPF. Every sentence earns its place by clarifying the tool's function and the technology involved, with no wasted words 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 low complexity (single parameter, no output schema) and rich annotations, the description is mostly complete. It explains what SPF is and the tool's purpose, but lacks details on output (e.g., what 'valid' means, return format) or error cases, which could be helpful despite the absence of an output schema.

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

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

Schema description coverage is 100%, with the parameter 'domain_name' fully documented in the schema. The description does not add any parameter-specific information beyond what the schema provides (e.g., format examples or validation rules), so it meets the baseline of 3 for high schema coverage without extra value.

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

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

The description clearly states the specific action ('Check if a domain has a valid SPF DNS record') and resource ('domain'), and distinguishes it from siblings like 'spf_generate' (which creates SPF records) and 'txt_lookup' (which is a general DNS lookup). It provides the full expansion of SPF and its purpose, 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 implies usage for verifying SPF records, which is clear in context with sibling tools like 'spf_generate' and 'dkim_check'. However, it does not explicitly state when to use this tool versus alternatives (e.g., 'txt_lookup' for general TXT records or 'dns_lookup' for broader DNS queries), nor does it mention exclusions or prerequisites, leaving some guidance gaps.

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 cover key behavioral traits (readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=false), but the description adds valuable context by specifying the output format ('record name, value, and type ready to be added to DNS'), which helps the agent understand the tool's practical application. 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 a single, well-structured sentence that efficiently conveys the tool's purpose, input basis, and output format without unnecessary details. It is front-loaded with the core action and avoids redundancy, making every word count.

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 parameters, no output schema) and rich annotations, the description provides sufficient context for an agent to understand its function and output. However, it lacks details on error conditions or example outputs, which could enhance completeness for a generation 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 100% schema description coverage, the input schema fully documents all three parameters (provider, domain_name, hard_fail_boolean). The description does not add any parameter-specific semantics beyond what the schema provides, such as examples or edge cases, so it meets the baseline for high schema coverage.

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

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

The description clearly states the specific action ('Generate an SPF DNS record'), target resource ('for a domain'), and purpose ('based on the email provider being used'), distinguishing it from sibling tools like spf_check or dmarc_generate. It explicitly mentions the output format ('record name, value, and type'), which further clarifies its unique function.

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

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

The description implies usage context ('for a domain based on the email provider') but does not explicitly state when to use this tool versus alternatives like spf_check or dmarc_generate. It provides no guidance on prerequisites, exclusions, or comparative scenarios with sibling tools, leaving usage decisions to inference.

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 this is a read-only, non-destructive, idempotent, and open-world operation. The description adds value by specifying that it retrieves 'all TXT records' and lists common content types (SPF, DKIM, etc.), which helps the agent understand the scope and typical use cases beyond the safety profile covered by 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 two concise sentences: the first states the core purpose, and the second adds helpful context about TXT record contents. Every word earns its place, and the information is front-loaded 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 lookup tool with rich annotations (read-only, non-destructive, etc.) and a fully described single parameter, the description provides adequate context by explaining what TXT records are used for. However, without an output schema, it could benefit from mentioning the return format (e.g., list of strings), though the annotations and purpose clarity partially compensate.

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, fully documenting the single required parameter 'domain_name' with an example. The description does not add any parameter-specific information beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without compensating value.

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

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

The description clearly states the specific action ('look up all TXT records') and resource ('for a domain'), distinguishing it from sibling tools like cname_lookup or mx_lookup by specifying the DNS record type. It also elaborates on what TXT records typically contain, providing additional context.

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

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

The description implies usage for retrieving TXT records with examples of content (SPF policies, verification tokens), but does not explicitly state when to use this tool versus alternatives like dns_lookup (which might return all record types) or spf_check (which might analyze SPF specifically). No exclusions or prerequisites are mentioned.

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