gmail-mcp

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

Annotations already indicate non-destructive and idempotent behavior, and the description adds meaningful semantic context: archiving removes the message from the inbox and does not delete it. This goes beyond the boolean hints.

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 short and front-loaded: a single clear sentence defines the action and non-destructive nature, followed by a minimal parameter note. Every sentence 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 single-parameter, largely non-destructive operation with annotations and an output schema, the description provides enough functional context to invoke the tool correctly. It only lacks explicit mention of label effects or response details, which are not critical here.

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 0%, but the Args section compensates by explaining message_id as 'Message to archive,' giving clear purpose beyond the schema's bare 'Message Id.' It fully covers the only parameter.

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 the specific verb 'Archive' applied to 'a message' and clarifies the exact effect: 'taking it out of the inbox.' 'Nothing is deleted' distinguishes it from destructive alternatives like gmail_trash.

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 operation itself is clear, and 'Nothing is deleted' implies this is not the tool for permanent deletion. However, the description never explicitly names alternatives such as gmail_trash or states conditions for choosing this tool over them.

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 the key lifecycle behavior that the draft is not sent and remains in the mailbox, which goes beyond the annotations. It also explains that reply_to_message_id sets reply headers and makes the draft appear in the existing conversation. There is no contradiction with the annotations, and it adds useful behavioral context.

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: two short behavioral sentences followed by a scannable Args list. Every sentence adds useful information, and there is no filler or repetition.

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?

With an output schema present and annotations covering side-effect class, the description provides what an agent needs to invoke the tool: all required and optional parameters are described, and the non-sending behavior is clear. It would be slightly stronger if it explicitly pointed to gmail_send_draft for the follow-up sending step, but this omission does not block correct 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?

Schema description coverage is 0%, so the Args section carries the full burden. The description covers all six parameters and adds practical meaning: 'to' can be a comma-separated list, 'body' is plain text, and 'reply_to_message_id' threads the draft. A few entries are minimal, but overall the parameter guidance is sufficient.

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 clear action, 'Write a draft,' and immediately states the defining behavior: 'It waits in the mailbox until a person sends it.' This distinguishes the tool from sending tools like gmail_send_message and gmail_send_draft, and clarifies that it creates an unsent message.

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 phrase 'It waits in the mailbox until a person sends it' clearly communicates the main use case: prepare a message but do not send it yet. The extra explanation about reply_to_message_id explains when to use that parameter to reply in an existing conversation. However, it does not explicitly name alternatives such as gmail_send_draft or gmail_update_draft or give when-not-to-use 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?

Annotations already convey that this is non-read-only, non-destructive, and idempotent. The description adds the nesting behavior for label names, but does not mention what happens if the label already exists or whether the parent label must exist. With annotations covering the safety profile, the description provides acceptable but minimal additional behavioral context.

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 short, front-loaded with the core action, and contains no filler. The 'Args:' section is slightly redundant with the schema but adds the important nesting note. It earns its place with minimal waste.

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-required-parameter tool with annotations and an output schema, the description covers the essential information: creating a label and how to nest it via the name. It does not explain duplicate-label behavior, but the idempotentHint mitigates that. Overall, it is complete enough for an agent to invoke 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?

The schema only provides the parameter name and type, so the description carries the burden of explaining the parameter. It adds the useful detail that names can use 'Parent/Child' for nesting and calls the parameter a 'Label name.' However, it does not specify constraints like character limits or allowed characters, and the explanation remains somewhat redundant with the schema's title.

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 a specific verb and resource: 'Create a label.' The additional nesting hint clarifies that labels support hierarchical names. However, it does not explicitly distinguish this from related tools like gmail_modify_labels or gmail_delete_label, so it falls short of full sibling differentiation.

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 about when to use this tool versus gmail_modify_labels or gmail_delete_label. The only operational hint is the Parent/Child nesting syntax, which is about formatting the label name rather than choosing between alternatives.

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 convey the destructive (destructiveHint=true) and mutating (readOnlyHint=false) nature, so the description doesn't need to repeat those. It adds little beyond the literal 'Discard' action and doesn't disclose whether the deletion is permanent or what happens to the associated message. There is no contradiction with the annotations.

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

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

The core description is one short front-loaded sentence, which is appropriately concise for a simple tool. The 'Args:' block is redundant with the input schema and adds no new information, preventing a perfect score.

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 simplicity (one required parameter), the presence of an output schema, and annotations covering destructive and idempotent behavior, the description is mostly complete. It could add practical context such as where to obtain a draft_id or confirm irreversibility, but these are minor for a one-action delete 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 0% schema description coverage, the description carries the burden for parameter meaning, but 'draft_id: Draft to delete' only restates the parameter's purpose in near-tautological terms. It doesn't explain the expected ID format, how to obtain it (e.g., from gmail_list_drafts), or any constraints beyond the schema's required flag.

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 ('Discard') and resource ('a draft'), clearly identifying the operation as deleting a draft. It is not a tautology because 'Discard' conveys the action beyond the tool name, and the draft scope separates it from message deletion tools. It doesn't explicitly contrast with siblings like gmail_trash or gmail_delete_label, so it stops short of a 5.

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 no guidance on when to choose this tool over alternatives; it doesn't mention that gmail_trash handles messages or that gmail_update_draft edits existing drafts before deletion. 'Discard a draft' is a bare imperative with no exclusions, prerequisites, or context.

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 destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds valuable behavioral context beyond annotations by explicitly stating that messages are not deleted—'Messages keep their content but lose the label'—which clarifies the exact scope of the destructive operation. This is a meaningful disclosure of what gets destroyed and what does not.

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: one clear sentence explaining the operation's effect, followed by a minimal parameter note. Every sentence earns its place, and the key behavioral fact is front-loaded. There is no fluff or repetition of schema data.

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 simple one-parameter destructive tool with annotations covering safety and idempotency, the description covers all essential calling information: the action, the effect on messages, and the source of the label_id. The presence of an output schema means not describing return values is acceptable. Minor gaps like irreversibility or permission requirements are already implied by annotations and the simple operation.

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 schema offers only a title and type for label_id, with 0% description coverage. The description compensates by specifying that label_id should be 'Label id from gmail_list_labels,' giving the agent a concrete source for the parameter. For a single-parameter tool, this is sufficient added meaning 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 states a specific verb ('Delete') and resource ('a label'), and immediately clarifies the non-destructive effect on messages: 'Messages keep their content but lose the label.' This clearly differentiates it from sibling tools like gmail_trash or gmail_modify_labels without needing to open their schemas.

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 no explicit guidance on when to use this tool versus alternatives. It tells the agent where to get the label_id ('from gmail_list_labels') but does not state conditions, exclusions, or trade-offs relative to sibling tools. Usage context is only weakly implied by the verb 'Delete'.

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 read-only, idempotent, non-destructive behavior, so the description does not need to cover basic safety. It adds some context by specifying that the returned draft is 'in full' and includes the body, but it does not disclose other behaviors such as error conditions or draft-specific formatting. 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 minimal and front-loaded: a one-sentence purpose statement followed by a single argument note. There is no filler or redundant restatement of the tool name, and every sentence contributes either to goal clarity or parameter sourcing.

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 one-parameter read operation with rich annotations and an output schema, the description covers the essential call pattern and the nature of the returned object. Its main gap is the lack of explicit comparison to sibling tools, but this is minor because the getter's role is already evident from the name and description.

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 schema provides only a bare string type with a title, and schema description coverage is 0%, so the description carries the full burden. The note that draft_id comes from gmail_list_drafts gives the agent concrete sourcing guidance beyond the schema and clarifies that the parameter is an existing draft ID, not an arbitrary string.

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 clarifies that the tool returns a single draft, and 'including its body' adds meaningful specificity about the returned content. It does not use an explicit verb like 'retrieve' and does not explicitly distinguish it from sibling getters like gmail_get_message, but the resource and scope are 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 phrase 'Draft id from gmail_list_drafts' implies that the agent should call gmail_list_drafts first to obtain a valid ID, which is useful but implicit context. There is no explicit guidance about when to prefer this tool over alternatives such as gmail_get_message or gmail_get_thread, nor any when-not-to-use conditions.

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 safety (readOnlyHint, idempotentHint, destructiveHint). The description adds that it returns the full message including body text, which is useful behavioral info not in annotations. No contradictions.

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 only two sentences, front-loading the core purpose. Every word is functional—no filler. It's as concise as possible while still adding meaning.

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 simple single-message retrieval tool, the description covers the essential purpose and parameter source. An output schema exists, so return structure is handled. It doesn't discuss edge cases like missing IDs, but that's likely acceptable given the tool's simplicity and the presence of sibling tools for related operations.

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 0%, so the description must compensate. It does explain the source of message_id ('from gmail_search'), giving semantic context. However, it doesn't mention format, constraints, or potential errors, leaving some ambiguity for the single parameter.

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 and resource: 'One message in full, including its body text.' This clearly distinguishes it from siblings like gmail_get_thread (which returns an entire thread) and gmail_get_draft (for drafts). The purpose is 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?

It provides context by specifying that message_id comes from gmail_search, implying a typical workflow. However, it doesn't explicitly mention when to prefer this over gmail_get_thread or list similar exclusions. The guidance is sufficient for an agent to infer usage.

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, and non-destructive. The description adds value beyond those by disclosing the return ordering ('oldest message first'), the full scope ('whole conversation'), and a pragmatic behavioral caveat about later messages changing the initial request. This is useful context that the annotations do not 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 admirably compact: a one-line core definition, a crucial usage warning, and a minimal args section. Every sentence earns its place, and the critical advisory is front-loaded right after the definition.

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?

This is a simple read-only tool with one parameter, strong annotations, and an output schema that covers return values. The description tells the agent what it returns (full conversation, oldest first), where the thread_id comes from, and why reading the full thread matters. Nothing essential for calling 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?

Schema coverage is 0%, and the schema only gives the parameter name and type. The description compensates by specifying that thread_id comes from gmail_search or gmail_get_message, giving the agent actionable provenance information. It does not describe format constraints, but for a single string parameter this is sufficient.

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 identifies the resource as 'a whole conversation' and adds the ordering trait 'oldest message first', which distinguishes it from gmail_get_message (single message). However, the verb is implicit rather than explicit ('get' is only in the tool name), so it misses the 'specific verb' element of a 5.

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 instruction 'Read this before replying' gives concrete context for when to use this tool: before replying, to see the full conversation because later messages may alter the meaning of the first one. It implies a contrast with only looking at a single message, though it does not name the alternative tool explicitly or state when not to use it.

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 readOnly, idempotent, and non-destructive behavior, so the description only needs to add context. It adds that the result is limited to filenames, types, and sizes, implying metadata-only inspection, but it does not describe how attachments are returned or any limitations.

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 short, front-loaded statements plus an Args line, with no filler or repetition of schema or annotation information. Every sentence contributes either purpose or parameter provenance.

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 simple, read-only, single-parameter tool with an output schema and strong annotations, this description is nearly complete: purpose, output scope, and parameter source are all present. It stops short of explicit sibling differentiation, but nothing critical is missing for invoking 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?

With zero schema description coverage, the description must carry the semantic load for message_id. 'Message id from gmail_search' gives the needed provenance and makes the parameter actionable, which is sufficient for a single-parameter tool.

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 identifies the tool's function as reporting attachment metadata (filenames, types, sizes) for a specific message, distinguishing it from siblings like gmail_get_message and gmail_search. It lacks an explicit verb like 'list', but the intent is 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?

It provides useful context that message_id should come from gmail_search, indicating a search-then-inspect workflow. However, it does not state when to prefer this tool over alternatives such as gmail_get_message, nor any 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 this as read-only, idempotent, and non-destructive, so the description does not need to repeat safety traits. However, it adds no behavioral context beyond that, such as ordering, pagination behavior, or response characteristics.

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 text is short but not effectively concise: the opening sentence is a fragment that adds little value, while the useful limit explanation is buried in an Args section. The description is under-specified rather than tightly scoped.

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 simple single-parameter schema, output schema, and safety annotations, the description is minimally usable for a straightforward call. Still, it lacks an explicit statement of the operation and any context for choosing this tool over its siblings.

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 description compensates for the 0% schema coverage by explaining that limit means 'Maximum drafts to return' and adding the upper bound of 100. This gives an agent important information not present in the schema, though the default of 20 is left to 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 is a noun phrase, 'Drafts waiting in the mailbox,' with no explicit verb stating what the tool does. The action 'list' must be inferred entirely from the tool name, and the phrase largely restates the name with redundant 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 provides no guidance on when to use this tool versus alternatives like gmail_get_draft, gmail_search, or gmail_create_draft. There is no stated context, exclusion, or comparison to 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 establish read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral context beyond those annotations by stating the tool returns every label and that the id field is the important part for downstream filing tools. This is a concise disclosure of scope and output emphasis.

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?

Two sentences, both purposeful. The first states the output clearly, and the second explains why that output matters. No filler, no redundancy, and the most important 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?

For a parameterless listing tool with an output schema and comprehensive annotations, this description is fully sufficient. An agent knows what it will get, why to use it, and that it is safe to call. 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?

The tool has zero parameters and 100% schema description coverage, so the baseline is 4. The description adds no parameter detail because none is needed, but it does clarify the semantic role of the returned id, which is the only meaningful data an agent will consume.

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 identifies the resource (labels) and the output (each label with its id), and the name reinforces the action. It does not use an explicit verb like 'lists', but 'Every label, with its id' is unambiguous. It also subtly distinguishes this tool from label-modifying siblings by pointing to label ids as the input for filing 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 phrase 'Label ids are what the filing tools take' signals exactly when this tool is useful: before performing filing operations that require label ids. It does not offer explicit exclusions or alternatives, but no competing list-labels sibling exists, so the practical usage context is 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 establish that this is a non-read-only, idempotent, non-destructive operation. The description adds the key behavior that read=false causes unread, but it does not reveal any other side effects or prerequisites. 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?

Five short lines, no filler; the core capability appears in the first sentence, and the Args block is minimal and directly tied to the schema.

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 simple two-parameter state-change tool, the description, together with the annotations and the existing output schema, provides enough information to make the call correctly. The only missing element is explicit selection guidance, but the operation is simple enough that this is 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?

With 0% schema description coverage, the description fully compensates by explaining message_id as the target message and read as the state switch ('True marks it read, False marks it unread'), which is exactly the semantic information an agent needs beyond the raw types.

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?

States the exact operation with a verb ('Mark') and resource ('message'), and specifies the two possible outcomes ('read' or 'unread with read=false'). This is unambiguous and separates it from sibling tools like gmail_trash, gmail_archive, and gmail_modify_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?

No explicit guidance about when to choose this tool over alternatives or when not to use it. There are no excluded cases or pointers to sibling tools; the only implied context is the operation's own name and the read flag behavior.

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 non-read-only, idempotent, and non-destructive behavior, but the description adds meaningful side-effect disclosure: removing INBOX archives and removing UNREAD marks read. It also lists the system labels, which is useful operational context beyond the schema and 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 compact and front-loaded with the core action. The system-label list and side-effect notes earn their place, and the Args block is appropriately brief. There is no filler or redundant repetition of the title.

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 relatively simple three-parameter tool with an output schema and informative annotations, the description covers label semantics and important side effects. Minor gaps remain, such as behavior when neither add nor remove is provided and the exact format of label ids, but they are not critical given the output schema and sibling 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?

The input schema has no property descriptions, and the Args section only partially compensates. 'add' and 'remove' mirror the parameter names with little added depth, while message_id is described only as 'Message to file,' which is imprecise. Optionality and label-id formatting are also left unspecified.

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: 'Add or remove labels on a message.' It then clarifies system labels and key side effects, making the tool clearly distinguishable from archive, mark-read, and trash siblings.

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 context for when label modification is appropriate and explicitly maps behaviors to alternatives: 'Removing INBOX archives a message; removing UNREAD marks it read.' It does not explicitly name sibling tools or state when not to use it, but the context is strong enough for an agent to route correctly.

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, openWorldHint, and destructiveHint=false. The description adds useful context by revealing that the tool returns both mailbox identity and usage quantity, and that it is meant as an orientation step. 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 two short sentences with no filler. The core purpose is front-loaded, and the usage guidance follows immediately, 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?

For a parameterless, read-only tool with a rich output schema and clear annotations, the description is complete. It tells the agent what the tool reveals and when to invoke it; no further behavioral or parameter details are needed.

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 tool has zero parameters and schema coverage is 100%, so there is nothing for the description to add about arguments. This matches the baseline for a parameterless tool.

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 that the tool identifies which mailbox the server serves and reports its usage level, which is a clear purpose and clearly distinct from message, draft, label, and trash siblings. It lacks an explicit imperative verb like 'get' or 'retrieve', and 'how much is in it' is slightly vague, but the meaning is still clear.

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 says to call this tool first when more than one Gmail connector is set up, so replies go to the correct account. This gives an agent a concrete decision rule for when to use it, which is strong guidance even though no direct alternative tool exists.

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/openWorld/idempotent/non-destructive. The description adds meaningful behavioral details beyond those hints: return format (headers and snippet only), default spam/trash exclusion, max limit of 100, and empty-query behavior. 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?

Every sentence adds value: intro, operator list, return behavior, follow-up guidance, and a compact Args section. The most important scoping and return information is front-loaded, and no space is wasted on restating titles or obvious types.

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 output schema exists, the description does not need to explain return types in detail. It covers query syntax, defaults, scope exclusions, limits, and onward routing. An agent has everything needed to select and call this 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 0%, so the description must compensate, and it does thoroughly. Each parameter is explained with a concrete example for query, a maximum bound for limit, and the behavioral effect of include_spam. This far exceeds what the bare schema provides.

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?

States a specific verb ('search') and resource ('mailbox') with Gmail's query syntax. Clearly differentiates itself by noting it returns headers/snippets, not bodies, and points to sibling tools for retrieval. An agent can tell this apart from gmail_get_message and gmail_get_thread immediately.

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?

Describes the query operators and the empty-query fallback, giving concrete context for when to call it. It names follow-up tools for message/thread retrieval, but does not explicitly list exclusions for sibling search/list alternatives. The usage context is clear, though not exhaustive.

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?

Adds important behavioral context beyond annotations: sending 'reaches other people and cannot be undone,' and requires human confirmation. This meaningfully extends the destructiveHint and readOnlyHint signals rather than merely repeating 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 compact, front-loaded with the core action and consequence, and every sentence earns its place. The Args section is minimal and does not bloat the definition.

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 consequential one-parameter action, the description covers the outcome, irreversibility, consent requirement, and parameter meaning. The existing output schema handles return-value expectations, so no critical information 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 description coverage is 0%, so the description must carry parameter meaning, but it only says 'Draft to send,' which restates the schema property title 'Draft Id.' It does not explain how to obtain a draft_id or what format is expected.

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?

States a specific verb and resource: 'Send an existing draft.' This clearly distinguishes the tool from siblings like gmail_create_draft, gmail_update_draft, and gmail_send_message, and the 'existing' qualifier scopes it to pre-built drafts.

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?

Gives explicit preconditions: show the draft and get explicit yes before calling, and explicitly says sending is not a plan step but a user decision. It does not name an alternative tool, but the context is clear enough for an agent to know when it is appropriate.

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 destructive/read-only status, and the description adds the key consequence: it reaches people immediately and cannot be undone. It also frames the safer alternative workflow, adding context beyond structured data.

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 warning and usage guidance are front-loaded, and the parameter block is compact and readable. Every sentence earns its place with no filler.

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 simple parameter set, output schema, and annotations, the description covers purpose, when to use it, side effects, and all parameters. No critical information needed for correct invocation 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 description coverage is 0%, so the description must compensate. It does by explaining comma-separated recipients, plain-text body, and cc/bcc roles. It could include address format details, but the coverage is solid for this API.

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?

States a specific verb-resource pair ('Compose and send') and clearly marks this as the immediate-send tool. The opening line distinguishes it from the draft/send-draft siblings.

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 directs the agent to prefer gmail_create_draft followed by gmail_send_draft once text is approved, and says 'Use this only when told to send outright.' This is strong positive and negative routing.

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 convey that this is a destructive, non-read-only, idempotent operation. The description adds useful context about the 30-day retention period. However, it does not clarify what happens after 30 days or explicitly note recoverability via gmail_untrash.

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 very concise and well-structured: one clear functional sentence followed by the parameter line. No filler or redundant explanation.

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 mutation with an output schema and annotations covering destructive/idempotent behavior, the description is mostly complete. It covers the action and retention window, though it omits guidance on restoration and the permanent-deletion implication after 30 days.

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 schema description coverage at 0%, the description carries the burden of explaining the parameter. It does minimally by saying 'message_id: Message to trash,' which is more semantic than the schema's 'Message Id'. However, it does not specify the ID format or where the ID should come from.

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 with a specific verb and resource: 'Move a message to the trash.' It also adds a meaningful retention detail. It is naturally distinguishable from siblings like gmail_archive or gmail_untrash, but it does not explicitly name or differentiate them.

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 such as gmail_archive or gmail_untrash. The description only states what the tool does and gives no exclusions, context, or routing hints.

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 the mutation/idempotent/non-destructive profile, so the description does not need to restate them. It adds no extra behavior detail such as no-op behavior for already-untrashed messages, but it does not contradict the annotations.

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

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

The description is compact, front-loaded with the action, and contains only the necessary parameter line. There is no boilerplate or 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?

For a one-parameter tool with strong annotations and an output schema, the definition is sufficient to make a correct call; return-value explanation is unnecessary. It lacks explicit prerequisite or alternative information, but that is not essential for this simple operation.

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% schema description coverage, the description must carry parameter meaning; 'message_id: Message to restore' provides the basic role of the single parameter. It does not add format, source, or invalid-ID behavior, but for a single self-explanatory argument the minimal clarification is adequate.

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 first line uses a specific verb and object ('Take a message back out of the trash'), clearly defining an untrash operation. It is naturally distinguished from the sibling gmail_trash, and no other sibling matches this action.

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?

Usage is implied by the operation name and first line: invoke when a previously trashed message must be restored. However, it does not explicitly state when not to use it or point to alternatives such as gmail_trash for the opposite action.

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, the description reveals a key behavioral trait: Gmail performs a full rewrite rather than a partial update, so callers must supply every field. This is exactly the kind of non-obvious behavior an agent needs to know to invoke the tool correctly and avoid silently resetting omitted fields.

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 concise and front-loaded: the central behavior and critical pitfall appear in the first two sentences, followed by a compact parameter list. There is no filler, and every line adds necessary 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 six-parameter mutation tool, the description provides enough behavioral and parameter context to call the tool correctly. It does not explicitly note that cc/bcc are optional or that null clears them, but the schema already marks those defaults. Output schema exists, so return-value documentation is not needed here.

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 0%, so the description carries the full burden of parameter explanation. It provides meaningful one-line meanings for all six parameters: draft_id, to, subject, body, cc, and bcc. It does not add format details like delimiter expectations, but the basic semantics are sufficient for correct use.

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 action: 'Replace a draft's contents.' This distinguishes it from siblings like gmail_create_draft, gmail_delete_draft, and gmail_send_draft, which perform different operations on drafts. The scope is specific and immediately understandable.

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 context for the tool's intended use: modifying an existing draft. It also provides a critical operational guideline: because Gmail rewrites the entire message, all fields must be passed rather than only changed ones. It does not explicitly name alternatives or when-not-to-use cases, but the replacement semantics make the primary use case evident.

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