gmail

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

Annotations indicate this is a non-destructive mutation (readOnlyHint: false, destructiveHint: false), which the description doesn't contradict. The description adds useful context about label ID sources (list_labels, system labels) and implies idempotent behavior (adding existing labels likely has no effect), but doesn't cover error cases, rate limits, or authentication needs 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 extremely concise (two sentences) and front-loaded with the core purpose. Every sentence earns its place: the first defines the tool, the second provides essential usage guidance. No wasted words or redundant information.

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

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

Given the tool's moderate complexity (mutation with two parameters), 100% schema coverage, annotations covering safety, and an output schema (implied by context signals), the description is reasonably complete. It covers the what and how-to aspects well, though it could better address error handling or idempotency for a mutation tool.

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

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

With 100% schema description coverage, the schema fully documents both parameters (emailId, labelIds). The description adds marginal value by mentioning list_labels as a source for labelIds and giving examples of system labels, but doesn't provide additional syntax, format, or constraints beyond the schema's 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 ('Add one or more labels') and target resource ('to an email message'), distinguishing it from sibling tools like remove_labels (which removes labels) and list_labels (which lists labels). The verb+resource combination is precise and unambiguous.

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

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

The description provides clear context for when to use this tool by referencing list_labels to find label IDs and listing common system label IDs. However, it doesn't explicitly state when NOT to use it (e.g., vs. remove_labels) or mention prerequisites like needing a valid emailId from search_email or get_email, though the schema hints at this.

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-destructive write operation (readOnlyHint: false, destructiveHint: false), which the description aligns with by stating 'Create a new Gmail label'. The description adds context about post-creation usage with 'add_labels', but doesn't disclose additional behavioral traits like permissions, rate limits, or error handling 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 two sentences, front-loaded with the core action, and every sentence adds value: the first defines the tool's purpose, and the second provides practical guidance on next steps. There is no wasted text.

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 schema with 100% coverage, annotations, and an output schema (implied by context signals), the description is mostly complete. It covers purpose and usage flow but lacks details on output or error cases, though the output schema mitigates this 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 detailed descriptions for all parameters including enums and defaults. The description doesn't add any parameter-specific information beyond the schema, so it meets the baseline of 3 without compensating for gaps, as there are none.

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 ('Create a new Gmail label') and resource ('Gmail label'), distinguishing it from siblings like 'add_labels' or 'delete_label'. However, it doesn't explicitly differentiate from 'list_labels' in terms of creation vs. listing, though the verb 'create' makes the purpose evident.

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 by mentioning that labels organize emails and suggesting 'add_labels' for applying them after creation. It implies usage for label creation but doesn't explicitly state when not to use it or compare to alternatives like 'delete_label' or 'list_labels'.

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

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

The description adds valuable context beyond annotations: it clarifies that deletion is permanent, specifies the effect on messages (label removal without message deletion), and notes restrictions on label types (user-created vs. system). While annotations indicate destructiveHint=true and readOnlyHint=false, the description enriches this with practical behavioral details, though it doesn't cover aspects like error handling or permissions.

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 highly concise and well-structured: three sentences that efficiently convey purpose, behavior, and usage constraints without redundancy. Each sentence adds critical information, making it front-loaded and easy to parse for an agent.

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 (destructive operation with restrictions), the description is complete: it covers the action, effects, limitations, and usage context. With annotations providing safety hints and an output schema likely handling return values, no significant gaps remain. It adequately prepares an agent for correct tool selection and invocation.

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

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

With 100% schema description coverage, the schema already fully documents the single parameter (labelId). The description does not add any parameter-specific semantics beyond what's in the schema, such as format examples or validation rules. However, it implies the parameter must reference a deletable label, which aligns with the schema's guidance.

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 ('permanently delete') and resource ('a Gmail label'), distinguishing it from siblings like 'remove_labels' (which removes labels from messages) and 'create_label'. It explicitly notes what happens to messages ('removes the label from all messages but does not delete the messages themselves'), avoiding confusion with message deletion 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 explicit guidance on when to use this tool vs. alternatives: it specifies that only user-created labels can be deleted, while system labels (INBOX, SENT, etc.) cannot be removed. This clearly defines the scope and exclusions, helping the agent avoid incorrect invocations for system labels.

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-destructive write operation (readOnlyHint=false, destructiveHint=false). The description adds valuable behavioral context beyond annotations: it specifies that drafts are saved to the Drafts folder, plain text is automatically formatted with markdown, and HTML can be optionally provided for rich formatting. 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.

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

Three concise sentences with zero waste. First sentence states the core purpose, second provides usage guidelines and alternative tool, third explains formatting behavior. Every sentence earns its place by adding distinct value.

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 that this tool has annotations covering safety profile, 100% schema description coverage, and an output schema exists (so return values are documented elsewhere), the description provides complete contextual information. It covers purpose, usage guidelines, behavioral traits, and formatting behavior without needing to repeat structured data.

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 already documents all 6 parameters thoroughly. The description adds minimal parameter semantics beyond the schema - it mentions that plain text supports markdown formatting (implied by body_text's schema description) and HTML is optional for rich formatting (implied by body_html's optional nature). 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 specific action ('Create a new email draft saved to the Drafts folder') and distinguishes it from siblings like 'draft_reply' (which replies to existing emails) and 'send_draft' (which sends already-created drafts). It specifies the resource (email draft) and destination (Drafts folder).

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?

Explicitly states when to use this tool ('when composing an email to review or send later') and names an alternative tool for subsequent actions ('The draft can be sent using send_draft'). It also distinguishes from 'draft_reply' by not mentioning replying to existing 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?

The description adds valuable behavioral context beyond annotations: it explains the automatic 'Re:' prefix addition, email threading preservation, and markdown support. Annotations already indicate this is a non-destructive write operation (readOnlyHint=false, destructiveHint=false), but the description provides useful implementation details without contradicting them.

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

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

The description is efficiently structured with four sentences that each serve a distinct purpose: stating the core function, explaining the use case, describing automatic behaviors, and clarifying parameter semantics. No wasted words, and key information is front-loaded.

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, comprehensive schema coverage (100%), clear annotations, and the presence of an output schema, the description provides complete contextual understanding. It covers purpose, usage context, key behaviors, and parameter implications without needing to explain return values (handled by 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?

With 100% schema description coverage, the input schema already documents all parameters thoroughly. The description mentions 'reply_all parameter determines whether to reply to all original recipients or just the sender' and 'Plain text supports markdown formatting' for body_text, adding minor context but not significant value 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 specific action ('Create a reply draft'), target resource ('to an existing email'), and key behavior ('maintaining the conversation thread'). It distinguishes from sibling tools like 'draft_email' (new email) and 'send_draft' (sending rather than drafting).

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

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

The description provides clear context for when to use this tool ('to compose a response that can be reviewed before sending'), but doesn't explicitly state when NOT to use it or compare it to alternatives like 'send_draft' for immediate sending. The guidance is helpful but lacks explicit 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 and destructiveHint=false, indicating a safe read operation. The description adds valuable behavioral context beyond annotations: it specifies return formats based on file types (text files as decoded text, images as viewable content, others as base64), and mentions a 10MB size limit for attachments. This provides practical implementation details not covered by annotations.

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

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

The description is efficiently structured with zero waste: the first sentence states the core purpose, subsequent sentences provide usage guidance and behavioral details, and every sentence adds essential information. It's appropriately sized for a tool with multiple behavioral nuances.

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 (multiple return formats based on file types, size limits) and the presence of both comprehensive annotations and an output schema, the description is complete. It covers purpose, usage context, behavioral traits, and constraints without needing to explain return values (handled by 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 already documents all four parameters thoroughly. The description adds minimal parameter semantics beyond the schema—it mentions that filename and mimeType should come from get_email's attachment metadata, which is somewhat implied in the schema descriptions. This meets the baseline expectation when schema coverage is complete.

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

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

The description clearly states the specific action ('Download an email attachment') and resource ('by its ID'), distinguishing it from siblings like get_email (which fetches email metadata) and search_email (which searches emails). It explicitly mentions the tool's scope of fetching actual attachment content.

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 explicit guidance on when to use this tool ('Use after get_email to fetch the actual attachment content') and prerequisites ('Pass the filename and mimeType from get_email's attachment metadata'), clearly differentiating it from other email-related tools like get_email or search_email.

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 annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds valuable context about what content is retrieved (full body, all recipients, headers) and the prerequisite relationship with search_email. However, it doesn't mention rate limits, authentication requirements, or potential errors 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 efficiently structured in two sentences with zero waste. The first sentence states the core purpose, the second explains the workflow relationship with search_email. Every phrase adds value and is appropriately front-loaded.

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 has annotations covering safety (readOnlyHint, destructiveHint), 100% schema coverage, and an output schema exists (so return values are documented elsewhere), the description provides complete contextual information. It explains the purpose, usage guidelines, and relationship with search_email adequately for this level of 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?

With 100% schema description coverage, the schema already documents the single required parameter 'emailId' as 'Email ID from search_email results'. The description reinforces this by mentioning 'using its ID from search_email' but doesn't add significant semantic value beyond what the schema provides. 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 tool's purpose with specific verbs ('retrieve', 'read', 'see', 'access') and resources ('complete content of a specific email', 'full email body', 'all recipients', 'complete headers'). It explicitly distinguishes this tool from its sibling 'search_email' by explaining that search only returns snippets while this retrieves the actual content.

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 explicit guidance on when to use this tool ('after search_email since search only returns snippets, not the actual email content') and names the alternative ('search_email'). It clearly establishes the workflow relationship between these two 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?

The description adds valuable context beyond the annotations (readOnlyHint: true, destructiveHint: false) by specifying the scope of returned data ('both system labels... and user-created labels with message/thread counts') and the authentication requirement ('for the authenticated user'). While annotations cover safety, the description enhances understanding of what the tool does without contradicting them, though it doesn't detail rate limits or exact output format.

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 additional details and usage guidance, with no wasted words. Every sentence adds value—defining the return data and explaining when to use the tool—making it efficient and well-structured for quick comprehension by an agent.

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 (0 parameters, read-only, non-destructive) and the presence of an output schema, the description is complete enough. It covers the purpose, usage context, and behavioral details, aligning with annotations and sibling tools, without needing to explain return values since the output schema handles that, making it fully adequate for 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?

With 0 parameters and 100% schema description coverage, the description compensates by explaining the tool's behavior and output context. It clarifies that no inputs are needed and adds semantic meaning about the returned data (label types and counts), which the schema alone doesn't provide, making it more informative than the baseline of 3 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 ('List all Gmail labels') and resource ('for the authenticated user'), distinguishing it from siblings like 'create_label' or 'delete_label' by focusing on retrieval rather than modification. It explicitly mentions what is returned ('both system labels... and user-created labels with message/thread counts'), making the purpose unambiguous 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 provides explicit guidance on when to use this tool ('to discover label IDs needed for add_labels, remove_labels, or search_email queries'), directly naming alternative tools and clarifying its role in the workflow. This helps the agent understand the tool's context and when to select it over other options, such as for ID discovery rather than label management.

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 readOnlyHint=false and destructiveHint=false, but the description adds valuable behavioral context beyond this: it explains the side effects of removing specific labels (e.g., removing INBOX archives the message, removing UNREAD marks it as read). This clarifies non-obvious consequences not covered by annotations.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by two concise, actionable sentences that provide essential usage notes and behavioral insights. Every sentence adds clear value without redundancy.

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

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

Given the tool's moderate complexity, 100% schema coverage, annotations covering safety, and the presence of an output schema, the description is complete. It covers purpose, prerequisites, and key behavioral nuances, leaving no critical gaps for agent understanding.

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

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

Schema description coverage is 100%, so the schema already fully documents both parameters (emailId and labelIds). The description adds minimal semantic value beyond the schema, such as referencing list_labels for label IDs and providing example label values, but does not significantly enhance parameter understanding.

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 ('Remove one or more labels') and target resource ('from an email message'), distinguishing it from sibling tools like add_labels (which adds labels) and list_labels (which lists labels). It provides precise operational context.

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

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

The description explicitly references list_labels as a prerequisite to find label IDs, providing clear context for when to use this tool. However, it does not specify when NOT to use it or explicitly contrast with alternatives like add_labels, which slightly limits guidance.

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 annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds valuable behavioral context beyond this: it specifies the search scope ('across all folders unless specified otherwise'), describes the return format ('email summaries suitable for listing and overview'), and implies pagination behavior (by referencing 'get_email with the returned email ID' for full content). However, it doesn't explicitly mention rate limits or authentication requirements, which could be useful additions.

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 and front-loaded, with three sentences that each serve a distinct purpose: stating the tool's function, providing usage guidelines, and clarifying scope. There is zero waste—every sentence adds value, and the structure flows logically from general purpose to specific instructions and limitations.

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 (search functionality with multiple parameters), rich schema (100% coverage with examples), annotations (clear read-only, non-destructive hints), and the presence of an output schema (implied by context signals), the description is complete enough. It covers purpose, usage, scope, and output format without needing to repeat schema details or explain return values, which the output schema will handle.

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 already documents all three parameters thoroughly with examples and defaults. The description adds minimal parameter semantics beyond the schema—it mentions 'query' implicitly through search criteria but doesn't provide additional syntax or format details. This meets the baseline of 3 when the schema does the heavy lifting, but the description doesn't compensate with extra insights like query construction tips or pagination strategies.

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 with specific verb ('Search for emails in Gmail') and resource ('emails'), distinguishing it from siblings like 'get_email' (which retrieves full content) and 'list_labels' (which deals with labels). It specifies the search scope ('across all folders unless specified otherwise') and filtering capabilities ('by sender, subject, date, content, or other criteria').

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 explicit guidance on when to use this tool ('when the user wants to find emails by sender, subject, date, content, or other criteria') and when to use an alternative ('to read full email content, attachments, or HTML body, use get_email with the returned email ID'). It also clarifies the scope ('searches across all folders unless specified otherwise'), helping differentiate from potential sibling tools that might filter differently.

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

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

The description adds valuable behavioral context beyond annotations: it discloses the irreversible nature ('This action cannot be undone') and the automatic folder movement ('moved from Drafts to Sent folder automatically'). Annotations already indicate it's not read-only and not destructive, but the description provides specific consequences that help the agent understand the tool's impact.

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 three sentences that each serve a distinct purpose: stating the action, explaining the outcome, and warning about irreversibility. It's front-loaded with the core purpose and contains no redundant information.

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

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

Given the tool has annotations covering safety aspects, 100% schema coverage, and an output schema (implied by context signals), the description provides excellent contextual completeness. It covers purpose, usage timing, behavioral consequences, and warnings - everything needed for the agent to use this tool appropriately without over-explaining what's already in structured fields.

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 fully documents the single required parameter 'draftId'. The description adds minimal parameter semantics by mentioning 'Draft ID from draft_email or draft_reply response', which slightly reinforces the schema but doesn't provide significant additional value. This 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 ('send a previously created draft email'), identifies the resource ('draft email'), and distinguishes it from siblings by referencing 'draft_email' and 'draft_reply' as prerequisites. It goes beyond the tool name by explaining the outcome ('moved from Drafts to Sent folder').

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

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

The description explicitly states when to use this tool ('after draft_email or draft_reply when ready to send'), provides prerequisites ('previously created draft'), and implies alternatives (not using it if not ready to send). It clearly distinguishes this from draft creation tools in the sibling list.

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