Server Quality Checklist

Tool Scores

• send_draftA
  3.6/5.0
  Behavior1/5

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

  The description contradict the annotations: annotation declares idempotentHint=true, but the description explicitly warns 'must NOT be retried' when pending approval, implying non-idempotent behavior. This is a direct contradiction. Per scoring rules, this dimension scores 1. The description otherwise adds good behavioral detail (pending approval status, immediate send), but the contradiction overrides.

  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 three sentences long, each serving a purpose: stating the action, providing usage context, and explaining the two possible outcomes. It is front-loaded with the core purpose and contains no fluff or redundancy.

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

  Completeness4/5

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

  Given no output schema, the description adequately explains return values (202 with pending_approval or immediate message ID). It covers the main behavioral aspects. However, it does not mention error scenarios (e.g., draft not found, already sent) or address the idempotency conflict, leaving minor gaps. Overall, it is fairly complete.

  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% coverage with a clear description for the single 'id' parameter. The description adds no additional parameter semantics beyond what the schema provides. Baseline score of 3 is appropriate.

  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 action ('Send a draft you prepared, by its id') and the tool's resource ('draft'). It distinguishes from sibling tools like send_email and reply_email by focusing on draft sending. The two modes (immediate vs pending approval) are succinctly described, making the purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description explicitly says 'Call this when a staged draft is ready to go out.' It also provides crucial guidance on the pending approval case: 'NOT a failure and must NOT be retried.' While it does not explicitly compare to send_email as an alternative, the draft context implies the distinction. The guidance is clear and actionable.

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

• create_draftA
  4.2/5.0
  Behavior3/5

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

  Annotations are minimal (all hints false), so the description carries the burden. It adds that the tool returns a draft ID with status 'draft', which is helpful. However, it does not disclose behavioral traits like non-idempotency (multiple calls create multiple drafts) or any side effects beyond creation. The description does not contradict 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.

  Conciseness5/5

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

  The description is three sentences that front-load the core purpose, immediately follow with usage guidance, and end with return format. Every sentence earns its place with no redundancy or fluff. It is perfectly scoped for the tool's complexity.

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

  Completeness4/5

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

  Given 5 parameters, no output schema, and moderate complexity, the description covers the main points: purpose, two usage modes, and return structure. It could mention that drafts are persisted per mailbox and that the tool is not idempotent, but these gaps are minor. The sibling tool set (list_drafts, get_draft, update_draft, send_draft) fills in some missing context, and the description is sufficiently complete for correct agent invocation.

  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?

  Schema coverage is 100% with good descriptions for all parameters. The main description adds value by explaining how parameters interact: 'Same fields as send_email, or omit to/subject and pass reply_to_message_id to draft a threaded reply.' This provides pragmatic usage guidance beyond the schema's individual parameter descriptions, especially for the conditional omission of to and subject.

  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 tool prepares an email draft without sending it, using the specific verb 'prepare' and the resource 'draft'. It explicitly distinguishes from the sibling send_draft and send_email, and also mentions an alternative usage for threaded replies via reply_to_message_id, making the purpose unmistakable.

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

  Usage Guidelines4/5

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

  The description gives explicit context: 'Call this when you want to stage a message for later or for a human to review before it goes out — send it afterward with send_draft.' This tells when to use the tool and points to the sibling for the next step. It also explains the alternative threading workflow. However, it doesn't explicitly state when not to use it (e.g., if immediate sending is needed, use send_email), but the context is strong enough for a high score.

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

• list_draftsA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds value by specifying the status filter and ordering (newest first). It does not contradict annotations and provides useful behavioral context beyond what is in the schema.

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

  Conciseness5/5

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

  Two sentences with no fluff. The first sentence states what the tool does and the ordering; the second gives explicit usage context. Every sentence earns its place.

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

  Completeness4/5

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

  For a simple single-parameter tool with strong annotations, the description covers purpose, usage scenario, and output ordering. It does not specify error behavior or return format, but the core information is present. Given no output schema, the description does enough.

  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% (mailbox_id is described well). The tool description does not add any extra meaning beyond what the schema already provides, so baseline 3 is appropriate.

  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 verb 'list' and the resource 'open drafts in a mailbox', specifying the statuses (draft, pending_approval, sending) and ordering (newest first). This distinguishes it from siblings like list_inbox, get_draft, and others.

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

  Usage Guidelines4/5

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

  The description explicitly says when to call this tool: to see staged or queued messages, with a concrete example after a send returns 'pending_approval'. While it doesn't explicitly name alternatives or when-not-to-use, the context is strong enough for an agent to differentiate.

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

• list_inboxA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows it is a safe read. The description adds that results are sorted newest first and include comprehension status, which is useful beyond the annotations. No contradictions are present.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the primary purpose and then usage guidance. Every word serves a purpose, no redundancy or filler.

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

  Completeness4/5

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

  Given the tool's simplicity (2 parameters, 100% schema coverage, no output schema, and annotations present), the description adequately covers what it does, when to use it, and how it differs from a key sibling. It could optionally mention pagination or return format, but for a listing tool this is sufficient.

  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 coverage is 100%, so the baseline is 3. The description does not add any additional meaning to the parameters beyond what the schema already provides (mailbox_id is required, limit is optional with range). The mention of 'newest first' is ordering behavior, not parameter semantics.

  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 tool lists recent messages in a mailbox, with ordering (newest first) and includes comprehension status. It distinguishes itself from the sibling 'read_email' by noting that this tool is for checking arrivals while read_email provides full content and extracted data.

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

  Usage Guidelines4/5

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

  The description explicitly says 'Call this when checking what has arrived; use read_email for full content and extracted data.' This provides a clear when-to-use and an alternative. However, it does not mention when not to use it (e.g., for searching or filtering), which would elevate it to a 5.

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

• get_draftA
  4.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true, fully covering the safety and idempotency profile. The description adds value by specifying the exact fields returned (recipient, subject, body, status), but this is more about return structure than behavioral traits. No contradiction.

  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?

  Two sentences with zero wasted words. First sentence delivers purpose and return content. Second sentence provides usage context and rationale. Highly efficient and front-loaded.

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

  Completeness5/5

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

  The tool has 1 parameter (fully documented), no output schema, but the description lists return fields. Combined with sibling tools and annotations, this provides complete context for a simple read operation. The agent knows what to expect and when to invoke it.

  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% with the 'id' parameter already described as 'Id of the draft to read, from create_draft or list_drafts.' The tool description does not add any additional semantic meaning beyond what the schema provides, so baseline 3 is appropriate.

  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 verb 'Read', the resource 'one draft in full by its id', and explicitly lists the fields returned (recipient, subject, body text, current status). This distinguishes it from siblings like 'list_drafts' which returns a summary list, and 'update_draft' which modifies.

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

  Usage Guidelines5/5

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

  The description explicitly tells when to use this tool: 'when you need the content of a specific draft', and provides concrete examples: 'to review what is queued for approval after list_drafts, or before editing it with update_draft'. This also implies alternatives (list_drafts, update_draft), giving excellent guidance.

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

• list_mailboxesA
  4.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is clear. The description adds useful ordering ('newest first') and scoping behavior (single mailbox vs all account). However, it doesn't disclose pagination limits, data freshness guarantees, or what happens if API key is invalid.

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

  Conciseness4/5

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

  Three sentences, each serving a distinct purpose (what, when, edge cases). Slightly verbose in the second sentence, but no wasted words. Could merge scoping info into first sentence for better front-loading.

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

  Completeness5/5

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

  Given zero parameters, no output schema, and annotations covering safety/idempotency, the description fully addresses what an agent needs: purpose, usage guidance (including when to call first), scope behavior, and empty list handling. No gaps remain for this simple tool.

  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?

  Schema has 0 parameters (100% coverage), so the description need not add param info. The description still adds meaning by specifying output structure (id, email) and behavior not in schema (newest first, scoping rules), going above baseline 3.

  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 provides a specific verb ('List') and resource ('mailboxes') with clear behavioral details (newest first, what each returns). It distinguishes itself from sibling tools like create_mailbox and list_inbox by focusing solely on mailbox enumeration.

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

  Usage Guidelines5/5

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

  Explicitly tells when to use this tool ('first call in a workflow', when you need a mailbox_id) and when not to use alternatives ('check whether you already have a mailbox before creating one', implying create_mailbox is alternative). Also handles edge cases like empty results and API key scoping.

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

• read_emailA
  4.4/5.0
  Behavior4/5

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

  Annotations already mark the tool as readOnlyHint=true, so the description's disclosure of read behavior is not additional. However, the description adds significant value by detailing what the tool returns (cleaned body, sanitization report, classification, extracted data), which goes well beyond the annotations. 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.

  Conciseness5/5

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

  Two sentences that are entirely informative. The first sentence enumerates the return values, the second provides the usage cue. No filler, redundant phrases, or unnecessary elaboration.

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

  Completeness4/5

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

  Given the complexity (single parameter, no output schema), the description is nearly complete: it specifies what the tool does, what it returns, and when to call it. It could be slightly more complete by mentioning if the cleaned body includes attachments or by clarifying the 'sanitization report' and 'classification' in more detail, but for a single-param tool this is very strong.

  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?

  Schema description coverage is 100%, so the baseline is 3. The description adds context by explaining the type of usage (reading a message, getting extraction), but does not add new semantic details about the message_id parameter beyond what the schema already provides (type, format, and source hint). A small lift over baseline due to usage context.

  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 verb 'read' and resource 'one email', explicitly listing what the result includes (body, sanitization report, classification, extracted data). It distinguishes itself from siblings like list_inbox and wait_for_email by specifying this is for reading a specific message in full.

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

  Usage Guidelines4/5

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

  The description includes the explicit usage trigger 'Call this when you need the content or extraction of a specific message.' This provides clear context for when to use it. However, it does not mention when not to use it (e.g., if only basic metadata is needed, list_inbox might be more efficient) or explicitly name alternatives.

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

• wait_for_emailA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, so the tool is safe and idempotent. The description adds key behavioral context: it blocks, can time out, and returns a specific structure on timeout ({timed_out:true}). It doesn't mention rate limits or resource consumption, but for a read-only blocking poller with annotations, this is strong.

  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 two sentences long with no wasted words. It front-loads the core behavior ('Block until...'), then gives usage guidance, and finally notes the return value. Every sentence earns its place.

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

  Completeness4/5

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

  Given the tool has no output schema, the description compensates by explaining the return format (full message or {timed_out:true}). It doesn't explicitly state all possible return fields, but for a waiting tool with good annotations and schema, it's nearly complete. A mention of the format of the returned message would push this to 5.

  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%, with all 4 parameters clearly documented. The description mentions the return format but adds no additional parameter semantics beyond the schema. Baseline 3 is appropriate.

  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 tool blocks until a matching email arrives or times out, using specific verbs ('Block', 'wait') and the resource ('email in a mailbox'). It distinguishes itself from siblings like list_inbox by explicitly saying it replaces polling.

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

  Usage Guidelines5/5

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

  The description explicitly tells when to use the tool: 'Call this when you just sent an email and need the reply, or are expecting an inbound message — instead of polling list_inbox yourself.' This provides clear context and mentions the alternative (list_inbox) to avoid.

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

• update_draftA
  4.5/5.0
  Behavior4/5

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

  The description discloses key behavioral details beyond annotations: 'omitted fields keep their current value' clarifies partial update semantics, and it specifies the unchangeability of the reply target and the constraint that sending drafts cannot be edited. With annotations already marking idempotentHint=true and destructiveHint=false, the description adds valuable context 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.

  Conciseness4/5

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

  Two sentences form the core description, with a third sentence providing key constraints. It's front-loaded with the primary action, followed by usage guidance and limitations. Every sentence adds important information without redundancy, though the last sentence could be slightly more concise.

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

  Completeness4/5

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

  Given the tool's complexity (4 params, no output schema, no nested objects) and rich sibling set, the description is sufficiently complete. It covers the operation, parameters, constraints, and usage context. The only minor gap is that it doesn't explicitly state what happens on success (e.g., returns the updated draft), but the schema doesn't promise an output, so this is acceptable.

  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?

  Schema coverage is 100%, so the baseline is 3. The description adds meaning by clarifying that omitted fields retain their current values, which maps directly to the optional parameters (to, text, subject). It also reiterates that the id is required. This semantic explanation goes beyond what the schema provides, earning a 4.

  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 'Edit the to, subject, or text of a draft', specifying the exact verb (edit) and resource (draft), and lists which fields can be changed. It distinguishes itself from siblings like 'create_draft' (which is for creating new drafts) and 'send_draft' (which sends rather than edits), making the purpose unambiguous.

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

  Usage Guidelines5/5

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

  The description explicitly tells when to use the tool: 'Call this when a draft needs changes, e.g. a human declined to approve it and you are revising it.' It also provides important exclusions: 'The reply target cannot be changed (create a new draft to reply to a different message)' and 'a draft that is already sending or sent can no longer be edited.' This offers excellent guidance on when not to use it and alternatives.

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

• create_mailboxA
  4.6/5.0
  Behavior4/5

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

  Annotations are minimal (readOnlyHint=false, destructiveHint=false), so the description bears the burden. It discloses that mailboxes persist across sessions, returns a working address immediately, explains slug personalization (agent-<slug>@...), and notes that custom domains must be verified. No contradictions 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.

  Conciseness5/5

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

  Five tight sentences, front-loaded with the core action and usage guidance. Every sentence adds value—no filler, no redundancy. The structure logically flows from purpose to when-to-use to parameter details.

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

  Completeness4/5

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

  Given 4 optional parameters, no output schema, and minimal annotations, the description covers the essential behavioral context: creation semantics, persistence, duplication consequences, and domain verification requirement. It references sibling tools appropriately. Minor gaps include lack of error scenarios or rate limits, but overall complete for a creation tool.

  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?

  Schema coverage is 100%, providing a baseline of 3. The description adds meaningful context beyond the schema: clarifies that slug produces 'agent-<slug>@...', explains domain_id must come from list_domains and be verified, and notes that omitting extraction_schema_id yields cleaned messages without structured extraction.

  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 starts with 'Create a NEW email mailbox this agent owns', using a specific verb and resource. It clearly distinguishes from sibling tools like list_mailboxes (which checks existing mailboxes) and list_domains (which provides domain IDs for customization).

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

  Usage Guidelines5/5

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

  Explicitly states 'Call this when list_mailboxes shows you have no suitable mailbox yet' and warns against creating duplicates because 'mailboxes persist across sessions, so creating a second one for the same purpose strands mail in the first.' Also guides use of domain_id from list_domains for custom domains, including the verification requirement.

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

• list_domainsA
  4.6/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe, read-only operation. The description adds valuable context about what status means ('verified' domains can host mailboxes) and the implication of an empty list (only shared platform domain available). This exceeds the annotation baseline.

  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?

  All three sentences are meaningful and non-redundant. The purpose is front-loaded, usage guidance follows, and the status constraint is stated clearly. No wasted words.

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

  Completeness4/5

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

  With no parameters and basic output, the description covers all needed information: purpose, when to use, status semantics, and downstream usage. The only minor gap is not explaining what happens if the account has no custom domains (returns empty list), but the description does describe 'an empty list means only the shared platform domain is available'.

  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 no parameters, so the description doesn't need to document any. However, it goes beyond by explaining what the returned data includes (id, name, verification status) and how to use it downstream, which is especially helpful with no output schema.

  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 uses 'List the account's custom sending domains' which clearly identifies the verb and resource. It distinguishes itself from siblings like list_mailboxes by specifying it returns domains with id, name, and verification status.

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

  Usage Guidelines5/5

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

  The description explicitly states when to call this tool: 'when you want to create a mailbox on a custom domain' and 'to check whether a domain has finished verifying'. It provides alternatives by explaining the shared platform domain is available when the list is empty, and specifies that only verified domains can be used.

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

• send_emailA
  4.8/5.0
  Behavior5/5

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

  Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds crucial behavioral details: the client_id guarantees at-most-once delivery, the pending_approval draft response is not a failure, and how to handle that case. No contradictions 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.

  Conciseness5/5

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

  Four sentences, each carrying essential information: main action, sibling distinction, idempotency rule, and approval handling. No filler, front-loaded with the primary purpose. Highly efficient.

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

  Completeness4/5

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

  The description covers purpose, usage, idempotency, and the approval edge case. However, it does not describe the normal success response (e.g., returns a messageId). Since there is no output schema, this is a minor gap. Still, it is largely complete for an agent to use correctly.

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

  Parameters4/5

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

  Schema coverage is 100% (all parameters described). The description adds value beyond the schema by explaining the client_id's role as an idempotency key, reuse strategy, and the 'draft:' prefix restriction. It also mentions mailbox_id comes from list_mailboxes. This extra context justifies a 4, as the schema already provides good baseline.

  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 starts with 'Send a new email from one of your mailboxes' – a specific verb and resource. It explicitly distinguishes from reply_email by stating when to use each tool (new conversation vs. replying), which differentiates it from siblings.

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

  Usage Guidelines5/5

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

  Provides clear when-to-use (starting a new conversation) and when-not-to (use reply_email for replies). Also explains idempotency via client_id reuse and the human approval scenario with specific instructions not to retry and to check list_drafts instead.

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

• delete_draftA
  4.9/5.0
  Behavior5/5

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

  The description complements the annotations (destructiveHint: true, idempotentHint: true) by detailing the specific behavioral trait that a draft already sending or sent cannot be deleted, and clarifies that the action is irreversible in terms of enabling future sending. There is 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.

  Conciseness5/5

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

  The description is three sentences with zero wasted words. Each sentence serves a distinct purpose: stating the core action and effect, providing when-to-use scenarios, and giving an important constraint. It is front-loaded with the key verb and resource.

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

  Completeness5/5

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

  For a tool with a single documented parameter, clear annotations, and no output schema, the description is fully complete. It explains the tool's action, valid usage scenarios, a critical restriction, and does not need to describe return values since none are required.

  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 sole parameter 'id' is fully described in the schema (format, pattern, source). The description adds usage context (the draft must be in a deletable state), but since schema coverage is already 100% with a good description, the baseline is high. Score 4 because the description adds useful behavioral context beyond the schema's type/format info.

  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 states the verb ('discard') and the resource ('a draft by its id'), clearly differentiates the outcome ('so it will never be sent'), and distinguishes it from the 'send_draft' or 'reply_email' siblings by specifying that the tool is for withdrawal before sending.

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

  Usage Guidelines5/5

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

  The description explicitly states when to call this tool ('a staged or pending-approval message should be withdrawn — e.g. it is no longer needed or was created by mistake') and provides clear exclusion criteria ('A draft that is already sending or sent cannot be deleted'), guiding the agent away from inappropriate use.

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

• reply_emailA
  4.9/5.0
  Behavior5/5

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

  Annotations declare idempotentHint=true and destructiveHint=false. The description explains BOTH: idempotency via client_id (how it works, retry behavior, and that a new client_id sends a second copy) and the non-destructive 'pending_approval' case (not a failure, check with list_drafts). This exceeds annotation-only info.

  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?

  Three sentences, zero wasted words. Each sentence delivers critical payload: first sentence establishes purpose, second sentence covers idempotency mechanics, third sentence clarifies the draft-approval edge case. Perfect density.

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

  Completeness5/5

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

  Given 4 required params with full schema coverage, no output schema, and the domain (email reply), the description covers all behavior: idempotency, threading derivation, pending-approval workflow, and sibling differentiation. Nothing essential is missing.

  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?

  Schema coverage is 100% with good descriptions for each param. The description adds value by clarifying how reply_to_message_id drives recipient/subject/threading automatically, and giving extra context on client_id behavior (idempotency, reuse rule, 'draft:' prefix restriction) beyond the schema.

  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 starts with 'Reply to an email you received' which is a specific verb-resource pair. It clearly distinguishes from siblings like send_email (new email) and create_draft (new draft) by stating it derives recipient/subject/threading from the original message.

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

  Usage Guidelines5/5

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

  Explicitly says 'Call this when answering an existing message' and contrasts with alternatives by noting that send_email would be for new messages. Also provides guidance on when to retry and when not to retry (pending_approval case).

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