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 adds the meaningful trait that suppressing is 'SAFE' and stops future sends, but it does not disclose other important aspects like idempotency, whether it overwrites an existing suppression, permission requirements, or the response format. This is minimal 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 two sentences, front-loaded with the primary action, and contains no irrelevant details. Every word adds value: the action, the default list, and the safety implication. 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 tool with no output schema, the description covers the core action and effect but omits details about the 'kind' parameter values and the relationship to remove_suppression. It is minimally sufficient but leaves room for clarification in operational contexts.

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%, and the description only partially compensates. It clarifies that 'email' is the address and notes the default for 'kind' (global unsubscribes), but it does not explain any other possible values for 'kind' or the format/validation of 'email'. This leaves the optional parameter underdocumented.

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 an address to a suppression list') with a specific resource and even notes the default kind. It differentiates from siblings like remove_suppression by emphasizing this is the 'add' operation and highlights the effect of stopping future sends.

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 by explaining the safety and effect, but it does not explicitly mention alternatives or when to use this instead of remove_suppression or check_suppression. The 'SAFE direction' note gives some context, but lacks direct comparison with 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?

No annotations are provided, so the description carries full burden. It states the action but does not disclose return format, side effects, or error behavior. It adds the deliverability/consent context, which is helpful, but for a read-only check the transparency is minimally adequate.

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 core purpose, followed by a rationale. Every word earns its place; no fluff or redundancy.

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

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

The tool is simple with one parameter and no output schema. The description explains purpose and usage context well. However, it doesn't state the return type (e.g., boolean) which would be useful for an agent, and it doesn't mention any limitations. Still, it's nearly 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 has one parameter 'email' with no description (0% coverage). The description says 'address' but not explicitly 'email address', though context implies it. It doesn't add format, constraints, or meaning beyond the schema. For a single obvious parameter, this is adequate but not compensating fully.

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 'Check' and resource 'suppression list', clearly stating the tool's function. It distinguishes from siblings like list_suppressions (which lists all entries) and add/remove_suppression (mutations).

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 context: 'Run this before drafting mail to someone' and explains the consequence of ignoring it (deliverability harm, consent violation). It does not explicitly name alternatives or when-not-to-use, but the use case is well-defined.

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 behavioral burden. It clearly states the operation (listing) and the data returned (domains and DNS validity), implying a read-only action. However, it does not mention authorization needs or output format, leaving some behavioral details implicit.

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

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

The description is a single, well-structured sentence that front-loads the action and resource, then appends a useful usage pointer. Every word earns its place without 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?

For a zero-parameter tool with no output schema, the description adequately covers purpose, expected return content, and a usage scenario. It is sufficiently complete for an agent to select and invoke this 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 tool has zero parameters, so schema coverage is trivially 100%. The description adds no parameter details, but none are needed. Baseline 4 applies due to the 0-param case.

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 distinct resource ('authenticated sending domains') and adds a focused qualifier ('their DNS validity'). It clearly differentiates from sibling tools like send_email or get_email_stats, which serve different purposes.

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 'the first thing to check when deliverability drops' provides a clear triggering scenario. While it does not explicitly name alternatives, the prioritization hint gives agents a strong contextual cue for when to invoke this tool over others.

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 the burden of disclosing behavior. It does so partially by listing the data fields and mentioning the date format, but it does not explicitly state that this is a read-only operation with no side effects, nor does it explain the behavior of omitted end_date. This is adequate but not comprehensive for a tool with zero annotation coverage.

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 quickly communicates the tool's purpose and key parameters. Every element—metrics, date format, aggregation options—earns its place, with no filler or redundancy.

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

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

The tool is relatively simple with three parameters and no output schema. The description lists the returned metrics, which partially compensates for the lack of output schema. However, it is silent on the end_date parameter's behavior and any response structure, leaving minor gaps for a complete understanding.

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

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

Schema description coverage is 0%, so the description must compensate. It does by specifying the exact format for start_date (YYYY-MM-DD) and the allowed values for aggregated_by (day|week|month). However, it fails to explain end_date's semantics (e.g., default behavior). The added meaning is substantial for two of three parameters.

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 this tool retrieves global email statistics, listing specific metrics (requests/delivered/opens/clicks/bounces/spam). This is a specific resource with a clear scope ('global') and is easily distinguished from sibling tools like send_email or list_templates which serve different purposes.

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

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

The description provides clear context for when to use this tool, such as retrieving aggregated email stats over a date range. It does not explicitly name alternatives, but given none of the sibling tools cover stats, the usage intent is unambiguous. It also clarifies the aggregation options, guiding the user on how to tailor the request.

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?

Since no annotations are provided, the description carries full responsibility for behavioral disclosure. The word 'Fetch' indicates a read-only operation, and the phrase 'subject + content preview' clarifies that it returns a preview rather than full content. However, it could explicitly state that no modifications occur or mention any authentication requirements.

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

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

The description is one concise sentence that is front-loaded with the core action and resource. It contains no unnecessary words, making it highly efficient and easy to parse.

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

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

For a simple tool with one parameter and no output schema, the description adequately communicates the return value (template with versions and content preview). It does not explain error conditions or provide broader context, but the description is reasonably complete 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?

Schema description coverage is 0%, but the single parameter 'template_id' is self-explanatory and the description repeats 'Fetch one template', implying the ID specifies which template to fetch. The description does not add explicit parameter detail, but the parameter name and context are sufficient for a simple identifier.

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 'Fetch' with a specific resource 'one template with its versions', clearly indicating a single-item retrieval operation. It also specifies the return content ('subject + content preview'), distinguishing it from siblings like list_templates which would list multiple templates.

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?

No guidance is provided on when to use this tool versus alternatives such as list_templates or preview_email. The description only states what it does, leaving the agent without clear usage context or criteria for selection.

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

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

No annotations are provided, so the description carries the full burden for behavioral disclosure. While 'List' implies a read-only operation, the description does not mention pagination behavior, ordering, return format, or any side effects. It adds no behavioral context beyond the obvious action.

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 with a colon-delimited list. Every word earns its place, and the key information is front-loaded with the verb 'List'. There is no unnecessary fluff 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 read-only tool with two optional parameters and no output schema, the description is largely complete. It identifies the resource, the kinds of suppressions, and implicitly what the tool does. Minor gaps remain regarding the meaning of 'limit' and any return value structure, 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 description compensates for the 0% schema coverage by enumerating the allowed values for the 'kind' parameter (unsubscribes|bounces|blocks|spam_reports|invalid_emails), which are not defined as enums in the schema. However, it does not explain the 'limit' parameter, leaving its meaning to inference from the default value.

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

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

The description clearly states the tool lists a suppression list and enumerates the five kinds (unsubscribes, bounces, blocks, spam_reports, invalid_emails). This gives a specific verb, resource, and scope, and helps distinguish it from siblings like add_suppression or check_suppression, though it does not name them explicitly.

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 offers no guidance on when to use this tool versus alternatives such as check_suppression, add_suppression, or remove_suppression. It simply states what it does without context, prerequisites, or exclusions, leaving the agent to infer usage purely from the tool name and sibling list.

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

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

No annotations are provided, so the description carries full responsibility for behavioral transparency. It only states the tool lists templates and includes both dynamic and legacy, but it doesn't disclose how results are returned (e.g., array, pagination), whether any auth is needed, or if the operation is read-only. As a simple list operation, some low score is justified, but it doesn't go beyond what the name implies.

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 action and scope. There is no wasted wording, and it is front-loaded with the main purpose. This is appropriately minimal for a tool with no parameters.

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

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

The tool is very simple (0 params, no output schema), so the description is mostly sufficient. However, since there is no output schema, the description should at least hint at what is returned (e.g., an array of templates). It also omits any mention of authentication or administrative context. This is adequate for a trivial list operation but leaves a few gaps.

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

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

The tool has zero parameters, and the input schema is empty with 100% schema coverage. Per the rubric, a baseline of 4 applies when there are no parameters, since the description doesn't need to add parameter semantics. The description correctly focuses on the action and scope.

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 'List' with the resource 'transactional email templates' and clarifies it covers both dynamic and legacy types. This clearly distinguishes it from sibling tools like get_template (single template fetch) and preview_email (rendering preview). It doesn't explicitly name alternatives, but the verb+resource combination 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use list_templates over get_template, preview_email, or other siblings, nor any exclusions. The scope is implied by the name and verb, but no explicit usage context is given.

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 burden. It discloses key behaviors: the tool does not send, returns a single-use confirm_token valid for 10 minutes, and that sending must go through the token handoff. It also states the exact output (payload plus token) and design constraint on BCC.

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 short and front-loaded with the main purpose. Each sentence adds critical workflow information without redundancy, achieving high information density in three concise sentences.

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

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

For a tool with 10 parameters and no output schema, the description adequately covers the workflow, token expiry, and the necessity of calling send_email. However, it lacks details on validation error behavior and the exact structure of the returned payload, which slightly limits completeness given the schema's absence.

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 by explaining parameter meanings, but it only mentions BCC (which is not even a parameter). It does not explain how to, from_email, template_id, template_data, body_html, or other fields are used, leaving the agent without guidance beyond raw 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's function: 'Validate and render an email WITHOUT sending it.' It also distinguishes itself from the sibling send_email by explaining the token-based handoff and the absence of a direct-send path.

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 explains when to use this tool: it is a prerequisite for sending, as 'Sending requires passing that token to send_email — there is no direct-send path.' It also notes that BCC is not accepted, providing a clear constraint.

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

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

With no annotations, the description fully discloses key behaviors: it re-enables sending to non-compliant recipients, requires confirm=true, is rate-limited, and is audited. This goes well beyond basic mutation info and provides critical 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?

Two sentences: first states purpose, second packs critical warnings and constraints. Every word earns its place; no fluff 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?

The description covers the tool's danger, confirm requirement, rate limit, and audit trail, which are essential for safe use. However, it omits details on the 'kind' parameter and expected outcome/return, making it slightly incomplete for full autonomous 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 description coverage is 0%, so the description must compensate. It only mentions that confirm=true is required, leaving kind and email semantics unexplained. No enums or allowed values are provided for 'kind', leaving the agent to guess.

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

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

The description starts with 'Remove an address from a suppression list,' which is a specific verb+resource. It clearly distinguishes from sibling tools by noting the 'DANGEROUS direction' (re-enabling sending to bounced/unsubscribed), contrasting with add_suppression.

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 it: to re-enable sending to someone who bounced or unsubscribed, and warns of compliance violations. However, it doesn't explicitly name alternatives or state when not to use it beyond the danger warning.

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 to fall back on, the description provides essential behavioral context: it accepts only a confirm token, the payload cannot be altered, tokens are single-use and expire after 10 minutes, and dry-run mode (the default) simulates without sending. This is comprehensive and directly informs the agent of safety and constraints.

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

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

The description is three sentences long, front-loaded with the core action, and every sentence contributes meaningful information. There is 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 one-parameter tool with no output schema, the description covers the prerequisite (preview_email), token constraints, and default dry-run behavior, making it complete enough 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?

The only parameter, confirm_token, is thoroughly explained in the description: it is the token from preview_email, single-use, and expires in 10 minutes. This adds significant meaning beyond the bare input schema, fully compensating for the 0% schema description 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 explicitly states the tool's function: sending an email previously rendered by preview_email. This clearly distinguishes it from the sibling preview_email tool and makes 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 clearly implies the tool should be used after preview_email by stating it sends the email 'previously rendered.' However, it does not explicitly mention when not to use it or provide alternative tools for sending, so it falls short of a full 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 discloses the exact data returned and, importantly, that the API key itself is never included ('never the key'), which is a critical safety behavior. It does not mention side effects or return format, but a status tool is assumed read-only.

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

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

The description is a single, well-structured sentence that front-loads the subject ('This server's security posture') and immediately lists the key output fields. 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 no output schema and no annotations, the description is remarkably complete. It lists all the categories of information the tool returns, making it clear what the agent can expect. For a parameterless status tool, no additional context is necessary.

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 adds no parameter details because none are needed; the schema already documents the empty parameter list.

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 identifies the tool's purpose as reporting the server's security posture, listing specific fields (mode, rate-limit remaining, allowlist, caps, audit-log path, API key presence). While it lacks an explicit verb like 'get' or 'show', the intent is unambiguous and distinguishes it from sibling email tools.

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

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

The description implies when to use this tool: to inspect server security posture. It doesn't explicitly mention alternatives or exclusions, but given the sibling tools are email-focused, the context is clear enough that no further guidance is needed.

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