Server Quality Checklist

Tool Scores

• add_to_suppressionC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It mentions adding to a suppression list (implying a write/mutation operation) but doesn't address critical aspects like permissions needed, whether the action is reversible, rate limits, or what happens if emails are already suppressed. This leaves significant gaps for an agent.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.

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

  Completeness2/5

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

  For a mutation tool with no annotations and no output schema, the description is insufficient. It lacks information about behavioral traits (e.g., idempotency, error handling), expected outcomes, or how this tool relates to siblings like 'list_suppression'. The agent would need to guess about many operational aspects.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already fully documents both parameters (emails array and reason enum). The description doesn't add any parameter-specific context beyond what's in the schema, such as format requirements for emails or implications of different reason values, meeting the baseline for high schema coverage.

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

  Purpose4/5

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

  The description clearly states the action ('Add') and target resource ('email addresses to the suppression list'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_suppression' or explain what a suppression list is, preventing a perfect score.

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

  Usage Guidelines2/5

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

  No guidance is provided about when to use this tool versus alternatives like 'list_suppression' or 'list_emails', nor about prerequisites such as whether emails must be verified first. The description only states what it does, not when it should be used.

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

• create_batchC
  2.9/5.0
  Behavior2/5

  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. While 'create' implies a write operation, the description doesn't address critical behavioral aspects: whether this is an asynchronous job, what permissions are required, if there are rate limits, what happens on failure, or what the expected output looks like. It mentions the action but lacks operational context needed for safe invocation.

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

  Conciseness5/5

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

  The description is perfectly concise - a single sentence that communicates the core purpose without any wasted words. It's front-loaded with the essential information and earns its place efficiently. No structural issues or unnecessary elaboration are present.

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

  Completeness2/5

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

  For a complex mutation tool with 8 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't address the asynchronous nature implied by 'batch job', doesn't explain what happens after creation, doesn't mention error handling, and provides no context about how this integrates with sibling tools. The agent lacks critical operational understanding.

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

  Parameters3/5

  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 8 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters (e.g., 'html' vs 'templateId'), provide examples, or clarify edge cases. The baseline score of 3 reflects adequate but minimal value addition.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Create a batch email job to send to multiple recipients'. It specifies the verb ('create'), resource ('batch email job'), and scope ('to multiple recipients'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'send_email' or 'create_template', which would be needed for a perfect score.

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

  Usage Guidelines2/5

  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. There's no mention of when to choose 'create_batch' over 'send_email' (for single emails) or 'create_template' (for reusable templates), nor any context about prerequisites, timing considerations, or exclusions. The agent must infer usage from the name and parameters alone.

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

• create_templateC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but only states it creates a template without disclosing behavioral traits. It doesn't mention permissions required, whether creation is idempotent, rate limits, or what happens on success/failure (e.g., returns a template ID). This leaves 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.

  Conciseness5/5

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

  The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.

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

  Completeness2/5

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

  Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after creation (e.g., returns a template ID for use in 'send_email'), error conditions, or dependencies on other tools like 'verify_domain'. More context is needed for effective use.

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

  Parameters3/5

  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 parameters (name, subject, html, text). The description adds no additional meaning beyond implying these parameters are used for creation, which is already clear from the tool name. Baseline 3 is appropriate as the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('Create') and resource ('new email template'), making the purpose immediately understandable. However, it doesn't distinguish this from sibling tools like 'list_templates' or 'get_email', which would require mentioning it's specifically for creation rather than retrieval or listing.

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

  Usage Guidelines2/5

  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. There's no mention of prerequisites (e.g., needing a verified domain), when not to use it, or how it differs from sibling tools like 'send_email' or 'create_batch' for email-related tasks.

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

• get_analyticsC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but only states what the tool does, not how it behaves. It doesn't disclose whether this is a read-only operation, what permissions are needed, if there are rate limits, or what format the analytics return. This is inadequate for a tool with no 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.

  Conciseness5/5

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

  The description is a single, efficient sentence with zero wasted words. It's appropriately sized and front-loaded with the core purpose.

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

  Completeness2/5

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

  For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what analytics are returned, their format, or any behavioral constraints. The agent would be guessing about the tool's behavior and output.

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

  Parameters3/5

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

  The description adds no parameter information beyond what's already in the schema (which has 100% coverage). It doesn't explain what 'summary' vs 'daily' analytics include, or how the 'days' parameter affects results. Baseline 3 is appropriate since the schema does the heavy lifting.

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

  Purpose4/5

  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 'email analytics and statistics', making the purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling analytics tools (none exist in the sibling list), so it's not a perfect 5.

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

  Usage Guidelines2/5

  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. There's no mention of prerequisites, context, or comparison with other tools like 'get_email' or 'list_emails' that might provide related data.

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

• get_batchC
  2.9/5.0
  Behavior2/5

  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 states this is a 'Get' operation, implying it's read-only, but doesn't confirm safety aspects like whether it requires authentication, has rate limits, or what happens with invalid IDs. The description adds minimal behavioral context beyond the basic action, leaving gaps for a tool that likely interacts with batch processing systems.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose ('Get batch job status and progress'), and every word earns its place by specifying what is retrieved. No unnecessary details or redundancy are present.

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

  Completeness2/5

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

  Given the complexity of batch job operations, the lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'status and progress' entails (e.g., success/failure states, percentage completion, error messages) or the return format. For a tool with potential behavioral nuances, this minimal description leaves too much unspecified.

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

  Parameters3/5

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

  The input schema has 100% description coverage, with the 'id' parameter documented as 'Batch ID'. The description doesn't add any meaning beyond this (e.g., explaining where to find the ID or its format). According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.

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

  Purpose4/5

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

  The description clearly states the verb ('Get') and resource ('batch job status and progress'), making the purpose immediately understandable. It doesn't specifically differentiate from sibling tools like 'list_batches' or 'create_batch', but the focus on retrieving status/progress for a specific batch is clear. No tautology or misleading elements are present.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'list_batches' (which likely lists multiple batches) or 'create_batch' (which creates new batches). There's no mention of prerequisites (e.g., needing a batch ID from a previous operation) or context for when this specific retrieval is appropriate. Usage is implied but not explicitly stated.

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

• send_emailC
  2.9/5.0
  Behavior2/5

  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. While 'Send' implies a write operation, the description doesn't mention authentication requirements, rate limits, delivery guarantees, error handling, or what happens on success/failure. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps that could affect agent decision-making.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for the tool's complexity and immediately communicates the core function without unnecessary elaboration.

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

  Completeness2/5

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

  For a 10-parameter mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address critical context like authentication requirements, rate limits, error conditions, or what constitutes a successful operation. The agent would need to guess about behavioral aspects that should be documented for a tool that sends emails.

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

  Parameters3/5

  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 10 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description, which applies here.

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

  Purpose4/5

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

  The description clearly states the action ('Send') and resource ('transactional email via GetMailer'), making the purpose immediately understandable. However, it doesn't differentiate this from potential sibling tools like 'create_batch' or other email-related operations, which would require more specific context about what makes this 'transactional' versus other email types.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'create_batch' or template-based operations. It mentions 'transactional email' but doesn't explain what that means in practice or when other tools might be more appropriate. There are no usage prerequisites, exclusions, or comparisons to sibling tools.

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

• verify_domainC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but offers minimal behavioral context. It doesn't disclose whether this is a read-only operation, what permissions are required, what the response format looks like, or how verification status is determined. The description simply restates the basic function without adding meaningful behavioral details.

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

  Conciseness5/5

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

  The description is perfectly concise at just 6 words, front-loading the essential information with zero wasted words. Every word earns its place in communicating the core function without unnecessary elaboration.

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

  Completeness2/5

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

  For a verification tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'verified' means in this context, what verification entails, what the response will contain, or how this differs from simply listing domains. The minimal description leaves too many contextual questions unanswered.

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

  Parameters3/5

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

  With 100% schema description coverage, the schema already documents the single 'id' parameter adequately. The description doesn't add any additional context about parameter meaning, format expectations, or how to obtain domain IDs. This meets the baseline for high schema coverage but doesn't enhance understanding beyond what the schema provides.

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

  Purpose4/5

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

  The description clearly states the tool's purpose with a specific verb ('Check') and resource ('domain'), making it immediately understandable. However, it doesn't differentiate from sibling tools like 'list_domains' or 'get_analytics' which might also provide domain status information, preventing a perfect score.

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

  Usage Guidelines2/5

  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. With siblings like 'list_domains' that might show verification status, there's no indication whether this tool is for checking a specific domain's verification status after adding it, or if it's the preferred method over other listing tools.

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

• add_domainB
  3.1/5.0
  Behavior2/5

  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 indicates a write operation ('Add') and mentions the output ('returns DNS records to configure'), but fails to disclose critical traits such as permissions required, whether the operation is idempotent, potential side effects, or error conditions. This leaves significant gaps in understanding the tool's behavior.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core action and resource, followed by the key outcome. There is no wasted verbiage, and every word earns its place, making it highly concise and well-structured for quick comprehension.

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

  Completeness3/5

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

  Given the tool's moderate complexity (a write operation with one parameter) and lack of annotations and output schema, the description is minimally adequate. It covers the basic purpose and output but omits details on usage context, behavioral traits, and error handling. This results in a description that meets the bare minimum but leaves the agent with unanswered questions.

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

  Parameters3/5

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

  The schema description coverage is 100%, with the single parameter 'domain' well-documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as format constraints or examples. Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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

  Purpose4/5

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

  The description clearly states the action ('Add') and resource ('new sending domain'), making the purpose immediately understandable. It distinguishes this from sibling tools like 'list_domains' or 'verify_domain' by focusing on creation rather than listing or verification. However, it doesn't explicitly contrast with all siblings, keeping it from a perfect score.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'verify_domain' or other domain-related operations. It mentions the return value ('returns DNS records to configure'), which hints at a post-creation step, but lacks explicit when-to-use or when-not-to-use instructions, leaving the agent to infer context.

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

• get_emailB
  3.1/5.0
  Behavior2/5

  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 mentions 'delivery events' as part of the details, which adds some context beyond a basic read operation, but fails to address critical aspects like permissions needed, rate limits, error conditions, or whether the operation is idempotent. For a tool with zero annotation coverage, this leaves significant gaps.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded with the core functionality.

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

  Completeness3/5

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

  Given the tool's moderate complexity (single parameter read operation), no annotations, and no output schema, the description is minimally adequate. It specifies the resource and includes 'delivery events' as extra detail, but lacks information on return values, error handling, or behavioral constraints, leaving room for improvement in completeness.

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

  Parameters3/5

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

  The schema description coverage is 100%, with the single parameter 'id' clearly documented as 'Email ID'. The description does not add any additional meaning or context about the parameter beyond what the schema provides, such as format examples or sourcing guidance. With high schema coverage, 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.

  Purpose4/5

  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 'details of a specific email including delivery events', which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'list_emails' or 'get_batch', which would require a 5.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'list_emails' or 'get_batch', nor does it mention prerequisites or exclusions. It only states what the tool does, not when to apply it.

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

• list_emailsB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It mentions 'status information' but doesn't disclose behavioral traits like pagination behavior (implied by cursor parameter), rate limits, authentication needs, or what specific statuses are returned. For a list operation with no annotation coverage, this leaves significant gaps in understanding how the tool behaves.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and includes a clarifying detail ('with status information'). Every word earns its place, making it easy to parse quickly.

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

  Completeness3/5

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

  Given the tool's moderate complexity (list operation with pagination), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, output format, or usage context. It meets the minimum viable threshold but has clear gaps in completeness for effective tool selection.

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

  Parameters3/5

  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 (limit and cursor) fully. The description doesn't add any parameter-specific meaning beyond what the schema provides, such as default behavior or usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the verb ('List') and resource ('sent emails'), specifying scope with 'with status information'. It distinguishes from siblings like 'get_email' (singular) and 'send_email' (action), but doesn't explicitly differentiate from other list tools like 'list_batches' or 'list_templates'.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus alternatives is provided. It doesn't mention prerequisites, context for listing sent emails specifically, or compare with siblings like 'get_email' for single emails or 'list_batches' for batch operations. The description only states what it does, not when to choose it.

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

• list_templatesB
  3.1/5.0
  Behavior2/5

  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 states the action ('List') but doesn't describe what 'available' means (e.g., all templates, only active ones), whether it requires authentication, pagination behavior, rate limits, or the return format. This leaves significant gaps for a tool that presumably returns data.

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

  Conciseness5/5

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

  The description is a single, efficient sentence ('List available email templates') that front-loads the core action and resource. It wastes no words, making it easy to parse quickly, which is ideal for a simple tool with no parameters.

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

  Completeness2/5

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

  Given the tool's simplicity (0 parameters) and lack of output schema, the description is minimal. However, with no annotations to cover behavioral aspects like safety or return format, and the description not addressing these, it's incomplete. For a list operation, agents need to know what 'available' entails and the response structure, which is missing here.

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

  Parameters4/5

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

  The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, and since there are none, it doesn't need to compensate for any gaps. A baseline of 4 is given as it avoids unnecessary parameter details.

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

  Purpose4/5

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

  The description 'List available email templates' clearly states the verb ('List') and resource ('email templates'), making the purpose immediately understandable. It distinguishes from siblings like 'create_template' (creation) and 'list_emails' (different resource), though it doesn't explicitly differentiate from 'list_batches' or 'list_domains' beyond the resource name.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing templates to exist), exclusions, or comparisons to siblings like 'get_email' or 'list_emails', leaving the agent to infer usage from context alone.

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

• list_batchesB
  3.2/5.0
  Behavior2/5

  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. 'List batch email jobs' implies a read-only operation but doesn't specify whether it returns all batches, supports pagination, includes metadata (e.g., status, dates), or has rate limits. For a list tool with zero annotation coverage, this is a significant gap in transparency about how the tool behaves.

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

  Conciseness5/5

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

  The description is a single, efficient sentence ('List batch email jobs') with zero wasted words. It is front-loaded and directly states the core functionality without unnecessary elaboration. This is appropriately sized for a simple list tool with no parameters.

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

  Completeness3/5

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

  Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally complete. It states what the tool does but lacks behavioral details (e.g., return format, pagination) that would be helpful for an agent. Without annotations or output schema, the description should ideally provide more context about the listing behavior, but it's adequate for basic understanding.

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

  Parameters4/5

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

  The input schema has 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description doesn't add parameter details, which is appropriate since there are none. Baseline is 4 for 0 parameters, as no compensation is needed, and the description correctly implies no filtering or options are required.

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

  Purpose4/5

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

  The description 'List batch email jobs' clearly states the verb ('List') and resource ('batch email jobs'), making the purpose immediately understandable. It distinguishes from siblings like 'get_batch' (which likely retrieves a single batch) and 'create_batch' (which creates one), though it doesn't explicitly differentiate them. The purpose is specific but lacks explicit sibling comparison.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., after creating batches), or exclusions (e.g., not for filtering or analytics). With siblings like 'get_batch' for single batches and 'get_analytics' for performance data, the lack of usage guidelines leaves the agent to infer based on tool names alone.

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

• list_domainsB
  3.2/5.0
  Behavior2/5

  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 only states what the tool does ('List verified sending domains') without explaining what 'verified' means, how results are returned (e.g., pagination, format), or any constraints like rate limits or authentication needs. This leaves significant gaps for a tool that likely interacts with a domain management system.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with no wasted words. It is front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by conveying essential information.

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

  Completeness3/5

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

  Given the tool's simplicity (0 parameters, no output schema), the description is adequate as a minimum viable explanation. However, it lacks context about what 'verified' entails, how results are structured, or any behavioral traits, which could be important for an AI agent to use it effectively. Without annotations or output schema, more detail would improve completeness.

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

  Parameters4/5

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

  The tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, but it appropriately doesn't mention any. A baseline of 4 is applied for zero-parameter tools when the schema is fully covered.

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

  Purpose4/5

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

  The description clearly states the verb ('List') and resource ('verified sending domains'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_batches' or 'list_templates' beyond the resource type, which prevents a perfect score.

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

  Usage Guidelines2/5

  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. For example, it doesn't specify if this should be used before 'verify_domain' or after 'add_domain', nor does it mention any prerequisites or exclusions for usage.

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

• list_suppressionB
  3.3/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions what types of suppressions are included but doesn't cover pagination behavior, sorting, default ordering, error conditions, or authentication requirements. For a list operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a simple list operation and front-loads the essential information immediately.

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

  Completeness3/5

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

  For a simple list tool with one parameter and no output schema, the description is adequate but incomplete. It covers what's being listed but lacks context about return format, typical result structure, or how results are organized. Without annotations or output schema, more behavioral context would be helpful.

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

  Parameters3/5

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

  Schema description coverage is 100% for the single parameter, so the schema already documents the 'limit' parameter fully. The description adds no parameter-specific information beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.

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

  Purpose5/5

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

  The description clearly states the specific action ('List') and resource ('suppressed email addresses'), with explicit scope details ('bounced, complained, or manually added'). It distinguishes this tool from siblings like list_domains or list_emails by focusing on suppression status rather than general listings.

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

  Usage Guidelines2/5

  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. While the purpose is clear, there's no mention of prerequisites, typical use cases, or how it differs from other list operations like list_emails or get_email. The description assumes context without providing it.

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