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

With no annotations provided, the description carries the burden of behavioral disclosure. It accurately conveys the core redirection behavior and a precondition, but it does not disclose side effects, error handling, rate limits, or any return value details. This is adequate but not comprehensive for a mutation tool.

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

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

The description is exactly two sentences, front-loads the primary action, and includes a necessary constraint. There is no redundant wording or filler.

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

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

For a simple create tool with fully documented parameters and no output schema, the description covers the essential purpose and a key prerequisite. However, it lacks guidance on when to use it versus siblings, and does not mention typical response or error scenarios. It is complete enough but leaves minor 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?

Schema description coverage is 100%, so the schema fully documents all three parameters. The description adds meaning by explaining the overall purpose (redirecting email) and the domain prerequisite, but it does not elaborate on parameter-specific syntax or constraints beyond what the schema already provides. 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's function: 'Create an alias that redirects incoming email to one or more target addresses.' This is a specific verb-resource-action pairing that distinguishes it from sibling tools like get_alias, update_alias, and delete_alias.

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 creating a new alias but does not explicitly mention when to avoid this tool or suggest alternatives (e.g., update_alias for modifications). It does provide a key prerequisite ('the domain part of the alias address must already exist'), which is helpful context but not full usage differentiation.

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

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

With no annotations provided, the description must carry the behavioral burden. It explains the verification process and notes that limits are plan-dependent, but does not mention potential failure modes, rate limits, or side effects. This is adequate but not exhaustive.

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. Every clause adds value: the first sentence defines the action, the second details verification options and a plan caveat. 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 complexity (7 parameters) and lack of output schema, the description covers the key operational aspects: domain addition, verification flows, and plan-dependent limits. It references relevant sibling tools for TXT records, making it complete for an AI agent, though it omits details on return values or error handling.

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%, setting a baseline of 3. The description adds meaningful context beyond the schema by explaining the default verification method ('mx') and the prerequisite for 'txt' verification via get_domain_dns_record. This enhances parameter understanding.

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

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

The description clearly states the action: 'Add a domain to the postale.io account.' The verb 'Add' plus the resource 'domain' makes the tool's purpose unambiguous. It also distinguishes itself from sibling tools by focusing solely on domain creation, with details on verification methods.

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 guidance on when to use each verification method, including a prerequisite instruction to call get_domain_dns_record for TXT verification. It does not explicitly mention when not to use the tool or compare it to alternative tools like update_domain, but the context is solid.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It does explain that domainAdmin and fullAdmin grant specific administrative powers, and that the domain must pre-exist. However, it does not disclose other behavioral traits such as permission requirements, duplicate address behavior, reversibility, or rate limits, leaving significant gaps for a mutation tool.

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

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

The description is exactly two sentences, front-loaded with the core action ('Create a mailbox') and immediately followed by essential contextual detail. There is no fluff or repetition, and every sentence earns its place.

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

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

For a create operation with a 100% schema coverage, the description covers the main purpose, the critical prerequisite, and the two optional admin flags. It is missing some behavioral context (e.g., password requirements, response, error handling), but given the schema's richness and no nested objects, it is reasonably complete. A higher score would require disclosure of side effects or return convention.

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

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

The schema already describes all parameters clearly (100% coverage), giving a baseline of 3. The description adds value by explaining the meaning of domainAdmin and fullAdmin in terms of account/domain administration, and by tying the 'address' parameter to the prerequisite that its domain must exist. This goes beyond the schema's simple field labels.

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

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

The description opens with 'Create a mailbox', a specific verb and resource that clearly distinguishes it from sibling tools like list/get/update/delete_mailbox. It adds a key scoping detail (domain must exist) that clarifies the tool's exact purpose beyond the name.

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

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

The description gives a clear prerequisite for usage: the domain part of the address must already exist. It also explains the effect of the admin role flags, which helps an agent decide when to set them. However, it does not explicitly mention alternatives (e.g., create_alias) or scenarios when not to use this tool.

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

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

With no annotations provided, the description carries the burden. It discloses the post-deletion behavior (bounce) and the confirmation requirement, which is critical for a destructive operation. It doesn't mention permissions or reversibility, but the schema's confirm parameter already indicates irreversibility.

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 action, and every word adds value. It is appropriately concise.

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

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

For a simple two-parameter delete tool with full schema coverage and no output schema, the description provides essential behavioral context (bounce effect) and safety requirement. It is complete for this tool's complexity.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds no new parameter details beyond restating the confirm requirement, so a baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Delete') and resource ('alias'), and adds a clear consequence ('Email sent to it will bounce afterwards'). This clearly distinguishes it from sibling tools like get_alias or update_alias.

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: to permanently remove an alias. It provides context that emails will bounce, and requires confirm=true as a safeguard. It does not explicitly name alternative tools or exclusions, but the context is clear enough for a deletion operation.

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 full responsibility. It explicitly discloses permanence ('PERMANENTLY', 'cannot be undone'), cascading deletion of mailboxes and stored emails, and the need for confirmation. This is fully transparent for a destructive operation.

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

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

Two sentences, front-loaded with the critical warning ('PERMANENTLY delete'), and every phrase contributes meaning. There is no redundant or filler content, making it highly concise 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?

Despite lacking an output schema and annotations, the description thoroughly covers all critical aspects for a destructive tool: exactly what gets deleted, irreversibility, and the confirmation requirement. For a two-parameter tool, this is comprehensive and sufficient.

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

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

The input schema already has 100% description coverage for both parameters ('name' and 'confirm'), including a clear explanation of the confirm constraint. The description reinforces 'Requires confirm=true' but does not add additional meaning beyond what the schema already provides, so the baseline 3 is appropriate.

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

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

The description uses a specific verb ('delete'), resource ('domain'), and scope ('ALL of its mailboxes, including every stored email'), clearly distinguishing it from sibling tools like delete_mailbox or delete_alias. It leaves no ambiguity about what the tool does.

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

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

The description clearly indicates the use case: permanently removing an entire domain and all associated mailboxes/emails. It also states the confirm=true requirement. However, it does not explicitly name alternatives or when not to use it (e.g., 'use delete_mailbox for single mailbox deletion'), so it falls short of a 5.

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

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

With no annotations provided, the description carries the burden of disclosing behavioral impact. It does state the key consequence (outgoing email no longer DKIM-signed) and emphasizes the need for confirm=true. While it doesn't explicitly say 'irreversible', the schema's confirm parameter covers that, and the description adds meaningful context beyond simple deletion.

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, tightly packed with relevant information: the action, the consequence, and the confirmation requirement. No wasted words or redundancy. Front-loaded with the core purpose.

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

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

For a simple 2-parameter tool with no output schema and no annotations, the description sufficiently covers purpose, effect, and required confirmation. The schema provides parameter details, and the description gives enough context for an agent to invoke the tool correctly.

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

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

Schema description coverage is 100% for both parameters (name and confirm), so the baseline is 3. The description reiterates that confirm=true is required, but this adds no new information beyond what the schema already states. It doesn't enhance parameter understanding.

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

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

The description uses a specific verb ('Remove') and clearly identifies the resource ('DKIM keys of a domain'). It distinguishes this from sibling tools like generate_domain_dkim or set_domain_dkim, making the tool's purpose unambiguous.

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

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

The description provides a clear context by stating that outgoing email will no longer be DKIM-signed, which implies when to use the tool (when DKIM signing is no longer desired). However, it doesn't explicitly mention alternatives or when-not-to-use conditions, so it falls short of a 5.

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

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

Despite no annotations, the description discloses the irreversible/destructive nature, scope of data deletion, and the need for explicit confirmation, providing robust behavioral transparency beyond the schema.

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

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

Two sentences, front-loaded with 'PERMANENTLY', no filler. Each word serves a purpose.

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

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

For a simple delete tool with no output schema, the description provides all essential context: what is deleted, permanence, and the required confirmation flag. It is self-contained for an agent to invoke correctly.

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

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

Schema covers both parameters with clear descriptions (full mailbox address, confirm must be true). The description reiterates 'Requires confirm=true' but adds no new parameter semantics, so baseline 3 applies.

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

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

The description clearly states the tool's function: permanently delete a mailbox and all its data, distinguishing it from mailbox read/update tools. The verb 'delete' and scope 'ALL of its data' make the purpose explicit.

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

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

It implies when to use (to remove a mailbox permanently) and emphasizes caution with 'cannot be undone' and 'Requires confirm=true', but does not explicitly name alternatives or exclusions. Context is clear but not 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?

With no annotations, the description carries the burden of behavioral disclosure. It discloses a destructive side effect ('replaces any existing keys') and clarifies that DNS publishing is a separate step. This is valuable context beyond a simple 'generate' statement.

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

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

Two sentences, no filler, with the action, important warning, and follow-up step all included. Perfectly front-loaded and appropriately sized.

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

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

For a single-parameter tool with no output schema, the description covers purpose, side effects, and next step. It could mention what is returned or that generation might be asynchronous, but these are not critical for basic usage.

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

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

The only parameter 'name' is fully described in the schema as 'The domain name'. The description adds no extra semantic detail beyond using the term 'domain', so the baseline of 3 applies because schema coverage is 100%.

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

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

The description uses a specific verb ('generate') and clear resource ('fresh DKIM key pair for a domain'), and explicitly notes that it replaces existing keys. This clearly distinguishes it from sibling tools like get_domain_dkim, set_domain_dkim, and delete_domain_dkim.

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

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

It provides a clear post-generation instruction: publish the DNS record from get_domain_dns_record record='dkim'. It also warns that existing keys are replaced. It doesn't explicitly compare against alternatives like set_domain_dkim, but the context is sufficient for correct 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?

With no annotations, the description carries the full burden of behavioral disclosure. It explains that the tool returns specific fields, which is useful, but it does not disclose error behavior (e.g., what happens if the alias does not exist) or any read-only guarantee. This is adequate for a simple getter but leaves some gaps.

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

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

The description is a single, concise sentence that immediately states the tool's purpose and output. There is no filler or redundant content.

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

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

Given the low complexity (one parameter, no output schema), the description covers the essential return values and the selection criterion. It is missing edge-case behavior like not-found handling, but for a simple getter this is acceptable completeness.

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

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

The input schema already provides a full description of the 'address' parameter (including an example), so baseline 3 is appropriate. The description does not add parameter-specific semantics beyond what the schema contains; it only clarifies that the result corresponds to that single alias.

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

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

The description uses a specific verb ('Get') and a clear resource ('a single alias'), and enumerates the exact fields returned (address, display name, redirect targets, timestamps). This distinguishes it from siblings like list_aliases or update_alias.

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

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

The description clearly conveys that this tool retrieves a single alias as opposed to listing all aliases, which is the implied usage context. However, it does not explicitly state when to use this instead of list_aliases or mention any exclusions, so it falls short of a 5.

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

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

No annotations are provided, so the description carries the full burden. It indicates a read-only operation via 'Get' and lists the returned fields, but does not disclose potential error behaviors, authentication requirements, or any side effects. For a simple retrieval, this is adequate but not rich.

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

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

The description is a single sentence that efficiently lists the key returned information. No unnecessary words or repetition. It is well-structured and immediately conveys the tool's purpose.

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

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

Without an output schema, the description takes on the role of explaining return values, which it does by enumerating specific fields. It does not cover error handling or all edge cases, but for a simple 'get' operation with a single parameter, the description is reasonably complete.

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

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

The schema provides 100% coverage for the single parameter 'name' with a clear description ('The domain name, e.g. example.com'). The tool description does not add further parameter semantics, but the schema already fully explains it, so baseline 3 is appropriate.

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

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

The description clearly states the action ('Get a single domain's info') and specifies the resource (a domain) along with the exact data returned (catch-all address, forward domain, limits, dates). It distinguishes itself from sibling tools like list_domains (which lists all domains) and get_domain_stats (which likely focuses on statistics).

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 use when you need detailed information about a specific domain, contrasting with listing tools. However, it does not explicitly mention when not to use it or name alternative tools for other scenarios. The context is clear but lacks explicit exclusions.

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

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

With no annotations, the description carries the full transparency burden. It explicitly lists the data fields returned, which clarifies the read-only nature and output scope. However, it does not mention potential edge cases like null values or permission requirements, but for a simple get tool this is acceptable.

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

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

The description is one concise sentence, front-loaded with the primary action and resource, followed by a compact list of returned fields. Every word earns its place with no redundancy.

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

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

Given a single parameter, no output schema, and no annotations, the description adequately informs the agent about what the tool does and what it returns. It could benefit from a note about return format or error behavior, but these are not critical for correct invocation.

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

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

The schema fully describes the single parameter 'name' with the description 'The domain name'. The tool description does not add extra parameter semantics beyond that, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Get') and resource ('white-label branding') and enumerates exactly what is returned (brand name, logo URLs, favicon, support URL, admin URL visibility, webmail/admin styles). It clearly distinguishes itself from sibling tools like get_domain or update_domain_brand.

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 branding-related information, but it does not explicitly state when to use this tool versus get_domain or update_domain_brand. No exclusions or alternative recommendations 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?

With no annotations, the description carries full behavioral burden. It discloses the return value (key pair with selector, public and private key) and the 404 error behavior for domains without DKIM keys. It does not mention authorization requirements, security sensitivity of the private key, or whether any side effects occur, but the verb 'Get' implies a read-only operation.

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

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

The description is two sentences, front-loaded with the action and resource, and every sentence provides useful information: the key pair composition and the 404 error case. No redundant phrasing.

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

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

For a one-parameter getter with full schema description and no output schema, the description covers the main behavior, return value, and an error case, which is largely complete. A minor gap is the lack of response format details or security notes, but these are not essential given the tool's simplicity.

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

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

The input schema fully describes the single 'name' parameter as 'The domain name', and the description adds no extra semantics beyond confirming the parameter is the domain. Since schema coverage is 100%, the baseline of 3 applies without any additional value from the description.

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

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

The description clearly states the tool retrieves the DKIM key pair (selector, public and private key) for a domain, using a specific verb and resource. It distinguishes from sibling tools like generate_domain_dkim, set_domain_dkim, and delete_domain_dkim by indicating this is a read operation.

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

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

The description implies usage when you need to read existing DKIM keys and mentions the 404 return for domains without keys, which suggests that generation or setup might be needed otherwise. However, it does not explicitly name alternatives such as generate_domain_dkim or state when to use them over this tool.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states that the tool returns 'the currently found value(s)', setting expectations for the output. It also discloses a dependency for the 'dkim' record type. It does not describe error cases or permissions, but for a read-only GET operation this is reasonable.

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

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

The description is a single sentence followed by a compact list of record types. Every phrase earns its place—the list is dense but structured with colons and quotes for readability. It is front-loaded with the purpose and then elaborates on the enum values, avoiding 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?

The description covers the core purpose and output content, but without an output schema it should more fully explain the structure of the returned data and potential failure modes (e.g., what happens if a DKIM key does not exist). It mentions a prerequisite but does not specify the behavior when that prerequisite is unmet. The tool is relatively simple, so this is not a major gap, but it prevents a higher 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?

The schema already provides descriptions for both parameters, giving 100% coverage. The description adds significant value by explaining each enum value in context (e.g., 'mx' for mail routing, 'verification' for TXT verification). This goes beyond the schema's brief descriptions and helps the agent select the correct record type.

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

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

The description clearly states the tool's function: 'Get a suggested DNS record for a domain, including the currently found value(s) so you can check whether DNS is configured correctly.' It uses a specific verb ('get') and resource ('suggested DNS record'), and the enumeration of record types distinguishes it from sibling tools like get_domain_dkim by focusing on DNS records rather than key management.

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 a clear usage context: 'so you can check whether DNS is configured correctly.' It also includes prerequisites (e.g., 'dkim requires DKIM keys to exist') and explains each record type's purpose, which helps the agent decide when to use this tool. However, it does not explicitly mention when not to use it or name 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, the description carries the burden of disclosure. It states the core behavior (returning daily counts for incoming/outgoing email over 30 days) and implies a read-only operation via 'Get', but does not explicitly say it is non-mutating or note any prerequisites like admin permissions. For a simple stats query, this is adequate but not overly detailed.

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

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

The description is a single, front-loaded sentence that conveys all essential information without extraneous words. It is concise and well-structured, earning a perfect score.

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

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

The tool is simple with one parameter and no output schema. The description adequately explains the returned data (daily inbound/outbound counts for a 30-day window). It could clarify whether incoming and outgoing are separate counts, but the phrasing is sufficiently clear for a straightforward stats tool.

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

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

The only parameter `name` is already described in the schema as 'The domain name', and the description reinforces this context by mentioning 'a domain'. Since schema coverage is 100%, the description adds minimal new meaning beyond what is already structured, meriting 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 action 'Get', the resource 'domain email stats', and the precise scope: incoming and outgoing emails per day for the last 30 days. This distinguishes it from sibling tools like get_domain (domain configuration) and get_mailbox_stats (mailbox-level stats).

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

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

The description implies when to use this tool (to retrieve aggregate email volume for a domain over the past month) but does not explicitly mention when not to use it or alternatives such as mailbox-level stats. It provides clear context but lacks explicit exclusions or comparison to 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?

With no annotations, the description must carry full behavioral burden. It implies a read-only retrieval via 'Get' and mentions the raw protocol nature, giving some insight. But it lacks disclosure about authentication requirements, output format, or potential response size, leaving notable gaps.

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

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

A single, front-loaded sentence that states the action, object, and purpose efficiently. Every phrase earns its place, including the diagnostic use case, with no redundancy or filler.

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

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

For a simple retrieval tool with a well-documented schema, the description conveys the core purpose and intended use. The absence of an output schema and annotations is partially mitigated by the clear 'raw transcript' wording, though a note on return format would round it out.

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

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

The input schema already provides full descriptions for both parameters (id as email log record ID, date as ISO format). The description adds no additional parameter-level meaning beyond what the schema offers, so the baseline 3 applies.

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

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

The description clearly states the action ('Get') and the resource ('raw SMTP/LMTP protocol transcript') tied to an email log record. This distinguishes it from sibling tools like list_email_logs and list_auth_logs by specifying a unique detail-level operation.

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

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

The phrase 'useful to diagnose delivery problems, rejections and bounces' provides concrete use-case context, implying when this tool is appropriate. However, it does not explicitly mention alternatives or state when not to use it, so it falls just short of full guidance.

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

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

With no annotations, the description carries the burden of disclosing behavior. It transparently lists the exact return fields and explains the password strength scale, which is helpful. However, it does not mention error handling (e.g., 404 for unknown address), authorization requirements, or any side effects, which for a get tool is a moderate gap.

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

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

The description is a single concise sentence that front-loads the purpose and packs in the key return fields without fluff. Every word earns its place.

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

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

Given the simple tool with one param and no output schema, the description covers the return fields comprehensively, including value interpretation for password strength. It doesn't describe error behavior, but for a straightforward get operation, the description is largely sufficient. A slightly higher score is held back by the missing edge-case 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 schema already describes the only parameter 'address' with examples, and the schema coverage is 100%. The description adds no additional parameter semantics beyond what the schema provides, fitting 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 opens with 'Get a single mailbox's info', which clearly specifies the verb (get) and resource (a single mailbox), and enumerates the exact fields returned. This distinguishes it from sibling tools like list_mailboxes by emphasizing 'single'. The purpose is unambiguous.

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

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

The description implies usage for retrieving details on one mailbox, but it does not explicitly contrast with list_mailboxes or state when to prefer this tool over alternatives. It provides no exclusionary guidance, so usage is only implied from the word 'single'.

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

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

No annotations are provided, so the description carries the behavioral transparency burden. It discloses the return data (storage limit, usage, email count) but does not explicitly confirm the operation is read-only or mention potential errors or permissions. This is sufficient for a simple getter but lacks depth.

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

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

The description is a single concise sentence that adequately conveys the tool's purpose and result. It is front-loaded with the key action and includes necessary specifics without 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?

The tool is simple with one parameter and no output schema. The description explains what the tool does and the data it returns, providing enough context for an agent to understand the operation. However, it doesn't specify the response structure or field names, which would be useful without 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?

The only parameter 'address' is fully described in the schema as 'The full mailbox address'. The description adds no extra meaning beyond the schema, so with 100% schema coverage, a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's function with a specific verb ('Get') and resource ('mailbox quota'), and enumerates the specific values returned (storage limit, usage, email count). This distinguishes it from sibling tools like get_mailbox_stats and update_mailbox_quota.

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

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

The description implies the tool is for retrieving quota information but does not explicitly contrast it with sibling tools like get_mailbox_stats or update_mailbox_quota. There is no explicit guidance on when to use this 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?

With no annotations provided, the description carries the full burden. It conveys a read-only retrieval operation through the verb 'Get', but does not disclose what happens if no script exists, whether any special permissions are needed, or the format of the returned script. It adds minimal behavioral context beyond the action itself.

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. It is front-loaded with the core purpose ('Get the Sieve filtering script') and includes a concise clarifying parenthetical. Every word earns its place with no redundancy.

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

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

Given the tool's low complexity (only one parameter, no output schema, no annotations), the description provides adequate context about the resource and the standard involved. It could be more complete by mentioning the return value or default behavior when no script exists, but it is sufficient for an agent to select and invoke the tool correctly.

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

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

The schema fully describes the single parameter 'address' as 'The full mailbox address' (100% coverage). The description does not add additional parameter-level meaning beyond what the schema already provides, 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 verb 'Get' and the resource 'Sieve filtering script of a mailbox', with a helpful parenthetical explaining what Sieve is (server-side email filtering, RFC 5228). This distinguishes it from siblings like update_mailbox_sieve and other getters.

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

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

The description implies when to use it (to retrieve a mailbox's Sieve script) but provides no explicit guidance on when not to use it or how it relates to alternatives like update_mailbox_sieve or get_mailbox. The RFC reference adds context but not usage direction.

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

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

With no annotations, the description must convey behavioral details. It does state the specific aggregation (per day, both directions) and time window (last 30 days), adding value beyond the name. However, it omits potential nuances such as timezone handling, date inclusivity, error cases, or response structure, leaving some ambiguity.

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

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

The description is a single, front-loaded sentence with no redundant information. Every word contributes to understanding the tool's purpose and behavior.

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

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

Although there is no output schema, the description indicates what will be returned (incoming/outgoing counts per day) and the time range. It doesn't specify the exact output shape (e.g., array vs object) or edge cases, but for a straightforward stats tool, it provides sufficient 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 already documents the single parameter 'address' with a clear description ('The full mailbox address'), giving 100% schema coverage. The tool description adds no additional parameter-level guidance, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb 'Get' and clearly defines the resource (mailbox) and the exact metric (incoming and outgoing email counts per day over 30 days). This distinguishes it from sibling tools like get_mailbox or get_domain_stats, which target different resources.

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

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

The description provides clear context on when to use this tool (to obtain per-mailbox email volume statistics over a 30-day window). It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous enough for an agent to select it appropriately.

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

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

With no annotations, the description carries the full burden. It discloses pagination (max 25 per page), optional search, and alias structure, but omits defaults for page/paging, ordering, and error behavior, leaving some behavioral gaps.

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

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

Two concise sentences: first states the core action, second adds essential return structure. No unnecessary words, effectively front-loaded.

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

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

For a simple list tool with three optional parameters and no output schema, the description covers the key aspects: action, scope, pagination, search, and alias elements. It lacks exact response format details, but is otherwise complete enough for an agent to use correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description repeats the pagination limit and optional search, but adds no new parameter-specific 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 uses a specific verb 'List' with a clear resource 'all aliases in the account', and mentions pagination and search. It distinguishes from sibling tools like get_alias (single alias) and mutation tools by conveying a read-only enumeration.

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

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

It clearly states the tool's purpose for listing aliases, implying when to use it. It does not explicitly name alternatives or exclusions, but the context and sibling names make the intended use clear.

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

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

With no annotations provided, the description carries the full burden. It discloses pagination (max 25 per page), optional search query, and the fields returned. It also implies read-only behavior via 'List', but does not mention authentication requirements or rate limits. This is good transparency but could be richer.

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 three sentences, front-loaded with the main action and resource, followed by details and use case. Every sentence contributes information without redundancy or unnecessary length.

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

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

The tool has 4 parameters, no output schema, and no annotations. The description covers purpose, parameters (date, pagination, query), and use case. It also mentions return fields, which is helpful given the lack of an output schema. A minor omission is specifying sorting or total count, but overall it is complete for a list-type 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 coverage is 100%, so parameters are already well-documented. The description adds context by mentioning 'for a given date' and pagination limits, but these echo the existing schema descriptions. It does not significantly enhance parameter understanding beyond what the schema provides, warranting the baseline 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 tool lists authentication log records, specifies the types (IMAP/POP/SMTP/webmail), and includes key fields (timestamp, IP, email, service). This distinguishes it from siblings like list_email_logs and get_email_log_protocol by focusing specifically on authentication events.

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: it is for a given date and useful for security audits and detecting unauthorized access. It implies this tool is for authentication-specific log queries, though it does not explicitly name alternatives or exclusions, which prevents a 5.

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

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

No annotations are provided, so the description carries full responsibility for disclosing behavior. It clearly mentions pagination limits (max 25 per page), optional search, and the return structure (page info plus domains). This goes beyond a basic read-only implication, though it omits details like auth or sorting behavior.

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

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

Two short sentences, front-loaded with the core purpose and then adding the key behavioral details. No filler or redundant information; every sentence earns its place.

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

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

For a list tool with 3 optional params and no output schema, the description covers pagination and return format, which is essential. It does not mention sorting or default values, but these are minor gaps given the straightforward nature of the operation.

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

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

Schema coverage is 100% with clear descriptions for each parameter (page, query, paging). The description adds no meaning beyond the schema; it merely restates pagination and search. Per the baseline for high schema coverage, a score of 3 is appropriate.

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

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

Clearly states 'List all domains in the postale.io account' with a specific verb and resource, distinguishing it from sibling tools like get_domain (single domain) and other list tools. The scope is explicit and unambiguous.

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

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

The description indicates this is the tool for listing all domains with pagination and search, providing clear context for when to use it. It does not explicitly mention alternatives or exclusions, but the use case is obvious and no conflicting guidance exists.

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

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

With no annotations, the description carries the transparency burden. It discloses pagination (max 25 per page), optional search query, and the type of data returned. However, it does not mention response format, default behavior, or any potential rate limits or authentication requirements, leaving some gaps.

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

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

Three sentences, front-loaded with the core purpose, then key details (pagination, search), then a cross-reference to a sibling tool. No filler, every sentence earns its place.

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

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

For a list tool with four parameters and no output schema, the description is sufficiently complete. It specifies the data fields returned, pagination limits, search capability, and how to get more detailed protocol information, covering the essential context an agent needs.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds a bit of context by linking 'date' to 'given date' and calling out the optional search query, but this is marginal value over the schema definitions.

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

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

The description clearly states the tool lists email log records for a given date, specifying the exact fields (timestamps, IPs, ports, user, addresses, redirections, subject). It distinguishes itself from siblings by focusing on email logs and pointing to get_email_log_protocol for full transcripts, making its 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 provides clear context for use (listing email delivery attempts for a date) and explicitly mentions using get_email_log_protocol when a full SMTP transcript is needed. However, it does not explicitly contrast with list_auth_logs or state when not to use this tool, so it stops short of full exclusion 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?

The description discloses key behavioral details: it returns a paginated list (max 25 per page), supports an optional search query, and includes specific fields like address, name, flags, password strength, and timestamps. This is valuable context beyond a bare 'list' statement, and since no annotations are present, the description carries the full burden effectively.

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-loads the main purpose, and includes essential details without fluff. Every word earns its place.

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

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

For a simple list operation, the description covers the primary aspects: scope (all domains), pagination behavior, search capability, and return fields. It lacks detail on default page size or error handling, but these are minor for a read-only list tool.

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

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

The input schema already provides descriptions for all three parameters (page, query, paging), so the description adds little new semantic detail. It mentions pagination and search generically, but does not clarify the interaction between page and paging or search syntax, which would be valuable.

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 specifically states 'List all mailboxes in the account across every domain' with a clear verb and resource, and distinguishes from sibling tools like get_mailbox by emphasizing the collection scope. It also notes pagination and search, 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 provides clear context that this tool is for retrieving a list of all mailboxes, which implies it should be used for bulk listing rather than fetching a single mailbox (get_mailbox). It does not explicitly name alternatives or exclusions, but the scope is evident from the text.

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

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

No annotations are provided, so the description carries the full burden. It mentions 'without changing DNS' but does not disclose whether existing DKIM keys will be overwritten, required permissions, or other side effects of this write operation.

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

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

The description is a single, well-structured sentence that immediately conveys the action and a use case, with no unnecessary words.

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

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

The description is adequate for understanding the tool's core purpose but lacks important context such as overwrite behavior, prerequisites (e.g., domain existence), and return value, especially given the absence of annotations and 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 descriptions cover all four parameters (100% coverage), so baseline 3 applies. The description adds no extra parameter-level detail beyond what is already in 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 'Install a specific DKIM key pair (bring your own keys) for a domain', with a concrete use case, which distinguishes it from siblings like generate_domain_dkim and delete_domain_dkim.

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

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

It provides an explicit context: 'e.g. when migrating from another provider without changing DNS', implying when to use this tool. However, it does not explicitly name alternatives or exclusion criteria.

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

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

The description discloses a critical behavioral trait: redirectTo replaces the full target list rather than merging. This goes beyond the schema and is especially important given no annotations are provided. It doesn't cover permissions or return value, but the key semantic is well explained.

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: the first states the tool's purpose, the second provides an essential caveat about the destructive replacement behavior. No unnecessary words or repetition.

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

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

For a simple update tool with fully documented parameters and no output schema, the description covers the main functional caveat. It could mention expected return values or error conditions, but the description is sufficiently complete for the tool's complexity.

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

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

Schema coverage is 100%, providing descriptions for all three parameters. The description adds further value by clarifying the replacement semantics of redirectTo, which is not fully obvious from the schema alone. Name and address are self-explanatory.

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 that the tool updates an alias's display name and/or redirect targets, with a specific verb and resource. It distinguishes from sibling tools by targeting aliases, though it doesn't explicitly contrast with create_alias or delete_alias.

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

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

Usage is implied: you use this when you need to modify an existing alias's display name or redirect targets. However, there is no explicit guidance about when not to use it or comparison with alternatives like create_alias or update_mailbox.

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 discloses the partial-update behavior ('Only the provided fields are changed'), which is valuable and not evident from the tool name. However, with no annotations, it does not mention permissions, reversibility, or side effects, leaving the safety and operational profile incomplete.

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 action and purpose, and the second sentence provides essential behavioral context without redundancy. Every word earns its place, making it exceptionally concise.

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

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

For a moderately complex update tool with a fully described schema and no output schema, the description provides clear purpose and partial-update behavior, which is sufficient for an agent to select and invoke correctly. It lacks some context like error conditions or return values, but the schema and description together cover the essential operational needs.

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

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

The input schema has 100% coverage with descriptions for all 7 parameters, so the schema already explains parameter semantics. The description adds a high-level summary of parameter categories (catch-all, forward domain, limits) but does not add detail beyond the schema, matching the baseline expectation.

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 explicitly states 'Update a domain's settings' and lists the specific settings (catch-all address, forward domain, mailbox/alias/storage limits), making it clear what the tool does. This distinguishes it from sibling tools like update_domain_brand, since the scope is core domain settings rather than branding.

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 use for updating domain settings but does not explicitly mention when to use this tool versus alternatives or any exclusions. No explicit guidance such as 'for branding, use update_domain_brand' is provided, so usage context is only inferred.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It explicitly states that only provided fields are changed, which is a key behavioral trait, and it discloses cross-field dependencies (darkLogoUrl/menuLogoUrl/faviconUrl require logoUrl). It also explains the capabilities of style objects, adding value beyond the schema.

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 four short sentences, each serving a distinct purpose: stating the action, describing partial update behavior, noting dependencies, and summarizing style options. It is front-loaded with the action and avoids any unnecessary elaboration.

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 (10 parameters, nested objects) and lack of annotations/output schema, the description adequately covers the core behaviors and constraints. It explains partial updates and dependency rules, though it doesn't mention potential mutations' side effects or permission requirements. The schema covers parameter details, so the description focuses on operational nuance, which is appropriate.

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

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

The input schema already provides descriptions for all 10 parameters (100% coverage), so the baseline is 3. The description adds meaningful cross-parameter semantics by explaining the dependency chain among logo URLs and clarifying the distinction between adminStyle (which can include colorPrimary/colorSecondary) and webmailStyle. This enriches the agent's understanding 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 a specific verb+resource ('Update the white-label branding of a domain'), which clearly differentiates from sibling tools like update_domain (general domain settings) or get_domain_brand (read). It also provides specifics about partial updates and style options, reinforcing the tool's 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?

While the description doesn't explicitly name alternative tools, it establishes clear usage context by indicating this is for white-label branding with partial updates. The dependency on logoUrl for certain fields and the grouping of style properties provide practical guidance on when and how to invoke the tool. It lacks an explicit 'when not to use' but is otherwise clear.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the partial-update semantics (only provided fields are changed), which is important and goes beyond the schema. However, it does not mention permissions required, error behavior if the mailbox does not exist, or side effects of role changes. This is adequate but not comprehensive, so a 3 is appropriate.

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

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

The description is two sentences, front-loaded with the core action ('Update a mailbox') and followed by a concise explanation of scope. Every word earns its place, with no redundancy or irrelevant detail. This is exemplary conciseness.

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

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

Given no output schema and no annotations, the description is reasonably complete: it defines the operation, enumerates mutable fields, and clarifies partial-update behavior. It could additionally specify that the mailbox must already exist or describe the return format, but for a straightforward update tool, the essential context is covered. This is a 4.

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

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

The schema already has 100% coverage with descriptions for all parameters, so the baseline is 3. The description adds meaningful semantic value by stating 'Only the provided fields are changed,' which clarifies how the optional parameters behave collectively—omitted fields remain untouched. This goes beyond individual schema descriptions and enhances understanding, so a 4 is warranted.

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

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

The description clearly states the tool's purpose: updating a mailbox's display name, password, disabled status, or admin roles. It uses a specific verb ('Update') with a specific resource ('a mailbox') and enumerates the mutable fields. This also distinguishes it from sibling tools like create_mailbox and delete_mailbox, so purpose clarity is high.

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 that this is a partial update tool ('Only the provided fields are changed'), which guides usage. However, it does not explicitly mention when not to use it or name alternative tools (e.g., create_mailbox for new mailboxes). Since the context is clear and the partial-update behavior is valuable guidance, this is a 4.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It simply states the action without revealing side effects, such as whether setting is idempotent, if it overwrites the existing quota, or if it can be rolled back. This is a meaningful omission for a mutation tool.

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

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

The description is a single, concise sentence that front-loads the action and includes the unit of measurement. There is no wasted text.

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

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

For a simple two-parameter tool with full schema coverage, the description is nearly sufficient to invoke correctly. However, without annotations or an output schema, it lacks behavioral context (e.g., what happens on failure or if the quota is set to 0), which slightly limits completeness.

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

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

The schema already documents both parameters (address and storageLimit) with clear descriptions, and the description adds no extra meaning beyond restating that the limit is in gigabytes. Since schema coverage is 100%, the description is adequate but not additive.

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

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

The description uses a specific verb ('Set') and identifies the resource ('mailbox') and the attribute ('storage limit') with units. It clearly distinguishes this from get_mailbox_quota (retrieval) and update_mailbox (generic update), 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 gives clear context for when to use the tool (setting a mailbox's storage limit) but does not explicitly state alternatives or exclusions, such as recommending get_mailbox_quota for checking current quota or warning against using update_mailbox for quota. Usage guidance is implied rather than explicit.

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

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

No annotations are provided, so the description carries the full burden. It discloses a key behavioral trait: 'The whole script is replaced', which is critical for an update operation. It also mentions the RFC syntax, though it does not detail permissions or error behavior; for a simple replacement, this is sufficient.

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

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

Two sentences with no filler. The main action is front-loaded, and the second sentence provides a crucial caveat about fetching the current script first. Every word earns its place.

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

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

For a two-parameter update tool with no output schema, the description fully covers the essential context: what the tool does, the destructive replacement behavior, and how to safely modify rules by referencing the sibling tool. It is complete for its simplicity.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds contextual meaning by implying the script parameter represents the complete replacement and that the address is the full mailbox address, reinforcing the replacement semantics beyond what the schema 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 uses the specific verb 'Replace' and clearly identifies the resource as 'the Sieve filtering script of a mailbox', which distinguishes it from siblings like get_mailbox_sieve and update_mailbox. It also specifies the RFC 5228 syntax, adding precision to the tool's 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?

It explicitly states that the whole script is replaced and advises fetching the current one with get_mailbox_sieve if only adding rules, providing clear when-to-use guidance and naming the alternative tool for partial modifications.

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