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

Annotations already indicate read-only, idempotent, and non-destructive behavior, which the description does not contradict. The description adds valuable context beyond annotations by specifying the requirement for the 'x-inbound-mailbox header,' the default sorting ('unread emails shown first by default'), and the inbound filtering ('emails sent TO your mailbox address'), enhancing transparency without redundancy.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by prerequisites and behavioral details in subsequent sentences, all without wasted words. Each sentence adds essential information (e.g., header requirement, filtering scope, default sorting), making it highly efficient and well-structured.

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

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

Given the tool's moderate complexity (4 parameters, no output schema) and rich annotations (read-only, idempotent), the description is largely complete, covering purpose, prerequisites, and key behaviors like default sorting. However, it lacks details on response format or error handling, which could be useful since there's no output schema, leaving a minor gap.

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

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

Schema description coverage is 100%, with all parameters well-documented in the schema (e.g., status filter with default 'unread', limit range, offset for pagination, time range options). The description does not add any parameter-specific details beyond what the schema provides, so it meets the baseline for high schema coverage without extra value.

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

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

The description clearly states the specific action ('check'), resource ('agent mailbox'), and scope ('for incoming emails'), distinguishing it from siblings like 'list_emails' or 'get_email' by focusing on the agent's own mailbox with inbound filtering. It explicitly mentions 'emails sent TO your mailbox address,' which clarifies its unique role.

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

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

The description provides clear context for usage by specifying 'Requires the x-inbound-mailbox header to be set' and that it returns 'emails sent TO your mailbox address,' which implicitly differentiates it from tools like 'list_emails' that might list all emails. However, it does not explicitly state when not to use it or name alternatives, such as 'get_email' for specific emails.

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

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

Annotations indicate this is a non-readOnly, non-idempotent, non-destructive operation, which the description aligns with by implying creation (a write action). The description adds value beyond annotations by specifying the delivery methods (webhooks and email forwards), but does not disclose additional behavioral traits like rate limits, authentication needs, or error handling.

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

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

The description is front-loaded with the core purpose in the first sentence and efficiently explains the two endpoint types in the second, with no wasted words or redundant information, making it highly concise and well-structured.

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

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

Given the tool's moderate complexity (6 parameters, no output schema) and rich schema/annotations, the description is mostly complete for guiding usage. However, it lacks details on output format or error cases, which would be beneficial since there is no output schema provided.

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

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

Schema description coverage is 100%, so the schema fully documents all parameters. The description adds minimal semantics by mentioning webhooks and email forwards, which loosely maps to the 'type' parameter, but does not provide extra details beyond what the schema already covers (e.g., parameter dependencies or usage examples).

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

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

The description clearly states the verb ('Create') and resource ('new endpoint for receiving emails'), and distinguishes this tool from siblings by specifying its unique creation function versus sibling tools that primarily retrieve, list, or send emails (e.g., list_endpoints, get_email, send_email).

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

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

The description provides clear context on when to use this tool by explaining the purpose of creating endpoints for email reception, but it does not explicitly state when not to use it or name specific alternatives among siblings (e.g., list_endpoints for viewing existing ones).

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

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

Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds context about what data is returned (content, headers, attachments, status), which is useful behavioral information beyond annotations. However, it doesn't disclose potential limitations like rate limits, authentication needs, or error conditions.

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

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

The description is a single, well-structured sentence that efficiently conveys the tool's purpose and scope. It's front-loaded with the core action ('Get detailed information about a specific email') and adds specific details without redundancy. Every word earns its place.

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

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

For a read-only, idempotent tool with one well-documented parameter and no output schema, the description provides adequate context about what data is returned. It covers the key aspects of the tool's behavior. However, without an output schema, it could benefit from more detail on return format or error handling, but it's largely complete for its complexity.

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

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

Schema description coverage is 100%, with the single parameter 'id' fully documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides (e.g., no examples of valid IDs beyond the schema's 'email_xxx' example). Baseline 3 is appropriate when the schema carries the full parameter documentation burden.

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

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

The description clearly states the verb ('Get') and resource ('email') with specific details about what information is retrieved ('detailed information including full content, headers, attachments, and delivery status'). It distinguishes from siblings like 'list_emails' (which lists emails) and 'get_thread' (which retrieves threads rather than individual emails).

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

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

The description implies usage context by specifying 'a specific email' and the need for an email ID, which suggests it's for retrieving details of known emails. However, it doesn't explicitly state when to use this vs. alternatives like 'list_emails' for browsing or 'get_thread' for thread-level details, nor does it mention prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, repeatable read operation. The description adds useful context about thread grouping and mailbox participation, but doesn't disclose additional behavioral traits like rate limits, auth needs, or pagination details beyond the cursor parameter.

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

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

The description is two concise sentences with zero waste: the first states the purpose and scope, the second clarifies the thread grouping concept. It's front-loaded with key information and appropriately sized for a read operation with good annotations.

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

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

Given the tool's moderate complexity (read-only list with filtering/pagination), rich annotations (safety profile covered), and 100% schema coverage, the description is mostly complete. It lacks output schema details (e.g., return format), but for a list tool with clear annotations, it provides sufficient context for agent use, missing only minor behavioral nuances.

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

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

Schema description coverage is 100%, so the schema fully documents the three parameters (unread, limit, cursor). The description doesn't add any parameter-specific semantics beyond what's in the schema, such as explaining how threads are filtered or paginated. Baseline 3 is appropriate when the schema handles all parameter documentation.

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

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

The description clearly states the verb 'Get' and resource 'email threads/conversations for your agent mailbox', specifying that it shows conversations where the mailbox is a participant. It distinguishes from siblings like 'get_email' (single emails) and 'list_threads' (likely broader listing) by emphasizing the mailbox-specific scope and thread grouping.

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

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

The description provides clear context: use this to retrieve threads where your mailbox participates, grouped like Gmail conversations. It implies when to use (for mailbox-specific threads) but doesn't explicitly state when not to use or name alternatives like 'list_threads' for broader access, though the context helps differentiate.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds valuable context beyond annotations: it specifies the return content (metadata, messages in chronological order, participant information) and clarifies that it retrieves 'all messages,' which isn't obvious from the tool name alone.

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

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

The description is two concise sentences that are front-loaded with the core purpose and efficiently detail the return values. Every word adds value without redundancy, 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.

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

Given the tool's low complexity (1 parameter), rich annotations (covering safety and idempotency), and lack of output schema, the description is mostly complete. It explains what the tool returns, but could improve by mentioning error cases or limitations, though annotations provide good foundational context.

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

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

Schema description coverage is 100%, with the single parameter 'id' fully documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides, such as format examples or constraints, so it meets the baseline for high schema coverage.

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

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

The description clearly states the specific action ('Get a complete email thread'), the resource ('email thread'), and the scope ('with all messages'). It distinguishes from siblings like 'get_email' (single message) and 'list_threads' (list only) by emphasizing completeness and chronological order.

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

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

The description implies usage context by specifying it retrieves a complete thread, suggesting it's for detailed viewing rather than listing. However, it doesn't explicitly state when to use this over alternatives like 'get_email' or 'list_threads', nor does it mention prerequisites or exclusions.

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

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

The description is missing, so it adds no behavioral context beyond what annotations provide. Annotations only include a title with no hints (e.g., readOnlyHint, destructiveHint), leaving the agent with no information about safety, permissions, or operational traits.

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

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

The description is under-specified ('No description provided'), which is not conciseness but a failure to provide any content. It lacks structure and does not front-load key information, making it ineffective for tool selection.

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

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

Given the complexity (a list operation with sibling tools) and lack of annotations or output schema, the description is completely inadequate. It provides no information on what 'domains' are, the return format, or how it fits into the context of email/mailbox-related tools.

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

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

The input schema has 0 parameters with 100% coverage, meaning no parameters need documentation. The description adds nothing, but this is acceptable since there are no parameters to explain, aligning with the baseline for zero parameters.

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

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

The description is 'No description provided', which is missing entirely. It fails to state what the tool does, making it impossible to understand its purpose or distinguish it from sibling tools like list_emails or list_endpoints.

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

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

No guidance is provided on when to use this tool versus alternatives. The description is absent, so there is no mention of context, exclusions, or comparisons with sibling tools such as check_mailbox or list_threads.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, repeatable read operation. The description adds useful context about what gets returned ('email metadata including sender, recipient, subject, and status'), but doesn't mention pagination behavior (beyond the offset parameter), rate limits, or authentication requirements. With annotations covering the safety profile, a 3 is appropriate.

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

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

The description is appropriately sized (two sentences) and front-loaded with the core purpose. The second sentence efficiently covers filtering and return values. There's minimal waste, though it could be slightly more structured with bullet points for clarity.

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

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

For a read-only list tool with comprehensive annotations and full schema coverage, the description is adequate but has gaps. It doesn't explain the return format in detail (no output schema exists), doesn't mention ordering of results, and provides no usage guidance relative to siblings. The description adds some value but isn't fully complete for optimal agent selection.

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

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

Schema description coverage is 100%, so the schema fully documents all 6 parameters with descriptions and constraints. The description mentions filtering capabilities ('Filter by type, status, time range, and more') but adds no additional semantic meaning beyond what's already in the schema. Baseline 3 is correct when schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: 'List emails in your Inbound account' with specific filtering capabilities. It distinguishes itself from siblings like 'get_email' (singular retrieval) and 'list_threads' (thread-focused), but doesn't explicitly contrast with 'check_mailbox' which might have overlapping functionality.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'list_emails' over 'check_mailbox', 'get_mailbox_threads', or 'list_threads', nor does it specify prerequisites or exclusions. Usage context is implied but not explicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds context about what types of endpoints are included (webhooks, email forwards, email groups), which isn't captured in annotations. It doesn't mention rate limits, authentication needs, or pagination behavior beyond what's 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.

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

The description is a single, efficient sentence that immediately states the purpose and scope. Every word earns its place by specifying what's listed and the endpoint types, with no redundant or vague language.

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

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

Given the tool's moderate complexity (5 parameters, no output schema), the description is reasonably complete. It clarifies the resource scope (endpoints for receiving emails) and types, which helps contextualize the filtering parameters. However, it doesn't address output format or pagination details, which could be useful since there's no output schema.

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

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

Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description doesn't add any parameter-specific information beyond what's in the schema, such as default values or usage examples. 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.

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 ('all endpoints for receiving emails'), and specifies the three types of endpoints (webhooks, email forwards, email groups). This distinguishes it from sibling tools like create_endpoint or get_email by focusing on listing rather than creating or retrieving specific items.

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

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

The description implies usage by mentioning endpoint types, but doesn't explicitly state when to use this tool versus alternatives like list_emails or list_threads. No guidance on prerequisites, exclusions, or specific scenarios for choosing this tool is provided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds context about what is returned (thread metadata, participant list, latest message preview), which is useful but doesn't detail behavioral aspects like rate limits, authentication needs, or pagination behavior beyond the cursor parameter.

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

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

The description is front-loaded with the core purpose, followed by clarifying details about threads and return values. Every sentence adds value without redundancy, making it efficient and well-structured.

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

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

Given the tool's moderate complexity, rich annotations, and full schema coverage, the description is mostly complete. It explains the return content, but without an output schema, it could benefit from more detail on response structure or error handling. However, it adequately covers the tool's purpose and basic usage.

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

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

Schema description coverage is 100%, so the schema fully documents all parameters. The description doesn't add any parameter-specific details beyond what the schema provides, such as explaining how 'search' interacts with 'unread' or default behaviors. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the verb ('List') and resource ('email threads (conversations) in your inbox'), and distinguishes from siblings by specifying it returns thread metadata, participant list, and latest message preview—unlike 'list_emails' which likely lists individual emails or 'get_thread' which retrieves a single thread.

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

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

No explicit guidance on when to use this tool versus alternatives like 'list_emails' or 'get_mailbox_threads' is provided. The description implies usage for listing threads in the inbox but doesn't specify exclusions or compare to sibling tools.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, indicating this is a non-idempotent write operation that doesn't destroy data. The description adds useful context about replying to latest messages in threads and reply-all functionality, but doesn't disclose additional behavioral traits like authentication needs, rate limits, or error conditions. No contradiction with annotations exists.

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

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

The description is perfectly concise with two sentences that each earn their place: the first establishes the core functionality, the second adds the reply-all feature. No wasted words, well-structured, and front-loaded with the essential information.

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

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

For a mutation tool with good annotations (covering safety profile) and comprehensive schema coverage, the description provides adequate context about what the tool does and its key features. However, without an output schema, it doesn't describe what the tool returns (e.g., success confirmation, new email ID), which would be helpful for a write operation. The description covers the essential behavior but leaves return values unspecified.

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

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

With 100% schema description coverage, the input schema already thoroughly documents all 7 parameters. The description adds minimal value beyond the schema by mentioning the email/thread ID distinction and reply-all functionality, but doesn't provide additional semantic context about parameter usage beyond what's already in the schema descriptions.

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

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

The description clearly states the specific action ('Reply to an email or thread') and distinguishes it from siblings by specifying it handles both email and thread IDs with reply-all functionality. It differentiates from tools like 'send_email' (new emails) and 'reply_from_mailbox' (likely mailbox-specific).

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

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

The description provides clear context about when to use this tool (replying to emails/threads with reply-all capability) but doesn't explicitly state when NOT to use it or name specific alternatives like 'send_email' for new emails or 'reply_from_mailbox' for mailbox-specific replies. The guidance is implied rather than explicit.

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

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

Annotations already indicate this is a non-readOnly, non-idempotent, non-destructive operation. The description adds useful context about the automatic 'from' address and thread behavior, but doesn't disclose additional behavioral traits like rate limits, authentication needs, or error conditions that would be helpful for a mutation tool.

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

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

The description is perfectly concise - two sentences that each earn their place. The first sentence states the core purpose, the second adds crucial behavioral context about the 'from' address and ID handling, with zero wasted words.

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

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

For a mutation tool with no output schema, the description is adequate but could be more complete. It covers the basic operation and key behaviors, but doesn't address what the tool returns, error conditions, or prerequisites. Given the complexity of email operations and lack of output schema, more completeness would be beneficial.

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

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

With 100% schema description coverage, the schema already documents all 5 parameters thoroughly. The description adds minimal value beyond the schema - it mentions the 'from' address automation and thread ID behavior, but doesn't provide additional parameter semantics beyond what's in the schema descriptions.

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

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

The description clearly states the specific action ('Reply to an email') with the resource ('from your agent mailbox'), distinguishing it from sibling tools like 'send_email' or 'reply_email' by specifying the automatic 'from' address setting and the ability to reply to either email ID or thread ID.

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

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

The description provides clear context on when to use this tool (replying from the agent mailbox with automatic 'from' address) and how it handles IDs, but it doesn't explicitly state when not to use it or name alternatives like 'send_email' or 'reply_email' from the sibling list.

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

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

Annotations indicate the tool is not read-only, idempotent, or destructive, which the description does not contradict. The description adds behavioral context by explaining the three retry modes (specific endpoint, specific delivery, or all endpoints), which goes beyond annotations. However, it lacks details on side effects, error handling, or rate limits that would enhance transparency.

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

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

The description is a single, efficient sentence that front-loads the core action ('retry delivery') and lists the three retry options concisely. There is no wasted text, and every part contributes to understanding the tool's functionality.

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

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

Given the tool's moderate complexity (3 parameters, no output schema) and rich annotations, the description is adequate but incomplete. It covers the purpose and retry modes but lacks details on prerequisites (e.g., email must have failed delivery), expected outcomes, or error conditions, which would be helpful for an agent to use it correctly.

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

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

Schema description coverage is 100%, so the schema fully documents parameters. The description adds minimal semantics by mentioning the three retry modes, which align with parameters but do not provide additional syntax or format details. This meets the baseline for high schema coverage without significant added value.

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

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

The description clearly states the specific action ('retry delivery') and resource ('received email'), distinguishing it from sibling tools like 'send_email' or 'reply_email' which involve creating new emails rather than retrying existing ones. It specifies the scope of retry operations (specific endpoint, specific failed delivery, or all endpoints), making the purpose unambiguous.

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

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

The description implicitly suggests usage when an email delivery has failed and needs to be retried, but it does not explicitly state when to use this tool versus alternatives like 'send_email' for new emails or 'reply_email' for responses. It provides context on retry options but lacks explicit exclusions or comparisons with sibling tools.

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

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

Annotations indicate this is a non-read-only, non-idempotent, non-destructive tool, which the description aligns with by describing a sending action. The description adds valuable context beyond annotations, such as support for HTML/plain text, CC/BCC, and scheduled sending with natural language times, though it doesn't cover rate limits or authentication details explicitly.

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

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

The description is a single, well-structured sentence that efficiently covers the tool's key features without redundancy. It is front-loaded with the core purpose and includes only essential details, making it highly concise and easy to parse.

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

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

Given the tool's complexity (10 parameters, no output schema) and rich annotations, the description is reasonably complete. It covers the main functionality and constraints (e.g., verified domain), but could be more comprehensive by addressing potential errors, response format, or integration with sibling tools, though annotations help fill some gaps.

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

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

With 100% schema description coverage, the input schema already documents all 10 parameters thoroughly. The description adds minimal semantic value by mentioning 'HTML and plain text content, CC/BCC, and scheduled sending with natural language times', which loosely maps to parameters like 'html', 'text', 'cc', 'bcc', and 'scheduled_at', but doesn't provide additional details beyond the schema.

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

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

The description clearly states the action ('Send an email') and specifies the resource ('from your verified domain'), distinguishing it from sibling tools like 'reply_email' or 'send_from_mailbox'. It explicitly mentions key capabilities like HTML/plain text support and scheduled sending, making the purpose specific and well-defined.

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

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

The description implies usage for sending emails with scheduling and content options, but does not explicitly state when to use this tool versus alternatives like 'send_from_mailbox' or 'reply_email'. It provides some context (e.g., 'from your verified domain') but lacks clear exclusions or direct 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.

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the agent knows this is a non-destructive, non-idempotent write operation. The description adds useful context about the automatic 'from' address setting and support for HTML/text content, CC/BCC, and scheduled sending, but doesn't disclose rate limits, authentication requirements, or error behavior beyond what annotations provide.

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

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

The description is perfectly concise with two sentences that are front-loaded with the core purpose and then list key features. Every sentence earns its place by providing essential information without redundancy or unnecessary elaboration.

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

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

For a write operation tool with no output schema, the description provides good context about the automatic 'from' address and supported features. However, it doesn't explain what happens after sending (success/failure responses, delivery confirmation) or potential limitations. Given the complexity of email sending and lack of output schema, some additional behavioral context would be helpful.

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

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

With 100% schema description coverage, the input schema already documents all 8 parameters thoroughly. The description mentions support for HTML/text content, CC/BCC, and scheduled sending, which aligns with parameters but doesn't add significant meaning beyond what the schema provides. The baseline of 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.

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

The description clearly states the specific action ('send an email'), identifies the resource ('from your agent mailbox'), and distinguishes it from siblings like 'send_email' by specifying the 'from' address is automatically set to the mailbox address via x-inbound-mailbox header. This provides precise differentiation from other email-sending tools.

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

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

The description provides clear context about when to use this tool (sending from the agent mailbox with automatic 'from' address setting) but doesn't explicitly mention when NOT to use it or name specific alternatives like 'send_email'. It implies usage for mailbox-based sending but lacks explicit exclusion guidance.

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