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

Annotations already cover readOnlyHint, idempotentHint, and destructiveHint. The description adds the behavioral fact 'No API key needed', which is not present in annotations and is valuable for an agent deciding whether to invoke this tool without authentication. No contradiction with annotations.

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

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

Two sentences, front-loaded with the returned content, followed by the auth requirement and usage guidance. No filler; 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 capabilities-discovery tool with no parameters and no output schema, the description fully covers what the agent needs: what is returned, the lack of auth, and when to call it. Nothing missing 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 tool takes zero parameters, so there is nothing for the description to clarify. Baseline for 0-parameter tools is 4, and the description's focus on return content 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 states a clear verb ('Return') and a specific resource ('what VaEmail supports'), enumerating the content (interfaces, capabilities, limits, scopes, region). It explicitly frames itself as the entry-point capability tool, distinguishing it from sibling tools that perform diagnostics, listings, or sending.

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

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

It explicitly says 'Call this first when deciding whether VaEmail fits a need', which gives a clear when-to-use directive and implies ordering relative to siblings. It does not explicitly name alternatives, but the 'first' directive plus the sibling list makes the intended usage unambiguous.

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

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

The description adds the crucial non-obvious behavior that declaration does not authenticate and DNS changes require a human step, so the agent must not claim readiness. Annotations already signal a write operation; this description adds meaningful operational context.

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

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

Three tight sentences, front-loaded with the action and output, followed by the critical caveat. No filler or redundancy.

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

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

Given no output schema, the description does a good job of stating that DNS records are returned and what to do with them. It could mention failure states like duplicate domains, but the core invocation and follow-up workflow are adequately covered.

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

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

The schema covers domain and dkim_selector with descriptions, and idempotency_key is self-explanatory by name. The description does not explain how the optional parameters affect DNS records, but this is a moderate gap given 67% 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?

States a specific action ('Declare a domain') and a concrete output (DNS records to add, each with purpose). It explicitly separates declaration from authentication and verification, which distinguishes it from siblings like vaemail_verify_domain.

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

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

The context is clear: this is the initial declaration step, and the follow-up is publishing DNS records and verifying. It does not explicitly name alternatives or say when not to use this tool, but the verify-later guidance makes the intended workflow evident.

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

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

Annotations already declare readOnly and idempotent, and the description adds what results are returned (authentication, reputation, actions) without contradicting the safety hints. It does not mention any side effects or state changes, which aligns with the readOnly annotations.

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

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

The description is two sentences, direct, and includes all necessary details without redundancy. Every phrase contributes to understanding the tool's purpose and behavior, making it highly efficient.

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

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

Given there is no output schema, the description adequately sets expectations by listing the types of findings (authentication, reputation, actions) and including guidance on endpoints. It is sufficient for an agent to decide and invoke the tool, though a bit more detail on the exact response format could be added.

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, 'domain', is fully described in the schema as restricting the diagnosis. The description adds context by using 'account' but then referencing domains, and the optional nature is clear. This goes beyond the basic schema definition.

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

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

The description clearly states the tool diagnoses deliverability, listing specific aspects (authentication, reputation, recommended actions) and directly answers the user's question 'why are my emails from example.com landing badly?'. It distinguishes from siblings by focusing on the full diagnostic, not just bounces or DNS requirements.

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

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

It explicitly says 'Answers... in one call' and mentions each recommended action has the endpoint that performs it, implying when to use this vs. other tools. However, it does not explicitly state when not to use it (e.g., for isolated bounce lists), so it is clear but not fully 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?

The description adds behavioral details beyond the annotations by specifying the output format ('record by record') and content ('with the role of each'). This complements the readOnlyHint and idempotentHint, providing a clearer picture of what the tool returns without contradicting the stated constraints.

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

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

The description is a single, focused sentence that avoids redundancy. It is front-loaded with the verb and resource, making the purpose immediately clear. No unnecessary words or enumerated lists that could obscure the message.

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

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

The tool has a simple interface with one parameter and no explicit output schema, so the description suffices. It explains what is returned (DNS records, with roles) and implies the scope (declared domain). There are no missing elements like error handling or side effects, which are not required given the read-only nature and the absence of an output schema.

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

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

The schema covers the 'domain' parameter (type string, required), and the description references it implicitly via 'declared domain'. However, no additional meaning is provided about the parameter's format, expected values, or examples. Given full schema coverage, a baseline of 3 is appropriate, and the description does not elevate it.

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

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

The description clearly states the action (Return), the resource (DNS records), and the format (record by record, with the role of each). It effectively communicates the tool's purpose without ambiguity, distinguishing it from sibling tools that handle other email operations.

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

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

The description does not explicitly state when to use this tool versus alternatives. It implies the scenario of needing DNS information for a domain (likely for email setup), but this is not made explicit. There is no direct comparison to sibling tools, leaving the decision to the agent's inference.

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

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

Annotations already declare this is read-only, idempotent, and non-destructive. The description adds valuable extra behavior: message bodies are never stored in the audit log, which matters for privacy and for what can be reported afterward.

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 economical sentences: it states the core behavior, adds an important caveat, and closes with a direct use case. Every sentence earns its place with no redundancy.

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

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

With no output schema and no parameter descriptions, the description should explain what the agent gets back and how to use the optional parameters. It explains the logged fields conceptually but leaves pagination, filtering, and the meaning of 'since' and 'cursor' undefined, so an agent cannot reliably construct a correct call.

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 0% description coverage, and the description does not compensate by explaining limit, since, cursor, or operation. It mentions 'operation' as a logged field, not as a filter parameter, and gives no guidance on pagination or filter formats.

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

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

The description states a specific verb ('Return') and resource ('log of API actions') and enumerates the meaningful fields: which key, operation, parameters, and result. The title reinforces the audit-log purpose, and this is clearly distinct from sibling tools like get_usage, list_bounces, or list_messages.

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 gives a clear use case: 'Use it to report exactly what was done.' This tells the agent when the audit log is the right tool, though it does not explicitly rule out alternatives or mention sibling tools.

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

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

Annotations declare read-only, idempotent, and non-destructive behavior. The description adds concrete details about the returned data (events, transport error) without contradicting the annotations, providing transparency beyond the annotations.

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

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

The description is a single, clear sentence with no redundant words. It lists the key elements (events, transport error) in a straightforward manner.

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 get tool with one parameter, the description fully explains what it returns and the parameter's purpose. No additional context is needed 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 only parameter 'id' has a description that explains its origin ('Message id returned by vaemail_send_email'), giving context beyond just the type. Schema coverage is 100%, so this exceeds the baseline.

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

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

The description clearly states the tool returns delivery status and events for a single message, including transport error on failure. The verb 'Return' is specific and the scope (one message) distinguishes it from sibling tools like list_messages.

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 (when you have a message id and need status/events) and the parameter description tells where the id comes from. It doesn't explicitly contrast with alternatives but the context is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds meaningful behavioral context by enumerating exactly what usage data is returned and framing the tool as a pre-batch stop-check. This goes beyond the annotations without contradicting them.

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 wasted words. The output contents are listed first, and the operational guidance is placed second. Every phrase earns its place and the description is easy to parse quickly.

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

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

With zero parameters and no output schema, the description carries the full burden of explaining what the agent will get. It does so by listing all return categories: monthly quota and remaining amount, today's sends, key scopes, daily cap, and remaining allowance. It also gives the practical trigger for calling it, making the context complete for this simple read-only 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 is empty and the parameter count is zero, so parameter semantics are not applicable. The baseline for zero-parameter tools is 4, and the description appropriately adds no irrelevant parameter details.

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 names a specific verb and resource: it returns monthly quota, remaining quota, today's sends, and key-specific scopes, daily cap, and allowance. This is distinct from the sibling tools, none of which focus on usage or quota. A model can immediately know what this tool does without opening a schema.

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

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

The description explicitly tells the agent when to use the tool: 'Read it before a batch to know whether to stop.' This is clear context for invocation. It does not mention when not to use it or compare it to alternatives, but the purpose is unique enough among siblings that this is only a minor gap.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds valuable behavioral context by disclosing that sending to these addresses is refused, and that the output includes the reason for exclusion. This goes beyond the annotation-only information.

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 fluff, with the most important scoping information front-loaded. The operational warning is succinctly added at the end.

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

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

For a simple read-only list, the description gives the essential purpose and a usage tip, but it lacks parameter semantics and return-structure details. Since there is no output schema, the agent does not know what the response contains beyond 'reason for each'. Some gaps, but not severe for a filtering 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?

Schema description coverage is only 25% (only the `since` parameter has a description). The description does not compensate by explaining `limit`, `cursor`, or the `reason` filter, despite the low coverage. The meaning of these parameters is left to inference from names and enum values.

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

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

The description uses a specific verb and resource: 'List addresses excluded from sending', and enumerates the categories (hard bounces, complaints, unsubscribes) with the reason for each. This clearly distinguishes it from sibling tools like list_messages or get_message because it focuses on bounces and exclusion reasons.

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 actionable context: 'Sending to one of them is refused, so read this before retrying a failed recipient.' This tells the agent when to use it, though it does not explicitly name sibling alternatives or state when not to use it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context by noting the DNS records are shown in their 'live state', which tells the agent the tool fetches current data rather than cached values. No contradiction with annotations.

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

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

The description is a single sentence with no filler. It front-loads the action and resource, then adds the distinguishing return detail efficiently.

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

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

For a zero-parameter, read-only listing tool with no output schema, the description is complete: it states what is returned (domains) and what additional detail is included (live SPF/DKIM/DMARC state). An agent has enough information to call this tool and interpret the result without further clarification.

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

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

The tool has zero parameters, so the baseline is 4. The description correctly focuses on what the tool returns rather than parameter details, and there is nothing about parameters that needs clarification.

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

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

The description states a specific verb ('List') and resource ('sending domains of the account'), and adds a distinctive detail: the live state of SPF, DKIM, and DMARC records. This clearly differentiates it from sibling tools like vaemail_list_bounces, vaemail_get_usage, and vaemail_get_audit_log, 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 implies that this tool is used to inspect sending domains and their DNS record status, but it does not explicitly state when to choose it over related siblings like vaemail_verify_domain or vaemail_diagnose_deliverability. The usage context is inferable but not spelled out.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior. The description adds useful behavior beyond annotations: newest-first ordering and pagination via the returned next_cursor. It does not mention default limit or response shape, but the safety profile is already covered by annotations.

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

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

Two sentences with no filler: the core action and ordering are front-loaded, followed by the essential pagination instruction. It does not repeat schema details or annotations.

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 five optional parameters and no output schema, the description covers the essential calling contract: ordering, filters, and pagination. It could be more explicit about default limit and returned message fields, but the core information needed to invoke it correctly is present.

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

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

Schema coverage is 0%, so the description must compensate. It maps status, tag, and recipient to the schema's status, tag, and to parameters, and it references cursor pagination. However, it does not explain limit semantics, cursor mechanics beyond 'returned next_cursor', or the fact that all parameters are optional.

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

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

Description states a specific verb and resource ('List messages') with ordering ('newest first') and filter dimensions (status, tag, recipient). It is clearly distinct from sibling get_message (single message) and list_bounces (bounces), so an agent can select it without opening the schema.

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: use this when you need a paginated list of messages filtered by status/tag/recipient. It does not explicitly name alternatives or exclusion criteria, but the collection-vs-single and messages-vs-bounces distinctions are implied by the wording.

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?

It discloses the async acceptance semantics, the non-blocking return behavior, and the idempotency mechanism beyond what annotations provide. This is valuable behavioral context for an agent deciding how to handle responses and retries.

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 focused sentences with no filler. The most important behavior (queued, returns immediately) is front-loaded, followed by follow-up guidance and idempotency advice.

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 9-parameter mutation tool with no output schema, the description covers the key operational concerns: side effect, async behavior, return value, and retry safety. It does not mention prerequisites like domain verification, but the schema and sibling tools partially mitigate that gap.

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

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

Schema coverage is 89%, so the schema already documents most parameters. The description adds meaning around idempotency_key and the return id, but does not need to compensate for missing parameter documentation.

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

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

The description states a specific verb ('Queue'), a clear resource ('a transactional email'), and the result ('return its id'). It distinguishes this tool from the sibling vaemail_get_message by clarifying the queue-then-deliver flow.

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 explains when to call this tool (to queue a send) and directs the agent to vaemail_get_message for delivery status. It also gives concrete retry guidance via idempotency_key, though it does not explicitly list exclusions or alternatives for other scenarios.

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 openly states 'Sends nothing', aligning with the readOnly and idempotent annotations. It also explains what the tool does (reports whether email would go out) and what it does not do (send), providing full transparency about side effects.

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

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

The description is extremely concise, using two short sentences to convey the tool's purpose, behavior, and recommended usage. There is no redundant or extraneous information.

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

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

Given the tool's simplicity and the absence of an output schema, the description provides enough context for correct usage. It tells when to use it, what it does, and what it avoids, though it does not specify the exact return format or potential edge cases, which are less critical for a dry-run validation 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 schema has no descriptions for any of the four parameters, and the tool description does not elaborate on how 'to', 'html', 'subject', or 'template_id' are used in the validation logic. Since schema description coverage is 0%, the description should compensate but does not mention any parameter details.

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

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

The description clearly states it is a dry run that reports whether the email would go out and names blockers, explicitly contrasting with actual sending. It distinguishes itself from sibling tools like vaemail_send_email and vaemail_diagnose_deliverability by focusing on validation without sending.

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 explicit usage guidance: 'Use it right after setup, before the first real message.' This tells the agent exactly when to invoke this tool, and also implies when not to (for actual sending).

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds that the operation reads public DNS, which is useful behavioral context, and that it reports each record. No contradiction with annotations, but it does not disclose potential edge cases like DNS lookup failures or rate limits.

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

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

The description is two sentences with no waste. The primary action and scope are front-loaded in the first sentence, and the second sentence provides a concise rationale without derailing the core definition.

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 what the tool reads and why, and the read-only annotations cover safety. However, it lacks an explicit explanation of the dkim_selector parameter and does not describe the exact return format or how to interpret the reported records. With no output schema, a bit more detail would make it fully self-contained.

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

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

Schema description coverage is 0%, so the description must compensate. 'Domain' is clearly implied as the domain to check, and 'DKIM' hints that dkim_selector is related to DKIM lookup. However, the optional dkim_selector parameter is never explicitly explained, and there is no guidance on how omitting it affects the DKIM check. This is a meaningful gap for a two-parameter tool.

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 ('Read') with a clear resource ('SPF, DKIM and DMARC for a domain in the public DNS') and states the output ('report each record'). This distinguishes it from siblings like vaemail_dns_requirements (setup requirements) and vaemail_diagnose_deliverability (broader deliverability diagnosis), making the tool's role unmistakable.

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

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

The description implies a usage context by warning 'Without SPF and DMARC, large mailbox providers file the mail as spam,' which suggests this tool is for checking authentication before sending. However, it does not explicitly state when to use this tool versus alternative sibling tools, nor does it mention any exclusions or prerequisites.

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