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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates that labels are modified in batches, without mentioning side effects, partial failure behavior, idempotency, permission requirements, or what happens when both add and remove label IDs are supplied. The batched behavior is useful but the description is too thin for a mutation tool.

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

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

The description is a single, focused sentence that front-loads the core action and scope. Every word earns its place, and there is no redundant or filler content.

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 batch mutation tool with four parameters and no annotations, the description is too minimal. It does not explain how batch_size affects execution, whether add and remove operations are applied together, or how this compares to modify_email and batch_trash_emails. The schema covers parameters, but the behavioral and usage context 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 100%, so the parameters are already well-documented in the schema. The description adds no additional parameter-level meaning beyond 'labels', so the baseline of 3 is appropriate.

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

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

The description clearly states the action ('Modify'), the target ('labels for multiple emails'), and the distinctive scope ('in batches'). This distinguishes it from the sibling tool modify_email, which presumably handles a single email, so an agent can select it based on the description alone.

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 'multiple emails in batches' implies this is the right choice when operating on many emails at once. However, it does not explicitly name modify_email as the single-message alternative, nor does it provide any exclusion conditions or guidance about when not to use the tool.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It conveys that the operation moves emails to trash rather than permanently deleting them and that it operates in batches, but it omits side effects such as reversibility, permission requirements, and whether failures are per-message or all-or-nothing.

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

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

The description is a single short sentence with no filler; every word carries meaning. It is efficiently structured and immediately communicates the action, target, and batch scope.

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 tool with a fully described schema and an output schema, the core operation is understandable. However, the absence of annotations and lack of sibling differentiation leave gaps around recoverability, error behavior, and when this tool should be chosen over alternatives.

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 covers both parameters: message_ids is 'List of message IDs to trash' and batch_size is 'Number of messages per batch (default: 50)'. The description adds little meaning beyond what the schema provides, so the baseline score of 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 uses a specific verb ('Move') plus resource ('emails'), destination ('to trash'), and scope ('multiple', 'in batches'), so an agent can tell this apart from singular trash_email and from batch_delete_emails (which deletes rather than trashes). It clearly states 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 implies bulk use ('multiple emails', 'in batches'), but it does not explicitly tell the agent when to prefer this tool over trash_email, batch_delete_emails, or batch_move. Usage guidance is left to inference from sibling tool names rather than stated.

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?

With no annotations provided, the description carries the full behavioral burden. It only says 'create' and does not disclose side effects, such as the filter immediately affecting incoming email, potential duplicate filters, permission requirements, or validation 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 a single clear sentence with no wasted words. It is front-loaded with the action and resource, though it could have included a brief usage pointer without becoming verbose.

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 nested objects, an output schema, and no annotations, the description is minimally adequate but leaves out behavioral context and alternative-tool routing. The schema covers parameter structure, so the main missing piece is usage guidance and side-effect disclosure.

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 input schema already explains criteria and action objects. The description adds only the word 'custom,' which is minimal and does not meaningfully extend what the schema provides; baseline 3 is appropriate.

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

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

The description is specific: 'Create a new Gmail filter' names the verb and resource, and 'with custom criteria and actions' adds scope. It clearly distinguishes this tool from create_filter_from_template and from list/get/delete 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 no guidance on when to use this tool versus alternatives like create_filter_from_template. It does not state exclusions, prerequisites, or that template-based creation should use a sibling tool.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It only states what the tool does ('Create a filter using a pre-defined template'), with no mention of side effects, required permissions, whether existing filters are affected, idempotency, or what the resulting filter looks like. The absence of annotations makes this a significant behavioral gap for a tool that creates a persistent resource.

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, a single 10-word sentence that clearly communicates the core purpose. It is not overloaded with irrelevant detail, and it front-loads the verb and resource. Some additional context about templates would be useful, but the structure itself is clean and efficient.

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?

The tool has 10 parameters including many conditional ones, an output schema, and no annotations. The description is too brief to guide an agent on selecting the right template and supplying the correct parameter combination, though the schema does provide the template options with parenthetical hints (e.g., 'for containingText'). Given the complexity and the presence of an output schema, a slightly fuller description (e.g., 'Choose one template and provide its corresponding parameter') would be materially helpful.

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

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

Schema description coverage is 100%, so the baseline is 3. The description itself does not add meaning beyond the schema, but the schema is self-explanatory; it documents each template-specific parameter and the template enum values. The description contributes little extra, but the schema already covers parameter semantics.

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 provides a clear verb ('Create') and resource ('a filter'), and mentions 'pre-defined template for common scenarios,' which distinguishes it from the sibling create_filter that presumably requires manual criteria construction. However, it does not explicitly name create_filter as the alternative or call out what makes using a template different beyond the phrase.

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

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

The description implies this tool should be used when a pre-defined template applies to a common scenario, but it provides no explicit guidance about when to choose this over create_filter, or when to prefer manual filter creation. It does not enumerate the templates or their use cases in the description; an agent must open the schema to learn the template enum values and the conditional parameters.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'Create a new Gmail label.' It does not mention whether duplicate names cause an error, what happens with default visibility settings, or any permissions required. This is a significant gap for a mutation tool.

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

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

The description is a single, clear sentence with no redundant words. It could have included a note about get_or_create_label, but as a concise statement of purpose, it is well-structured and 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?

Despite an output schema existing, the description is too sparse: it lacks any usage guidance or behavioral notes, and the presence of get_or_create_label suggests an important distinction that is not mentioned. For a tool with several siblings and no annotations, this is incomplete.

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 all three parameters with descriptions and defaults (100% coverage), so the description doesn't need to add parameter details. It adds nothing beyond the schema, which matches the baseline of 3 for high schema coverage.

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

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

The description uses a specific verb and resource ('Create a new Gmail label'), which clearly states the action. However, it does not distinguish this tool from the sibling get_or_create_label, which also creates labels when they don't exist, 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?

There is no guidance on when to use create_label instead of get_or_create_label or update_label. The single sentence only states the action, leaving the agent to infer the appropriate context from the name alone.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Delete' without indicating whether the operation is permanent, whether special permissions are required, or what side effects may occur.

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 one sentence with zero wasted words, directly stating the action and resource. It is optimally concise for the tool's simplicity.

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 delete operation, the essential invocation details are present and an output schema exists, so return values need not be described. However, the absence of usage guidance and behavioral transparency leaves the description adequate but not comprehensive.

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% and the filter_id parameter is clearly documented as 'ID of the filter to delete', so the baseline is 3. The tool description adds no additional semantic detail about the parameter or how to source a valid ID.

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 clear verb ('Delete') and a specific resource ('Gmail filter'), leaving no ambiguity about the tool's function. It distinguishes itself from siblings like create_filter, get_filter, list_filters, and delete_label by naming a unique action-object combination.

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 such as create_filter, get_filter, or delete_label. It also omits prerequisites like obtaining a valid filter_id from list_filters or any conditions that should precede deletion.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Delete a Gmail label,' offering no information about irreversibility, whether messages are affected, or any cascading consequences. For a destructive operation this is a notable gap.

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

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

The description is a single, direct sentence with no filler. It front-loads the action and resource, making it immediately scannable and efficient.

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 one parameter and an output schema, the description covers the core purpose adequately. However, it lacks any mention of side effects or permanent consequences, which would be expected for a delete operation without annotations. It is minimally viable but not 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 description coverage is 100%, with the id parameter already described as the 'ID of the label to delete.' The description adds no additional parameter context, but the schema fully covers it, so the baseline of 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 clearly states the action ('Delete') and the resource ('a Gmail label'), which is specific and unambiguous. It naturally distinguishes itself from sibling tools like create_label, update_label, and delete_filter.

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 the sibling label-related tools (create_label, update_label, get_or_create_label) or delete_filter. There are no exclusions or context about prerequisites, such as whether the label must exist or whether it is currently applied.

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?

No annotations are present, so the description carries the full burden, yet it discloses only the basic download action. It omits side effects such as file overwrite behavior, whether save_path must already exist, and what happens when the attachment or message is missing. For a tool that writes to the filesystem, this is a significant gap.

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?

A single eight-word sentence with the verb front-loaded and zero filler. Every word earns its place, and nothing is redundant with the schema or parameters.

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?

The output schema presumably covers return values and the schema documents all parameters, but the description omits usage context and safety caveats for a disk-writing operation: collision handling, path creation behavior, and relation to sibling email tools. For a non-annotated tool, this is only minimally viable.

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% — every parameter has a description, including defaults for filename and save_path. The phrase 'specified location' loosely maps to save_path but adds no syntax, path-format, or behavior detail beyond what the schema already documents, 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 (download) plus the resource (email attachment) and the target behavior (to a specified location). No sibling tool retrieves attachment binaries — send_email composes and read_email reads messages — so an agent can distinguish it without opening 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?

The description gives no when-to-use guidance, prerequisites, or exclusions. It never connects to related flows like read_email or send_email, leaving the agent to infer the tool's role solely from its name.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic action and does not mention whether the email is saved as a draft rather than sent, any side effects, required permissions, or limitations. It is not misleading, so it avoids a score of 1.

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

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

The description is a single, clear sentence with no filler or repetition. It is well front-loaded, but it is so terse that it omits useful qualifying information that would justify 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?

Despite having 10 parameters, no annotations, and an output schema, the description offers only a bare action statement. It lacks context about the draft's relationship to sending, threading/reply semantics, and how it differs from sibling email tools. The schema covers parameters, so the description is not completely inadequate, but it is not sufficient for confident tool selection in complex scenarios.

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 all 10 parameters are already documented in the input schema. The description adds no additional parameter semantics, but the baseline of 3 applies when the schema handles parameter documentation thoroughly.

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 ('Create') and resource ('an email draft'), clearly identifying the tool's action. It does not explicitly differentiate from sibling tools like send_email or modify_email, but the 'draft' wording implies a non-sent email, providing some distinction.

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 such as send_email, modify_email, or read_email. There are no exclusions, prerequisites, or conditions given, leaving the agent to infer usage from the tool name and sibling 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?

With no annotations provided, the description carries the full burden. It clearly identifies a read operation, but doesn't mention potential errors (e.g., invalid filter_id), rate limits, or that no modifications are made. The presence of an output schema somewhat mitigates this.

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 one sentence, front-loading the action and resource. Every word earns its place with zero redundancy.

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

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

Given the tool's simplicity (one parameter), an output schema for return details, and no nested objects, the description is mostly complete. It lacks only explicit behavioral caveats, but these are less critical for a simple read 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?

Schema coverage is 100%, so the schema already documents filter_id as 'ID of the filter to retrieve'. The description adds no additional meaning beyond what the schema provides, meriting the baseline score of 3.

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 ('Get details') and the resource ('a specific Gmail filter'), using a specific verb and object. It distinguishes from siblings like list_filters and create_filter by focusing on retrieving a single filter's details.

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

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

The description implies use when needing details of one specific filter, which contrasts with list_filters for all filters and delete_filter for removal. However, it doesn't explicitly state when not to use it or name alternative tools.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose the key conditional side effect of creating a label when absent, but it does not clarify whether optional visibility parameters are ignored for existing labels or whether any modification occurs on an existing label.

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?

A single, front-loaded sentence that conveys the tool's core behavior without unnecessary words. Every part of the description 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 an output schema exists and the input schema is fully described, the description is mostly sufficient. The main gap is the lack of clarity around behavior when the label already exists, particularly whether optional visibility settings are applied only on creation.

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 provides descriptions for all three parameters, so the tool description adds little parameter-level meaning beyond the schema. The name parameter's purpose is reinforced by the description, but no new semantic details are added.

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-resource pair and clarifies the conditional nature: get by name, create only if missing. This clearly distinguishes it from sibling create_label by conveying an idempotent upsert behavior.

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 use case is implied: call this when you need a label by name and want it created if it doesn't exist. However, there is no explicit guidance about when to prefer create_label or update_label instead, nor any exclusions or alternative 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?

No annotations are provided, so the description carries the behavioral disclosure burden. 'Retrieve' clearly signals a read-only operation, and 'all available' scopes the result, but the description does not mention authentication needs, rate limits, or whether system labels are included. The output schema covers return shape, which keeps this acceptable but not rich.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes directly to understanding the tool's function.

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 listing tool with an output schema, this description is sufficient. An agent can understand exactly what action will be taken and what the result will relate to, and the output schema is expected to resolve any remaining details about return structure.

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 the input schema fully documents that fact. The rubric baseline for zero parameters is 4, and there is nothing further the description needs to add about parameter semantics.

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 ('Retrieve') and a clear resource ('all available Gmail labels'), making the tool's purpose immediately obvious. It is also easily distinguished from sibling label mutation tools like create_label, update_label, and delete_label.

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

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

The description implies the tool is for fetching the complete set of Gmail labels, but it gives no explicit guidance on when to use it versus alternatives. For a zero-parameter list operation this is a minor gap, so it earns an implied-usage score rather than a higher one.

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?

No annotations are provided, so the description carries the full burden. 'Retrieve' clearly signals a read-only operation, but the description does not disclose potential behaviors such as pagination, ordering, or authentication requirements. It is not misleading, but it adds minimal behavioral context beyond the tool's basic action.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes to understanding the tool's purpose.

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 list operation with an output schema available, the description is essentially complete. It lacks only auxiliary context such as auth expectations or performance caveats, which are not critical given the tool's simplicity.

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, so there is no parameter semantics for the description to explain. The schema coverage is trivially 100%, and the description does not need to add parameter details that do not exist.

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 ('Retrieve') and a clear resource ('all Gmail filters'), making the tool's function immediately obvious. It also distinguishes itself from siblings like get_filter (single filter) and list_email_labels (labels, not filters).

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 'all Gmail filters' implies this tool is for retrieving the full set of filters rather than a single one, but it does not explicitly state when to use it instead of get_filter or other filter-related siblings. Usage context is present only by implication.

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?

No annotations are present, so the description carries the full burden of behavioral disclosure. It only says 'Modify email labels' and offers a folder metaphor, but it does not reveal whether label changes replace existing labels, whether add/remove parameters are cumulative, what side effects occur on the message, or what response to expect from a mutating operation.

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?

A single sentence with no filler; the parenthetical clarifies the domain concept of labels as folders. The core action is front-loaded, making it easy to scan.

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 presence of four parameters with overlapping semantics (label_ids vs add/remove), the tool's mutation behavior needs more context. The description lacks guidance on how the three label parameters interact, whether this is single-message only, and what the output schema contains. The existing output schema reduces the need to explain return values, but this is still incomplete for a mutating 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?

Schema description coverage is 100%, so the schema already documents each parameter individually. The description adds only a generic labels/folders mapping and does not clarify the semantic difference between label_ids, add_label_ids, and remove_label_ids, but the baseline 3 is appropriate because the schema handles parameter documentation.

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

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

The description states a specific action ('Modify email labels') and clarifies the resource ('email') and conceptual scope ('move to different folders'). It is clear enough to distinguish from unrelated sibling tools like send_email or create_filter, though it does not explicitly single out batch_modify_emails as a sibling for bulk operations.

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?

There is no guidance on when to use this tool versus alternatives such as batch_modify_emails or trash_email. The description implies it is for modifying labels, but it does not state exclusions, prerequisites, or single-vs-batch usage 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Retrieve,' implying a read operation, but does not disclose whether reading marks the email as read, whether authentication/scopes are required, or how invalid message IDs are handled. The minimal one-liner leaves key side-effect questions unanswered.

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?

One sentence with zero filler and the operative verb 'Retrieve' front-loaded. It is efficient, though it sacrifices substance for brevity; this is acceptable given the simple signature, so it earns a 4 rather than a 5.

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?

The tool is simple (one parameter, output schema present), so return-value coverage is handled. However, with no annotations and 17 sibling tools, the absence of usage guidance and side-effect disclosure leaves the definition incomplete for an agent deciding between read_email, download_attachment, and search_emails.

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 single parameter message_id is already documented as 'ID of the email message to retrieve.' The tool description adds no extra meaning beyond the schema, matching the baseline of 3 for high-coverage schemas.

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 clear verb and resource: 'Retrieve the content of a specific email.' It is distinguishable from siblings like search_emails (finds emails), send_email (creates outgoing mail), and trash_email (mutates state). However, it does not explicitly mention that retrieval is by message_id, nor does it contrast with download_attachment, so it falls just short of full 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?

There is no guidance on when to use this tool versus the 17 siblings. It does not say that the caller should first obtain a message_id from search_emails, nor does it exclude use cases such as retrieving only attachments. No context, no exclusions, no alternatives—score reflects the complete absence of usage direction.

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 phrase 'using Gmail search syntax' adds useful behavioral context: queries should use Gmail-specific operators like 'from:' or 'subject:'. However, there are no annotations, and the description does not explicitly state that the operation is read-only, mention authentication or scope, or describe what the returned results contain.

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

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

The description is a single, front-loaded sentence with no filler. 'Search for emails' is somewhat redundant with the tool name, but 'using Gmail search syntax' is the key differentiating information and is placed immediately, making the description appropriately compact.

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 search tool with an output schema, the description provides the core purpose and query syntax. However, it omits usage guidance, any indication of read-only behavior, and any context about what scope of emails is searched, leaving the agent to rely on schema and sibling names.

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 both query and max_results are already documented in the schema. The description adds value by clarifying that query uses Gmail search syntax, but it adds nothing about max_results or result limits, so the schema carries most of the parameter burden.

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

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

The description states a clear verb and resource: 'Search for emails', and adds the specific query mechanism 'using Gmail search syntax'. It does not explicitly differentiate itself from sibling tools, but list_email_labels, download_attachment, and batch_modify_emails are obviously different operations, so the purpose is still 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?

There is no guidance about when to use this tool instead of list_email_labels, download_attachment, or batch_modify_emails, and no mention of when not to use it. An agent would have to infer the appropriate choice purely from sibling tool names, which is minimal implied 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Send a new email' implies an action but does not disclose that sending is irreversible, whether replies via thread_id/in_reply_to behave differently, how attachments are handled, or any permission or rate-limit implications. The description adds little beyond the tool name.

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

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

The description is a single short sentence with no wasted words, but it is under-specified rather than genuinely concise. For a tool with 10 parameters and no annotations, 'Send a new email' is too minimal to serve as a useful description.

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, the lack of annotations, and the presence of sibling tools like draft_email and modify_email, this description is incomplete. It does not explain send semantics, reply behavior, attachment expectations, or when to choose this tool over alternatives. The rich schema and output schema compensate for some gaps, but not the operational 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 input schema already documents all 10 parameters clearly. The description adds no parameter-level meaning beyond 'new email,' but the schema carries the load, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Send a new email' clearly identifies a send operation on an email. It is clear enough to separate sending from reading, searching, or modifying, but it does not explicitly differentiate itself from sibling tools like draft_email or modify_email.

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

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

There is no guidance about when to use this tool versus alternatives. The description only says 'Send a new email,' without mentioning when drafting, modifying, batching, or searching would be more appropriate. No exclusions or alternative tool references are provided.

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

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

No annotations are present, so the description must carry the full behavioral burden. It states only the high-level action and does not disclose whether trashing is reversible, whether special permissions are needed, or how it relates to permanent deletion.

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

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

The description is a single, front-loaded sentence with no filler words. It is efficient, though slightly too terse to cover usage or behavioral context, so it falls short of 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?

For a simple tool with one parameter and an output schema, the description covers the essential call. However, the absence of usage guidance and behavioral detail leaves gaps when an agent must choose between this and batch_trash_emails.

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 describes message_id as 'ID of the email message to trash' with 100% coverage. The description adds no extra meaning about the parameter, so the baseline of 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 clearly states the action ('move') and the resource ('an email') with its destination ('trash'). It is immediately understandable and implicitly distinguishes itself from batch_trash_emails by targeting a single email.

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

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

No guidance is provided about when to use this tool versus alternatives. Sibling tools include batch_trash_emails and modify_email, but the description does not mention them or any selection criteria such as 'use this for a single email.'

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

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

Annotations are absent, so the description carries the full burden of behavioral disclosure. It only states that an existing label is updated, but fails to explain critical behaviors such as whether omitted optional parameters are left unchanged or reset, whether system labels are updatable, or whether the operation is idempotent. No behavioral traits beyond the tool's literal meaning are disclosed.

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

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

The description is a single, front-loaded sentence with no filler or wasted words. It is appropriately concise, though it leans toward under-specification; a longer sentence with a few behavioral details would still be concise and would improve 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?

With a 100%-covered schema and an output schema present, the tool is minimally callable: id is required and optional fields are documented. However, the description omits important contextual information about partial-update semantics (what null values mean), system-label limitations, and the relationship to sibling label tools. These gaps prevent the definition from being fully complete for an agent choosing and invoking 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 description coverage is 100%, so the baseline is 3. The description adds no parameter-level meaning, but the schema already documents each parameter clearly (e.g., 'New name for the label', 'labelShow, labelShowIfUnread, or labelHide'). The description neither improves nor degrades the parameter understanding provided by 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 'Update an existing Gmail label' uses a specific verb ('update') and resource ('existing Gmail label'), making the tool's purpose immediately clear and distinguishing it from sibling tools like create_label and delete_label. No ambiguity remains about the operation being performed.

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 given about when to use this tool versus alternatives such as create_label, get_or_create_label, or delete_label. The description does not mention exclusions, prerequisites, or when to prefer another sibling tool, leaving the agent to infer usage from the name and schema alone.

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