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

Annotations provide the safety profile, and the description adds substantial behavioral context: a browser window opens, a fallback consent URL is provided, re-adding overwrites existing credentials, and error conditions (missing OAuth client, denied consent, 5-minute timeout) are listed. 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.

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

The description is long but organized into labeled sections (Args, Returns, Examples, Error Handling) with a one-line lead. Every section carries necessary information for a complex OAuth flow; nothing is padded.

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

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

For a tool with 4 optional parameters, no output schema, and external side effects, the description is complete: it covers return values, side effects, auth behavior, timeouts, and errors. An agent has everything needed to invoke 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 coverage is 100%, so the baseline is 3. The description adds value with concrete usage examples, clarifies the legacy allow_send relationship, and explains that alias is usable anywhere an 'account' parameter is accepted — details that help an agent choose values.

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 states a specific verb ('Add (or re-authenticate)'), the resource ('Gmail account'), and the mechanism ('browser OAuth consent flow'). This distinguishes it from sibling tools like gmail_remove_account and gmail_list_accounts without needing to open the schema.

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

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

It clearly identifies when to use the tool (initial setup or re-auth via OAuth) and explains the flow. It does not explicitly name alternatives or exclusions, but the sibling set makes the context unambiguous.

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?

Beyond the annotations, it discloses that the draft is persisted to Drafts, requires modify/send scope, returns draft id/message id/account, and handles expired credentials with re-auth instructions. This gives the agent a solid model of side effects, auth needs, and failure behavior.

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 well-organized with a one-sentence purpose, grouped parameters, return value note, examples, and error handling. It is front-loaded with the most important behavioral information and every section 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?

Given there is no output schema, the description fully covers return values, required/optional parameters, examples, account selection, and error behavior. An agent has enough information to construct valid calls and interpret results without missing critical 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%, so the baseline is 3. The description mostly restates schema details, though the examples add concrete usage patterns and clarify that 'account' can be an alias or omitted for the default account. This is helpful but not substantial new meaning.

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 names a specific action and resource: Create a plain-text draft saved to Drafts, with the explicit clarification that nothing is sent. This clearly distinguishes it from sibling tools like gmail_send_message and gmail_reply_to_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?

It gives clear context for when to use the tool by noting drafts are saved but not sent and by specifying auth scope requirements. It does not explicitly name alternative tools or state when not to use it, but the distinction from sending is well implied.

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 establish read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral context beyond that: message IDs are account-specific, attachment content download is not supported in v1, and a 404 usually indicates the ID belongs to a different account. These are non-obvious operational details that help an agent avoid mistakes.

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 compact and well-organized with clear sections: a one-sentence summary, Args, Returns, Examples, and Error Handling. Every section contributes practical information, and the most important caveat (account-specific IDs) 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?

There is no output schema, so the description appropriately lists what the normalized message contains and what attachment metadata is included. It also covers the main error case and parameter defaults. For a simple read-only fetch tool with three parameters, this is complete.

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 coverage is 100%, so the baseline is 3. The description adds value by reinforcing the account-specific nature of message_id, explaining the response_format default and its effect, and giving concrete examples that clarify how parameters combine. This goes beyond the schema's own parameter 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 opens with 'Fetch a single message with full body text and attachment metadata,' which is a specific verb plus resource and clearly distinguishes this from thread-level operations like gmail_get_thread. It also states what is included in the result, making the tool's 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 makes clear this is for fetching a single message, implies account context matters, and provides examples showing typical calls. It does not explicitly say 'use gmail_get_thread for a full thread' or 'use gmail_search_threads for searching,' so it lacks an explicit exclusion, but the context is clear enough to guide selection.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds meaningful behavioral context: truncated long threads with a note on message count, normalized headers/body, and a 404 failure mode tied to account mismatch. This goes well beyond what the annotations alone 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 well-structured with front-loaded purpose, then Args, Returns, Examples, and Error Handling. Each section earns its place, and the content is detailed without being bloated or repetitive.

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?

Since there is no output schema, the description properly explains return values: all messages with headers, body text, labels, and attachment metadata. It also covers truncation behavior and the likely 404 cause, so an agent has everything needed to invoke and interpret the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds actionable context: thread_id must come from gmail_search_threads and be used with the same account that produced it. The examples also clarify realistic invocation patterns, which exceeds the baseline without being redundant.

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 opens with a specific verb and resource: 'Fetch a full thread — every message with normalized headers and body text.' It also distinguishes itself from siblings by stating it retrieves the complete thread and explicitly pointing to gmail_get_message for a specific message's full 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?

It clearly establishes when to use this tool: to get an entire thread. It also gives an explicit alternative condition, 'use gmail_get_message for a specific message's full content,' and explains that thread_id comes from gmail_search_threads. It doesn't contrast with every sibling, but the routing guidance is sufficient.

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, idempotentHint, and destructiveHint, but the description adds valuable behavioral detail: tokens are never exposed, output is one line per account, the no-accounts case is handled, and errors occur only if the local accounts file is unreadable or corrupt.

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, then organized into short labeled sections for args, returns, examples, and errors. Every section adds useful information without excessive wording.

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

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

For a zero-parameter read-only tool with no output schema, the description fully covers what the agent needs: invocation, return content, empty-result behavior, and error conditions. Nothing essential is missing.

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?

There are zero parameters and the schema fully documents that with an empty properties object. The description reinforces this with 'Args: none' and a literal '{}' example, adding confirmation even though there is no parameter meaning to elaborate.

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

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

The description uses a specific verb and resource: 'List every stored Gmail account,' followed by the exact fields returned. This clearly distinguishes it from sibling tools like gmail_list_labels and account-mutation tools such as gmail_add_account and gmail_remove_account.

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 intended use is clear: call this when you need to enumerate stored accounts and their metadata. It does not explicitly name alternatives or exclusion criteria, but no other sibling provides account listing, so the context is sufficient.

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, openWorldHint, idempotentHint, and destructiveHint=false. The description adds concrete return shape (name, id, type for every label) and credential-expiry behavior, going beyond the annotations. It does not contradict the annotations, and the only minor omission is explicit pagination/rate-limit behavior, which is not necessary for this simple read.

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 well-organized with a purpose line, Args, Returns, Examples, and Error Handling, making it easy to scan. It is slightly redundant with the schema's parameter documentation, but every section earns its place and the most important guidance 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?

For a read-only listing tool with no required parameters and no output schema, the description covers purpose, parameter usage, return fields, example calls, and failure behavior. It also explains how the output relates to gmail_modify_labels, so nothing an agent needs to call it correctly is missing.

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 already documents both parameters at 100% coverage, including defaults, enums, and account guidance. The description essentially restates the same account/response_format semantics without adding novel detail, so the baseline 3 applies.

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 states a specific verb ('List every label') and a clear resource (a Gmail account), and it enumerates both system labels and user labels with IDs. It also differentiates itself from gmail_modify_labels by noting that the sibling operates on label IDs. This is specific, distinct, and not a tautology.

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

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

It explicitly instructs the agent to call this tool first to translate label names to IDs before using gmail_modify_labels. It also clarifies account omission for the default account and includes error handling for expired credentials. This is direct when-to-use guidance with a named sibling alternative.

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 cover read-only, idempotent, and destructive hints. The description adds valuable behavioral context: account-specific IDs, the requirement of exactly one message_id or thread_id, and that at least one of add/remove is needed. It also describes the return value. 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?

The description is organized with clear sections (Args, Returns, Error Handling) and includes two concise examples. While it is longer than typical, every sentence adds value—no filler or redundancy. The main purpose is front-loaded, and details are structured for easy scanning.

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

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

For a tool with no output schema and limited annotations, the description is remarkably complete. It covers usage, parameter constraints, return values, error scenarios, and even practical tips like account-specific IDs. An agent could invoke this tool correctly without additional information.

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 is empty, so the description carries the full burden of parameter documentation. It thoroughly explains each parameter (message_id/thread_id, add_label_ids, remove_label_ids, account) with constraints, defaults, and the distinction between label IDs and names. This exceeds what a schema would typically provide.

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: 'Add and/or remove labels on one message or one whole thread.' It also explains that it is the mechanism for archiving and marking read/unread, and provides specific label IDs for those operations. This distinguishes it from sibling tools like gmail_trash_message and gmail_list_labels.

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 the tool (e.g., to archive, mark read/unread, star) and how to translate label names to IDs via gmail_list_labels. It also includes error handling advice (list labels first, 404 suggests wrong account). While it doesn't explicitly contrast with siblings, the examples and notes make usage clear.

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 flag destructive and idempotent behavior, but the description adds substantial context: best-effort refresh-token revocation, local entry deletion, default-account reassignment/clearing, revocation failures being ignored, and repeat safety. This goes well beyond the annotations and gives an agent a clear model of side effects.

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 well-organized into concise sections (Args, Returns, Examples, Error Handling) with the main behavior front-loaded. Every sentence adds value—no padding—and the error-handling note is especially useful for a destructive tool.

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 single-parameter tool with no output schema, this description is complete: it covers behavior, return content, example invocations, and error cases. The annotations carry the destructive/idempotent profile, and the description fills in the rest. An agent has everything needed to invoke it correctly and interpret the result.

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 coverage is 100% and the schema description already documents the only parameter ('Email or alias of the account to remove'). The description's Args section repeats this without adding new semantics, though the examples provide useful formatting. Baseline 3 applies because the schema carries the semantic load.

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 opens with a precise verb+resource: 'Remove a stored Gmail account by email or alias.' This unambiguously identifies the operation and, alongside the sibling set (gmail_add_account, gmail_list_accounts), makes clear it is the removal counterpart. No ambiguity about what the tool does.

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

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

The description gives clear operational context—what revocation, deletion, and default-account behavior happen—but does not explicitly state when to use this tool vs. alternatives or when not to use it. However, the purpose is so specific that an agent can infer the appropriate context; it just lacks an explicit exclusion or alternative-naming statement.

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 discloses key behaviors beyond the annotations: it creates threaded replies, requires send access, explains reply_all recipient semantics, specifies the return value, and covers common errors such as 404 indicating a cross-account thread id. This is substantial behavioral detail that annotations cannot convey.

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 well-organized into Args, Returns, Examples, and Error Handling sections, with the purpose and access requirement front-loaded. It is longer than average but every section adds actionable information, and the examples clarify parameter usage without padding.

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 four-parameter tool with no output schema or output schema richness, this description is complete: it explains return values, error conditions, account requirements, recipient selection, and the exact threading behavior. An agent has enough context to call it correctly without needing the 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?

Although schema coverage is 100%, the description adds real semantic value beyond the schema: thread_id is account-specific, reply_all false means sender or Reply-To only, reply_all true includes To/Cc minus this account, account may be an alias, and examples illustrate realistic invocation. This goes well beyond the schema's field names.

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 states a specific verb ('Reply to an existing thread'), the resource (thread, with threading headers), and a scope constraint ('from the account that owns it'). This clearly distinguishes it from siblings like gmail_send_message (new message) and gmail_create_draft (draft).

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

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

It clearly specifies when to use the tool: to reply within an existing thread with correct In-Reply-To/References headers, and states the prerequisite that the account must have send access. It doesn't explicitly name alternatives like 'use gmail_send_message for new mail,' but the 'existing thread' framing provides clear context without naming siblings.

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, so the description's confirmation of read-only behavior is redundant. However, it adds valuable behavioral details beyond annotations: the merge-by-date behavior across accounts, per-account caps, per-account failure handling, and the re-auth instruction behavior. It also clearly states what is NOT returned (full bodies), which is a behavioral boundary not covered by annotations. Minor deduction for not mentioning rate limits explicitly, but the added context justifies a strong score.

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 well-structured with an 'Args' section, examples, and error handling. It front-loads the primary purpose and then details parameters. It is somewhat long, but every section adds useful information. The explicit 'Returns' and 'Error Handling' sections are helpful. A 4 because it could be slightly more succinct without losing critical details.

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 (multi-account fan-out, pagination limitations, partial failures), the description is remarkably complete. It covers input syntax, output shape, edge cases (page_token limitation), and error handling, so an agent has everything needed to invoke correctly. There is no output schema, so the description's 'Returns' section is essential and provided. Nothing critical is missing.

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 coverage is 100%, so the schema fully documents each parameter with descriptions and examples. The description adds a few extra example queries and clarifies the behavior of page_token with account:'all', but these are marginal over the schema. A 3 is appropriate because 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 states a specific verb ('Search') and resource ('threads'), and immediately clarifies the scope (full Gmail syntax, across accounts). It distinguishes itself from gmail_get_thread by noting it returns thread-level summaries only, directing the agent to the sibling for full 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?

It gives explicit examples of when to use the tool and nuances like 'account: all' fan-out and pagination limitation, which are crucial for correct invocation. It also explains error handling in 'all' mode, so the agent knows failures are per-account and not fatal.

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 declare readOnlyHint=false and destructiveHint=false, and the description is consistent. It adds the requirement of 'send' access, describes the return confirmation (sending account, recipients, message and thread ids), and explains the error path for read-only accounts. 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.

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

The description is well-structured with Args, Returns, Examples, and Error Handling sections. The first sentence front-loads the core purpose. It is detailed but not redundant; every section adds information an agent needs.

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 6 parameters and no output schema, the description covers the required access, parameter semantics, return format, error handling, and a routing alternative. An agent can confidently invoke 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 baseline is 3. The description adds value by providing concrete examples, clarifying the 'account' parameter as an email or alias with a default, and noting that cc/bcc are optional arrays. This goes beyond the schema's terse 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 states 'Send a new plain-text email from one of the stored accounts' – a specific verb and resource, and explicitly notes constraints (plain-text, no HTML/attachments) that distinguish it from siblings like gmail_create_draft and gmail_reply_to_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?

It explicitly states the prerequisite (account must have been added with access: 'send'), explains the default account behavior, and gives a clear alternative (gmail_create_draft) with the condition when to use it. The error handling section reinforces 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?

The description adds significant behavioral context beyond the annotations: it explicitly states the action is recoverable for ~30 days, can be restored from Trash, and that nothing is permanently deleted. It also describes return values and error behavior, giving the agent a full picture of what happens when invoked.

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 well-structured with a leading purpose sentence, a highlighted recoverability note, a compact Args section, Returns, Examples, and Error Handling. Every section earns its place, and the most critical information (purpose and recoverability) 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?

For a moderate-complexity tool with no output schema, the description is complete: it covers the action, parameters, return value, examples, and error handling. It even addresses a common pitfall (id/account mismatch) with a concrete 404 explanation. Nothing an agent needs to invoke the tool correctly is missing.

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 is empty, so the description carries the full burden for parameter meaning. It clearly specifies that exactly one of message_id or thread_id is required, defines ids as account-specific, and explains the optional account parameter. Examples demonstrate valid payloads, fully covering parameter semantics despite the empty 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 opens with a specific verb and resource: 'Move one message or one whole thread to Trash.' It also clarifies scope (one message or whole thread), which differentiates it from sibling tools like gmail_modify_labels or gmail_send_message. The purpose is unmistakable and distinct.

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: trashing is recoverable and not permanent, and it explains the required message_id/thread_id pattern. It does not explicitly mention when not to use the tool or compare it to alternative siblings, but the intended use is obvious and no exclusions are needed for this specific action.

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