Gmail MCP Server

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool performs an addition operation but doesn't disclose important traits: whether this requires specific permissions, if delegates have limited vs full access, whether the operation is reversible (hinting at 'remove_delegate'), rate limits, or what happens on success/failure. For a mutation tool with zero annotation coverage, this leaves significant gaps.

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

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

The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple tool with one parameter and gets straight to the point without unnecessary elaboration.

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

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

For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'delegate' means in this context, what permissions delegates receive, whether there are limits on delegate counts, or what the tool returns. Given the complexity of account delegation and the lack of structured data, the description should provide more contextual information.

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

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

Schema description coverage is 100%, with the single parameter 'delegateEmail' fully documented in the schema. The description adds no parameter-specific information beyond what's already in the schema (it doesn't explain email format requirements, domain restrictions, or validation rules). Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the action ('Adds') and resource ('delegate to the specified account'), providing a specific verb+resource combination. It distinguishes from sibling tools like 'remove_delegate' and 'list_delegates' by specifying the add operation, though it doesn't explicitly differentiate from other account modification tools like 'update_auto_forwarding'.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing admin permissions), when delegation is appropriate, or how this differs from similar tools like 'create_forwarding_address' or 'update_auto_forwarding' that also manage account access. The agent must infer usage from the tool 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 full burden but only states the action without behavioral details. It does not disclose if deletion is permanent or reversible, permission requirements, rate limits, error handling, or what happens to associated data. This is inadequate for a destructive 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?

The description is extremely concise with just three words, front-loading the key action and target. There is no wasted language, making it efficient for quick understanding, though this brevity contributes to gaps in other dimensions.

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 destructive tool with no annotations and no output schema, the description is incomplete. It lacks critical context such as the permanence of deletion, success/failure indicators, or how it differs from sibling tools like 'trash_message'. This leaves significant gaps for safe and effective use.

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

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

Schema description coverage is 100%, so the schema fully documents the 'ids' parameter. The description adds no additional meaning beyond implying multiple IDs are needed, which is already clear from the schema. Baseline score of 3 is appropriate as 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 clearly states the action ('Delete') and target ('multiple messages'), which is specific and unambiguous. However, it does not explicitly differentiate from its sibling 'delete_message' (singular deletion), missing an opportunity to clarify the batch nature versus individual deletion.

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 like 'delete_message' or 'trash_message'. The description lacks context about prerequisites, such as needing message IDs, or when batch deletion is preferred over other methods.

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 full burden for behavioral disclosure. While 'modify' implies mutation, it doesn't specify permission requirements, whether changes are reversible, rate limits, or what happens if label IDs don't exist. For a batch mutation tool with zero annotation coverage, this leaves significant behavioral 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?

The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for the tool's complexity and front-loads the essential information about modifying labels on multiple messages.

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 no annotations and no output schema, the description is insufficiently complete. It doesn't address critical context like error handling, response format, atomicity of batch operations, or how it differs from single-message modification. The 100% schema coverage helps, but doesn't compensate for missing behavioral and output information.

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

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

Schema description coverage is 100%, so the schema already fully documents all three parameters (ids, addLabelIds, removeLabelIds). The description adds no additional parameter semantics beyond what's in the schema, such as format examples, constraints, or relationships between parameters. The baseline score of 3 reflects adequate but minimal value addition.

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') and resource ('labels on multiple messages'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'modify_message' by specifying batch operations, though it doesn't explicitly contrast with other label-related tools like 'create_label' or 'update_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 provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer batch_modify_messages over modify_message for single messages, or how it relates to label management tools like create_label or update_label. There are no usage prerequisites or exclusions 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 full burden for behavioral disclosure. It mentions the 'raw' parameter mechanics but fails to describe key behaviors: whether this requires Gmail authentication, if drafts are saved automatically, what happens on conflicts with threadId, or the return format. For a creation tool with mutation implications, this leaves significant gaps.

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 brief (two sentences) and front-loaded with the core purpose. The second sentence about 'raw' parameter mechanics is relevant but could be more integrated. There's no wasted text, though it could be more structured with usage guidance.

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 8 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the tool's behavior upon creation (e.g., where drafts are stored, return values), parameter conflicts beyond 'raw', or authentication requirements. For a complex creation tool in Gmail, this leaves too much unspecified.

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

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

Schema description coverage is 100%, so the schema fully documents all 8 parameters. The description adds minimal value by noting the 'raw' parameter mechanics (it overrides other fields), which is useful context not in the schema. However, it doesn't explain parameter interactions beyond this single note, maintaining the baseline score.

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

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

The description clearly states the action ('Create a draft email') and resource ('in Gmail'), making the purpose unambiguous. However, it doesn't differentiate this from sibling tools like 'send_draft' or 'send_message' that might also involve email creation, leaving room for improvement in distinguishing from alternatives.

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 'send_message' or 'send_draft'. It mentions the 'raw' parameter mechanics but doesn't explain when to use raw versus structured parameters (to, cc, etc.), which is a critical usage consideration given the parameter conflict.

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 fails completely. It doesn't indicate whether this is a read-only or mutating operation, what permissions might be required, whether the filter creation is reversible, or what happens on success/failure. For a tool that presumably creates persistent filters in a mail system, this lack of behavioral information is a critical 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?

While technically concise with only two words, this represents under-specification rather than effective brevity. The description doesn't front-load important information and fails to provide the minimal context needed for tool selection. In conciseness scoring, under-specification that leaves critical gaps is penalized, making this a 2 rather than a higher score for brevity.

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 (2 required parameters with nested objects), lack of annotations, and absence of an output schema, the description is completely inadequate. It doesn't explain what the tool returns, what happens after filter creation, or any behavioral aspects. For a tool that presumably creates persistent filtering rules in a mail system, this minimal description fails to provide the necessary context for effective use.

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 description coverage is 100%, so the schema already documents both parameters ('criteria' and 'action') and their sub-properties thoroughly. The description adds no parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.

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 'Creates a filter' is a tautology that merely restates the tool name without adding meaningful context. It doesn't specify what type of filter is being created (e.g., Gmail message filter), what resource it operates on, or how it differs from sibling tools like 'delete_filter' or 'list_filters'. While the verb 'creates' is clear, the lack of specificity makes this minimally informative.

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 absolutely no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, appropriate contexts, or comparisons to sibling tools like 'list_filters' or 'delete_filter'. The agent receives no help in determining when this specific creation tool should be selected over other available options.

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 states 'Creates' which implies a write/mutation operation, but doesn't specify permissions required, side effects (e.g., whether it sends verification emails), rate limits, or what happens on failure. For a creation tool with zero annotation coverage, this lack of behavioral detail 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?

The description is extremely concise with just three words, making it front-loaded and efficient. There's no wasted language or redundancy, though this brevity contributes to the overall inadequacy of the description for guiding tool usage.

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 (a write operation with no annotations or output schema), the description is incomplete. It doesn't explain what a forwarding address is, how it integrates with the email system, what the creation process entails, or what happens after invocation. For a mutation tool in a rich sibling ecosystem, this minimal description leaves critical gaps in understanding.

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

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

Schema description coverage is 100%, with the single parameter 'forwardingEmail' well-documented in the schema as 'An email address to which messages can be forwarded'. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage without compensating value.

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

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

The description 'Creates a forwarding address' is a tautology that merely restates the tool name without adding specificity. It doesn't explain what a forwarding address is, what resource it creates, or how it differs from similar tools like 'create_filter' or 'create_send_as'. While the verb 'creates' is clear, the object 'forwarding address' lacks context about its function or domain.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing admin permissions), use cases (e.g., setting up email redirection), or relationships to sibling tools like 'delete_forwarding_address' or 'get_forwarding_address'. Without any contextual cues, an agent must infer usage 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 states the tool creates a label but doesn't mention any behavioral traits such as required permissions, whether creation is idempotent, rate limits, or what happens on failure (e.g., duplicate names). This leaves significant gaps 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, efficient sentence with zero waste. It's front-loaded and appropriately sized for the tool's purpose, though it could benefit from more detail given the lack of annotations and output 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?

Given the tool's complexity (4 parameters, nested objects, mutation operation) and lack of annotations and output schema, the description is incomplete. It doesn't explain return values, error conditions, or behavioral context, making it inadequate for safe and effective use by an AI agent.

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

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

Schema description coverage is 100%, so the schema fully documents all parameters (name, messageListVisibility, labelListVisibility, color). The description adds no additional meaning beyond the schema, such as examples or constraints (e.g., name uniqueness). Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description 'Create a new label' clearly states the action (create) and resource (label), but it's vague about what a 'label' means in this context (e.g., email label, organizational tag). It doesn't differentiate from siblings like 'patch_label' or 'update_label', which handle modifications rather than creation.

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 like 'patch_label' or 'update_label'. The description lacks context about prerequisites (e.g., permissions, existing labels) or exclusions, leaving the agent to infer usage from tool names 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 full burden for behavioral disclosure but only states the basic action ('creates'). It doesn't mention whether this requires specific permissions, what happens on success/failure, if there are rate limits, or how the alias integrates with existing email settings. This leaves significant gaps 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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand at a glance.

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

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

For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after creation (e.g., success response, error conditions), nor does it provide context about permissions, limitations, or how this tool differs from similar sibling tools like 'update_send_as'.

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

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

Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema, which meets the baseline expectation when schema coverage is high.

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 ('creates') and the resource ('custom send-as alias'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'patch_send_as' or 'update_send_as', which would require more specificity about what distinguishes creation from modification.

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 'patch_send_as' or 'update_send_as', nor does it mention prerequisites such as required permissions or context. It simply states what the tool does without indicating appropriate usage scenarios.

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 full burden for behavioral disclosure. 'Delete a draft' implies a destructive mutation, but it doesn't specify whether this is permanent or reversible, what permissions are required, whether it's synchronous or asynchronous, or what happens on success/failure. For a destructive operation with zero annotation coverage, this leaves critical behavioral traits undisclosed.

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 at just three words, with zero wasted language. It's front-loaded with the core action and resource. While under-specified for completeness, it achieves perfect conciseness by eliminating all unnecessary verbiage.

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 destructive mutation tool with no annotations and no output schema, the description is severely incomplete. It doesn't explain what 'delete' means operationally, what the expected outcome is, error conditions, or how this differs from similar deletion/trash operations among siblings. The agent lacks sufficient context to use this tool safely and effectively.

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

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

With 100% schema description coverage for the single parameter 'id', the schema already fully documents the parameter's purpose and type. The description doesn't add any parameter-specific information beyond what's in the schema, but since there's only one well-documented parameter, this doesn't create a significant gap. The baseline for high schema coverage with minimal parameters is appropriately met.

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 'Delete a draft' is essentially a tautology that restates the tool name with minimal elaboration. It specifies the verb ('Delete') and resource ('a draft'), but lacks any distinguishing details about scope, permanence, or effects that would differentiate it from similar tools like delete_message or trash_message. This provides only basic purpose identification without meaningful 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 offers no guidance on when to use this tool versus alternatives. With sibling tools like delete_message, trash_message, and delete_thread available, there's no indication of whether this is for permanent deletion versus reversible actions, whether it applies to drafts specifically versus other message types, or any prerequisites. The agent receives zero usage 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 full burden for behavioral disclosure. 'Deletes a filter' implies a destructive mutation, but doesn't specify whether deletion is permanent or reversible, what permissions are required, whether it affects associated data, or what happens on success/failure. For a destructive operation with zero annotation coverage, this leaves critical behavioral traits undocumented.

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 maximally concise at two words ('Deletes a filter'), with zero wasted text. It's front-loaded with the core action and resource. Every word earns its place, though this conciseness comes at the expense of completeness for other dimensions.

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 this is a destructive mutation tool with no annotations, no output schema, and minimal description, the description is incomplete. It doesn't address what happens after deletion, error conditions, or behavioral implications. For a tool that permanently removes data, more context about consequences and requirements would be expected.

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

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

Schema description coverage is 100%, with the single parameter 'id' fully documented in the schema as 'The ID of the filter to be deleted'. The description adds no additional parameter context beyond what the schema provides. According to guidelines, when schema coverage is high (>80%), the baseline score is 3 even with no parameter info in the description.

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 'Deletes a filter' clearly states the action (delete) and resource (filter), providing basic purpose. However, it doesn't differentiate from sibling tools like delete_draft, delete_label, or delete_message, which all follow the same 'delete [resource]' pattern. The purpose is clear but lacks specificity about what distinguishes this particular deletion operation.

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. There's no mention of prerequisites (e.g., needing an existing filter ID), when deletion is appropriate versus modification, or how this differs from related tools like delete_filter versus create_filter or list_filters. The agent must infer usage 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 states the tool deletes a forwarding address, implying a destructive mutation, but lacks details on permissions required, whether the deletion is permanent or reversible, error handling, or rate limits. This is a significant gap for a mutation tool with zero annotation coverage.

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

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

The description is a single, efficient sentence with zero waste. It is front-loaded with the core action and resource, making it easy to parse quickly without unnecessary elaboration.

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

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

Given the tool's complexity as a destructive mutation with no annotations and no output schema, the description is incomplete. It fails to address behavioral aspects like side effects, success/failure responses, or error conditions, which are critical for safe and effective use by an AI agent.

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 100% description coverage, with the parameter 'forwardingEmail' documented as 'The forwarding address to be deleted'. The description adds no additional meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the action ('deletes') and target resource ('the specified forwarding address'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'delete_filter' or 'delete_label' beyond mentioning the specific resource type, which is adequate but not fully distinguishing.

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

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

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an existing forwarding address), exclusions, or comparisons to siblings like 'remove_delegate' or 'delete_send_as', leaving usage context unclear.

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. 'Delete a label' implies a destructive mutation, but it doesn't specify whether this action is reversible, requires specific permissions, has side effects (e.g., affecting associated messages), or provides confirmation. For a destructive tool with zero annotation coverage, this is a significant gap in transparency.

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

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

The description is extremely concise with just three words, front-loading the core action. There's zero wasted language, and it efficiently communicates the tool's primary function without unnecessary elaboration.

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

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

Given that this is a destructive mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like irreversibility, error conditions, or return values. The high schema coverage helps with parameters, but overall context for safe and effective use is lacking.

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 100% description coverage, with the 'id' parameter clearly documented as 'The ID of the label to delete'. The description adds no additional parameter information beyond what the schema provides. According to the rules, when schema_description_coverage is high (>80%), the baseline score is 3 even with no param info in the description.

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 'Delete a label' clearly states the verb ('Delete') and resource ('a label'), which is adequate. However, it doesn't distinguish this tool from other deletion tools like delete_draft, delete_filter, or delete_message, which all follow the same pattern. It's not vague but lacks 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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing label ID), exclusions, or comparisons to similar tools like patch_label or update_label. Without any usage context, the agent must infer 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 effectively communicates that this is a destructive operation ('permanently delete') with immediate effect, which is crucial context. However, it doesn't mention error conditions, permissions required, or what happens if the message doesn't exist - leaving some behavioral gaps.

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

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

The description is a single, efficient sentence that front-loads the most critical information ('immediately and permanently delete'). Every word earns its place, with no wasted verbiage or redundant information.

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

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

For a destructive operation with no annotations and no output schema, the description provides adequate but incomplete context. It clearly communicates the irreversible nature of the action, which is the most critical information, but lacks details about error handling, return values, or permissions - leaving the agent with some uncertainty about how to handle edge cases.

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 has 100% description coverage, with the single parameter 'id' clearly documented in the schema. The description doesn't add any additional parameter context beyond what's already in the schema, so it meets the baseline of 3 for high schema coverage without adding extra value.

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

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

The description clearly states the specific action ('delete'), resource ('message'), and key behavioral traits ('immediately and permanently'). It distinguishes from sibling tools like 'trash_message' (which likely moves to trash) and 'batch_delete_messages' (which handles multiple messages).

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 'trash_message' or 'batch_delete_messages'. It doesn't mention prerequisites, permissions needed, or any context for choosing this specific deletion method over other options available in the sibling tool list.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a destructive operation ('deletes') but doesn't specify whether this is permanent, requires specific permissions, or has side effects. For a mutation tool with zero annotation coverage, this is insufficient.

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

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

The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, with every word earning 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 that this is a destructive tool with no annotations and no output schema, the description is incomplete. It lacks critical information such as confirmation of deletion, error conditions, or what happens if the alias doesn't exist, leaving significant gaps for an AI agent.

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 description coverage is 100%, with the parameter 'sendAsEmail' documented as 'The send-as alias to be deleted'. The description adds no additional meaning beyond this, so it meets the baseline of 3 where the schema handles parameter documentation adequately.

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 ('deletes') and the resource ('specified send-as alias'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'delete_forwarding_address' or 'delete_label', which would require 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 provides no guidance on when to use this tool versus alternatives like 'patch_send_as' or 'update_send_as', nor does it mention prerequisites such as needing an existing alias to delete. It simply states what the tool does without 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 of behavioral disclosure. It states the tool performs a deletion, implying a destructive mutation, but doesn't specify whether this action is reversible, requires specific permissions, has side effects (e.g., on email sending), or what happens on success/failure. For a destructive tool with zero annotation coverage, this is a significant gap in transparency.

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

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the key action and resource, making it easy to parse. Every word serves a purpose, with zero redundancy or fluff.

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 (a destructive mutation with 2 required parameters), lack of annotations, and no output schema, the description is minimally adequate but incomplete. It covers the basic purpose but misses critical behavioral details (e.g., irreversibility, error conditions) and usage context. The high schema coverage helps, but the description doesn't fully compensate for the missing safety and 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%, with both parameters ('sendAsEmail' and 'id') clearly documented in the schema. The description mentions these parameters generically ('specified S/MIME config for the specified send-as alias') but adds no additional semantic context beyond what the schema already provides. This meets the baseline score of 3 for high schema coverage.

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

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

The description clearly states the action ('Deletes') and the resource ('S/MIME config for the specified send-as alias'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'delete_send_as' or 'set_default_smime_info', which would require more specific context about what distinguishes S/MIME config deletion from other deletion 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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether the S/MIME config must exist), exclusions, or related tools like 'insert_smime_info' or 'set_default_smime_info' for managing S/MIME configurations. The agent must infer usage from the name and parameters 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 full burden for behavioral disclosure. 'Delete a thread' implies a destructive operation, but doesn't specify whether this is permanent or reversible, what permissions are required, whether it affects associated messages, or what happens on success/failure. This is inadequate for a destructive tool with zero annotation coverage.

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 at just three words, with zero wasted language. It's front-loaded with the core action and resource, though this brevity comes at the cost of completeness. Every word earns its place in conveying the basic operation.

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 destructive operation with no annotations and no output schema, the description is severely incomplete. It doesn't explain what 'delete' means in this context (permanent vs. reversible), what happens to associated messages, what permissions are required, or what the tool returns. Given the complexity of deletion operations and lack of structured metadata, this description provides insufficient context.

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

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

Schema description coverage is 100%, with the single parameter 'id' clearly documented as 'The ID of the thread to delete'. The description adds no additional parameter information beyond what's already in the schema, which is acceptable given the high schema coverage. The baseline of 3 is appropriate when the schema does the heavy lifting.

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

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

The description 'Delete a thread' is a tautology that restates the tool name without adding meaningful context. It specifies the verb (delete) and resource (thread), but doesn't distinguish this from sibling tools like 'trash_thread' or 'delete_message', leaving ambiguity about what type of deletion this performs.

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 like 'trash_thread' or 'delete_message'. The description offers no context about prerequisites, permissions needed, or appropriate scenarios for this deletion operation versus other thread-related 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 states the tool 'gets' an attachment, implying a read-only operation, but doesn't specify if this requires authentication, returns binary data or metadata, has rate limits, or handles errors. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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, efficient sentence with zero waste. It's front-loaded with the core purpose and uses minimal words to convey the essential action, making it easy for an agent to parse quickly.

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

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

Given no annotations, no output schema, and a simple input schema, the description is incomplete. It doesn't cover what the tool returns (e.g., attachment content or metadata), error conditions, or usage context. For a retrieval tool with 2 required parameters, this minimal description leaves the agent under-informed about key behavioral aspects.

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 both parameters ('messageId' and 'id') clearly documented in the schema. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't explain format examples or relationships between parameters). Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description 'Get a message attachment' clearly states the action (get) and resource (message attachment). It distinguishes this tool from siblings like 'get_message' or 'get_draft' by specifying it retrieves attachments rather than messages themselves. However, it doesn't explicitly contrast with potential attachment-related siblings (none exist in the list), so it's not a perfect 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a message ID first from 'get_message'), nor does it differentiate from other retrieval tools like 'get_message' that might include attachments. The agent must infer usage from the tool name and parameters 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?

No annotations are provided, so the description must fully disclose behavioral traits. It only states the action ('Gets') without mentioning permissions required, rate limits, response format, or whether it's read-only. This leaves significant gaps in understanding how the tool behaves, warranting a score of 2.

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

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

The description is a single, efficient sentence ('Gets auto-forwarding settings') that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, earning the highest score for conciseness.

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 lack of annotations and output schema, the description is incomplete. It does not explain what the tool returns (e.g., settings details) or any behavioral aspects like error conditions. For a tool with no structured data support, this minimal description is inadequate, resulting in a low score.

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

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter information, which is appropriate, resulting in a baseline score of 4 as it does not need to compensate for any schema gaps.

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 'Gets auto-forwarding settings' clearly states the verb ('Gets') and resource ('auto-forwarding settings'), making the purpose unambiguous. However, it does not differentiate from sibling tools like 'get_forwarding_address' or 'update_auto_forwarding', which limits its score to 4 instead of 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 provides no guidance on when to use this tool versus alternatives. For example, it does not specify if this is for retrieving current settings before using 'update_auto_forwarding' or how it differs from 'get_forwarding_address'. This lack of contextual usage information results in a low score.

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 full burden. It only states the action without disclosing behavioral traits like read-only nature, error handling, authentication needs, or rate limits. For a retrieval tool, this lack of detail leaves the agent uncertain about safety and performance implications.

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 with a single sentence that directly states the tool's function. It's front-loaded and wastes no words, making it easy to parse quickly, though this brevity contributes to gaps in other dimensions.

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 lack of annotations and output schema, the description is incomplete. It doesn't explain what a delegate is, what data is returned, or any behavioral context, making it inadequate for an agent to fully understand how to use this tool effectively in a real-world scenario.

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 100% description coverage, clearly documenting the single parameter 'delegateEmail'. The description doesn't add extra meaning beyond the schema, but with high coverage and only one parameter, a baseline of 4 is appropriate as the schema adequately handles the 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 states the action ('Gets') and resource ('the specified delegate'), which clarifies the basic purpose. However, it's vague about what a 'delegate' is in this context and doesn't differentiate from sibling tools like 'list_delegates' or 'remove_delegate', leaving room for confusion about scope.

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. It doesn't mention prerequisites, such as needing an existing delegate, or contrast it with 'list_delegates' for browsing all delegates, which could lead to misuse in scenarios where listing is more 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?

With no annotations provided, the description carries full burden for behavioral disclosure. 'Get' implies a read operation, but there's no information about authentication requirements, rate limits, error conditions, or what happens if the draft doesn't exist. The description doesn't mention that includeBodyHtml is excluded by default for performance reasons (though the schema does).

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 sentence that states the core purpose without any wasted words. It's front-loaded with the essential information and contains no unnecessary elaboration.

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

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

For a read operation with no annotations and no output schema, the description is inadequate. It doesn't explain what a 'draft' represents in this context, what fields are returned, error handling, or how this differs from retrieving a regular message. The agent would need to guess about the return format and behavior.

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

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

Schema description coverage is 100%, so the schema already fully documents both parameters. The description doesn't add any parameter information beyond what's in the schema - it mentions 'by ID' which corresponds to the 'id' parameter, but provides no additional context about parameter usage or relationships.

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') and resource ('a specific draft by ID'), making the purpose immediately understandable. However, it doesn't differentiate this tool from similar sibling tools like 'get_message' or 'get_thread' which also retrieve specific resources by ID, so it doesn't achieve 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?

The description provides no guidance on when to use this tool versus alternatives. There are multiple similar retrieval tools in the sibling list (get_message, get_thread, get_attachment, etc.), but no indication of when this specific draft retrieval is appropriate versus other get operations or versus list_drafts for browsing.

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 full responsibility for behavioral disclosure. 'Gets a filter' implies a read-only operation but doesn't clarify permissions required, error conditions (e.g., invalid ID), response format, or side effects. For a tool with zero annotation coverage, this is insufficient to inform safe or effective use.

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?

While concise with only two words, the description is under-specified rather than efficiently informative. It lacks front-loaded critical details (e.g., what a filter is, key constraints) and wastes its limited space on a tautology. Conciseness should not come at the expense of utility.

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 no annotations, no output schema, and a minimal description, this tool definition is incomplete for effective use. The agent lacks context on what a 'filter' entails, how results are structured, error handling, or relation to sibling tools. For a read operation in a complex system (Gmail-like), this leaves significant gaps.

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

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

The input schema has 100% description coverage, with the 'id' parameter clearly documented as 'The ID of the filter to be fetched'. The description adds no additional parameter context beyond this, so it meets the baseline score of 3 where the schema does the heavy lifting. No compensation is needed or provided.

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 'Gets a filter' is a tautology that merely restates the tool name without adding meaningful context. It specifies the verb 'gets' and resource 'filter', but fails to distinguish this tool from sibling tools like 'list_filters' or explain what a 'filter' represents in this system (e.g., email filtering rules). This provides minimal value beyond the name itself.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_filters' (for listing multiple filters) or 'create_filter' (for creating new ones), nor does it specify prerequisites (e.g., needing a filter ID) or appropriate contexts. This leaves the agent with no 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('Gets') without details on permissions required, error handling, rate limits, or what the output contains (e.g., metadata, status). For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves in practice.

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

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

The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to scan. Every part of the sentence contributes directly to stating the tool's purpose, adhering to best practices for conciseness in tool definitions.

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 lack of annotations and output schema, the description is incomplete for a tool that likely returns detailed data. It doesn't explain what information is retrieved (e.g., forwarding rules, verification status) or handle edge cases. For a read operation with no structured output documentation, more context is needed to guide the agent effectively.

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 100% description coverage, with the parameter 'forwardingEmail' clearly documented as 'The forwarding address to be retrieved'. The description adds no additional meaning beyond this, such as format examples or constraints. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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 action ('Gets') and resource ('the specified forwarding address'), but it's vague about what 'gets' entails—retrieving metadata, configuration, or status? It doesn't differentiate from sibling tools like 'list_forwarding_addresses' or 'get_auto_forwarding', which handle related resources. The purpose is clear at a basic level but lacks specificity for precise tool selection.

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. Sibling tools include 'list_forwarding_addresses' for listing all addresses and 'get_auto_forwarding' for auto-forwarding settings, but the description doesn't mention these or specify use cases like retrieving details for a single known address. Without such context, the agent must infer usage from the tool 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?

No annotations are provided, so the description carries full burden. It implies a read-only operation ('gets'), but doesn't disclose behavioral traits such as authentication needs, rate limits, error conditions, or what the output contains. For a tool with zero annotation coverage, this is insufficient.

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

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

The description is a single, efficient sentence with no wasted words. It's appropriately sized for a simple tool and front-loads the key information. Every word earns its place.

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

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

Given no annotations, no output schema, and a simple tool with 0 parameters, the description is incomplete. It doesn't explain what IMAP settings are returned, potential errors, or how it fits into the broader context of email configuration tools. More detail is needed for adequate completeness.

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

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

With 0 parameters and 100% schema description coverage, the baseline is 4. The description doesn't add parameter details, but that's unnecessary since there are no parameters to document. It adequately handles the parameter semantics by omission.

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 'Gets IMAP settings' clearly states the action (gets) and resource (IMAP settings), but it's vague about scope and doesn't differentiate from siblings like 'get_pop' or 'get_auto_forwarding'. It provides basic purpose but lacks specificity about what IMAP settings are retrieved.

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

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

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions, and it doesn't reference sibling tools like 'update_imap' for modification. This leaves the agent without 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?

With no annotations provided, the description carries full burden for behavioral disclosure. It states a read operation ('Get') but doesn't mention permissions, rate limits, error handling, or response format. For a tool with zero annotation coverage, this is insufficient to inform the agent about behavioral traits beyond the 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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place, achieving optimal conciseness for this simple tool.

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

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

Given the tool's low complexity (1 parameter, 100% schema coverage) but lack of annotations and output schema, the description is minimally adequate. It states what the tool does but misses behavioral context and usage guidelines. For a read operation with no output schema, more detail on response format would improve completeness.

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

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

Schema description coverage is 100%, with the single parameter 'id' documented in the schema as 'The ID of the label to retrieve'. The description adds no additional meaning beyond this, such as ID format or examples. Baseline 3 is appropriate when the schema already fully describes parameters.

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

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

The description clearly states the action ('Get') and resource ('a specific label by ID'), making the purpose understandable. It distinguishes from siblings like 'list_labels' by specifying retrieval of a single item, though it doesn't explicitly name alternatives. A 5 would require explicit 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 on when to use this tool versus alternatives like 'list_labels' or 'patch_label'. The description implies usage for retrieving a known label ID but doesn't state prerequisites, exclusions, or contextual recommendations. This leaves the agent without 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Gets' implies a read-only operation, but it doesn't specify if this requires authentication, what permissions are needed, or how the data is returned (e.g., format, potential errors). For a tool with zero annotation coverage, this leaves significant behavioral gaps.

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 with just three words ('Gets language settings'), front-loaded and free of unnecessary information. Every word contributes directly to stating the tool's purpose, making it efficient and well-structured.

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

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

Given the tool's simplicity (0 parameters, no output schema), the description is minimally adequate but lacks depth. It doesn't explain what 'language settings' includes or the return format, which could be important for an agent to use it correctly. With no annotations, it should provide more context to be fully 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?

The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't add parameter details, which is appropriate since there are none. This meets the baseline of 4 for zero parameters, as no compensation is needed.

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 'Gets language settings' clearly states the action (get) and resource (language settings), making the purpose understandable. However, it's somewhat vague about what 'language settings' specifically entails (e.g., system, user, or application settings) and doesn't distinguish it from sibling tools like 'update_language', which could cause confusion.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'update_language' for modifications or clarify if this is for retrieving current settings versus default configurations. Without such context, the agent lacks clear usage directives.

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 mentions 'format options' (via includeBodyHtml), but doesn't describe other key behaviors: whether it's read-only (implied by 'Get'), error handling for invalid IDs, rate limits, authentication needs, or return format. For a retrieval tool with zero annotation coverage, this leaves significant gaps in understanding how it operates.

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

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

The description is a single, efficient sentence that front-loads the core purpose ('Get a specific message by ID') and adds a useful detail ('with format options'). There's no wasted verbiage, repetition, or unnecessary elaboration—every word earns its place.

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

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

Given the tool's low complexity (retrieval with 2 parameters) and high schema coverage (100%), the description is adequate but incomplete. It lacks output details (no output schema provided), behavioral context (no annotations), and usage guidance. For a simple getter, it's minimally viable but leaves the agent to guess about return values and operational constraints.

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

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

Schema description coverage is 100%, so the schema fully documents both parameters (id and includeBodyHtml). The description adds minimal value beyond the schema by hinting at 'format options', which loosely relates to includeBodyHtml, but doesn't provide additional syntax or context. This meets the baseline of 3 when the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: 'Get a specific message by ID with format options.' It specifies the verb ('Get'), resource ('message'), and key constraint ('by ID'), which distinguishes it from sibling tools like 'list_messages' or 'get_thread'. However, it doesn't explicitly differentiate from 'get_draft' or 'get_thread', which also retrieve specific items by ID, so it's not fully sibling-distinctive.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_messages' for browsing or 'get_thread' for thread-level retrieval, nor does it specify prerequisites (e.g., needing a valid message ID). The agent must infer usage from the name and parameters 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?

No annotations are provided, so the description carries the full burden. It states 'Gets POP settings', implying a read-only operation, but does not disclose behavioral traits like authentication requirements, rate limits, error conditions, or what happens if no settings exist. This is inadequate for a tool with zero annotation coverage.

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 ('Gets POP settings'), consisting of a single, front-loaded sentence with zero waste. It efficiently communicates the core action without unnecessary details, making it highly structured and to the point.

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 (simple read operation) but lack of annotations and no output schema, the description is incomplete. It does not explain what POP settings are, the return format, or any behavioral context, leaving significant gaps for an agent to understand and use the tool effectively.

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 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description does not add parameter semantics, but with no parameters, the baseline is 4 as it does not need to compensate for any gaps.

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 'Gets POP settings' clearly states the verb ('Gets') and resource ('POP settings'), providing a basic purpose. However, it lacks specificity about what POP settings are retrieved (e.g., configuration, status) and does not distinguish it from sibling tools like 'get_imap' or 'update_pop', making it vague in 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. It does not mention prerequisites, context, or exclusions, such as when to use 'get_pop' instead of 'update_pop' or other settings-related tools. This leaves usage unclear.

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 states the tool retrieves profile data but doesn't specify what the profile includes (e.g., email address, display name, settings), whether it requires specific permissions, or how the data is returned (e.g., format, error handling). This leaves significant gaps for a tool that likely involves user data access.

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 that directly states the tool's purpose without any unnecessary words or structural fluff. It's front-loaded and wastes no space, making it easy for an agent to parse quickly.

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

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

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the profile contains, how the data is structured, or potential behavioral aspects like authentication requirements or rate limits. For a tool that retrieves user-specific data, more context is needed to ensure proper use by an AI agent.

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 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description appropriately doesn't discuss parameters, which is efficient and correct for this case. A baseline of 4 is applied since no parameter information is needed.

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') and resource ('current user's Gmail profile'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from similar sibling tools like get_auto_forwarding or get_vacation, which also retrieve user-specific settings, though those are more specific subsets of profile data.

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

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

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., authentication needs), timing considerations, or how it differs from other get_* tools that might retrieve overlapping or related information, leaving the agent to infer usage 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states a read operation ('gets'), implying it's non-destructive, but doesn't cover error conditions (e.g., if the alias doesn't exist), authentication needs, rate limits, or return format. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

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

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

The description is a single, efficient sentence that front-loads the core action ('gets') and resource ('send-as alias'). There is no wasted verbiage or redundancy, making it easy to parse quickly.

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

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

Given no annotations, no output schema, and a simple parameter schema, the description is incomplete. It lacks behavioral details (e.g., error handling), usage context, and output expectations. For a retrieval tool in a complex email system, more guidance is needed to ensure correct agent 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 100%, with the parameter 'sendAsEmail' fully documented in the schema as 'The send-as alias to be retrieved'. The description adds no additional meaning beyond this, such as format examples or constraints. Given the high schema coverage, the baseline score of 3 is appropriate.

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

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

The description clearly states the verb ('gets') and resource ('specified send-as alias'), making the purpose immediately understandable. It distinguishes from siblings like 'list_send_as' (which retrieves multiple) and 'create_send_as'/'update_send_as' (which modify). However, it doesn't explicitly mention that this retrieves a single alias by identifier, which would make it fully specific.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing alias), contrast with 'list_send_as' for multiple aliases, or specify use cases like verifying alias details. Without such context, the agent must infer usage 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 states this is a read operation ('Gets'), but doesn't mention authentication requirements, rate limits, error conditions, or what happens if the specified config doesn't exist. For a retrieval tool with zero annotation coverage, this leaves significant behavioral gaps.

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

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

The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a simple retrieval tool and front-loads the essential information.

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

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

For a 2-parameter retrieval tool with no annotations and no output schema, the description provides basic purpose but lacks important context. It doesn't explain what information is returned, error handling, or how this differs from related S/MIME tools. The completeness is adequate but has clear gaps for effective agent use.

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 description coverage is 100%, with both parameters ('sendAsEmail' and 'id') fully documented in the input schema. The description doesn't add any additional parameter context beyond what's already in the structured data, so it meets the baseline for high schema coverage.

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

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

The description clearly states the action ('Gets') and the resource ('S/MIME config for the specified send-as alias'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_smime_info' or 'set_default_smime_info', which would require more specific scope clarification.

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 'list_smime_info' or 'set_default_smime_info'. It doesn't mention prerequisites, such as needing an existing S/MIME configuration, or contextual constraints for retrieval.

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 full burden for behavioral disclosure. It states it retrieves a thread but doesn't mention what data is returned (e.g., metadata, messages), error handling (e.g., for invalid IDs), or performance considerations (e.g., size of responses). This leaves significant gaps for a read 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?

The description is a single, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for a simple retrieval tool, making it easy to parse quickly.

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

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

Given no annotations and no output schema, the description is incomplete for a retrieval tool. It doesn't explain what data is returned (e.g., thread structure, included messages), error cases, or how 'includeBodyHtml' affects the response size. For a tool with 2 parameters and complex sibling tools, this leaves too much unspecified.

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

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

Schema description coverage is 100%, so the schema fully documents both parameters ('id' and 'includeBodyHtml'). The description adds no additional meaning beyond implying the 'id' parameter is required, which is already clear from the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the action ('Get') and resource ('a specific thread by ID'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_message' or 'list_threads' beyond the specific resource type, which prevents a perfect score.

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 'get_message' (for individual messages) or 'list_threads' (for multiple threads). It lacks any context about prerequisites, such as needing a thread ID from another operation, or exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves settings but doesn't specify if this is a read-only operation, what permissions are required, how data is returned, or any rate limits. This leaves significant gaps in understanding the tool's 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, efficient sentence that directly states the tool's purpose without any wasted words. It's front-loaded and appropriately sized for a simple retrieval tool, making it easy to parse quickly.

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

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

Given the tool's simplicity (0 parameters, no output schema), the description is minimal but insufficient. It lacks details on what 'settings' include, the return format, or behavioral aspects like authentication needs. For a tool with no annotations or output schema, more context is needed to be 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?

The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the input requirements. The description doesn't need to add parameter details, and it correctly implies no inputs are needed, aligning with the schema. A baseline of 4 is appropriate as the description doesn't contradict or add unnecessary information.

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 'Get vacation responder settings' clearly states the action (Get) and resource (vacation responder settings), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'update_vacation' or explain what specific settings are retrieved, which prevents a perfect score.

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 'update_vacation' or other get_* tools. It lacks context about prerequisites, such as whether authentication is needed or if this retrieves current or default settings, leaving usage unclear.

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 implies a write operation ('insert/upload') but doesn't specify permissions needed, whether it's idempotent, what happens on failure, or any rate limits. This leaves significant gaps 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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy 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 mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral aspects like error handling, side effects, or return values, leaving the agent with incomplete information to use the tool effectively.

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 three parameters thoroughly. The description doesn't add any additional meaning or context beyond what the schema provides, such as explaining relationships between parameters or usage examples, meeting the baseline for high schema coverage.

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

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

The description clearly states the action ('insert/upload') and the resource ('S/MIME config for the specified send-as alias'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'delete_smime_info' or 'set_default_smime_info', which would be needed for a score of 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?

No guidance is provided on when to use this tool versus alternatives like 'delete_smime_info' or 'set_default_smime_info', nor any prerequisites or context for its application. The description merely restates the purpose without offering usage instructions.

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 states it's a list operation, implying it's read-only and non-destructive, but doesn't specify details like pagination, sorting, error conditions, or authentication needs. This leaves significant gaps for a tool that likely returns multiple items.

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 wasted words. It's front-loaded with the core action and resource, making it efficient and easy to parse.

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

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

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but minimal. It covers the basic purpose but lacks behavioral details (e.g., return format, error handling) that would help an agent use it effectively, especially without annotations to fill gaps.

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

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

The input schema has 0 parameters with 100% coverage, so there are no parameters to document. The description adds value by clarifying the scope ('for the specified account'), which isn't contradicted by the schema. Baseline is 4 for zero parameters, as the description provides context beyond the empty schema.

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

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

The description clearly states the verb ('Lists') and resource ('delegates for the specified account'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_delegate' or 'remove_delegate', which might handle individual delegates differently, so it's not a perfect 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention siblings like 'get_delegate' (for a single delegate) or 'add_delegate'/'remove_delegate' (for modifications), leaving the agent to infer usage from tool names 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 full burden for behavioral disclosure. It mentions that drafts are listed from 'the user's mailbox' which implies personal scope, but fails to describe important behaviors like whether this is a read-only operation, how results are ordered/paginated, authentication requirements, or rate limits. For a list operation with zero annotation coverage, this leaves significant gaps.

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

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

The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a list operation and front-loads the essential information.

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

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

For a list operation with 4 parameters and no output schema, the description is insufficient. It doesn't explain what the return format looks like (e.g., list of draft objects with IDs, subjects), doesn't mention pagination behavior, and provides no context about authentication or error conditions. The lack of annotations exacerbates these gaps.

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

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

The description provides no parameter information, but the input schema has 100% description coverage with clear documentation for all 4 parameters. This meets the baseline score of 3 where the schema does the heavy lifting, though the description adds no value beyond what's already in the structured schema.

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

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

The description clearly states the verb ('List') and resource ('drafts in the user's mailbox'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'list_messages' or 'list_threads' that also list mailbox content, which prevents a perfect score.

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 'list_messages' or 'get_draft', nor does it mention any prerequisites or constraints. It simply states what the tool does without contextual usage information.

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 states the action ('Lists') but does not describe key behaviors like whether this requires authentication, if it returns a paginated list, what the output format is (e.g., list of filter objects), or any rate limits. For a tool with zero annotation coverage, this is a significant gap in transparency.

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

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

The description is a single, clear sentence that directly states the tool's function without any extraneous details. It is front-loaded and efficiently communicates the core purpose, making it easy to parse and understand quickly.

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

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

Given the lack of annotations and output schema, the description is incomplete for effective tool use. It does not explain what the tool returns (e.g., a list of filter objects, their structure, or any metadata), which is critical for an agent to handle the output correctly. For a list operation with no structured output information, more context is 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 input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description does not mention any parameters, which is appropriate since none exist. It effectively compensates by not introducing unnecessary information, aligning with the schema's completeness.

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

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

The description clearly states the verb ('Lists') and resource ('message filters of a Gmail user'), making the purpose understandable. However, it does not explicitly differentiate from sibling tools like 'get_filter' (which retrieves a specific filter) or 'create_filter' (which creates one), leaving some ambiguity about when to choose this tool over others for filter-related 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?

The description provides no guidance on when to use this tool versus alternatives. It lacks context such as whether this is for retrieving all filters at once, if it's the primary method for browsing filters, or how it compares to 'get_filter' for specific filter details. This absence of usage instructions leaves the agent without clear 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?

No annotations are provided, so the description carries full burden. It states the action ('Lists') but doesn't disclose behavioral traits such as authentication requirements, rate limits, pagination, return format, or whether it's read-only. For a list operation with zero annotation coverage, this is a significant gap in transparency.

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

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

The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly without unnecessary elaboration.

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

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

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., list format, fields), authentication needs, or error conditions. For a tool in a context with many siblings and no structured output, more detail is warranted to ensure proper agent usage.

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

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is appropriate, but it implies an unspecified account parameter ('for the specified account'), slightly exceeding the schema. This minor addition doesn't detract from the high baseline.

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

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

The description clearly states the verb ('Lists') and resource ('forwarding addresses for the specified account'), making the purpose unambiguous. However, it doesn't distinguish this tool from similar siblings like 'get_forwarding_address' (which likely retrieves a single address) or 'list_delegates' (which lists a different resource), missing 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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., account specification), exclusions, or comparisons to siblings like 'get_forwarding_address' or 'list_delegates', leaving usage context implied at best.

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 full burden for behavioral disclosure. While 'List all labels' implies a read-only operation, the description doesn't address important behavioral aspects like whether this returns all labels at once or uses pagination, what format the labels are returned in, or any authentication requirements. For a tool with zero annotation coverage, this represents significant gaps.

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

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

The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple list operation and front-loads the essential information, 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 simple list operation with no parameters and no output schema, the description provides the minimum viable information about what the tool does. However, without annotations or output schema, the agent lacks important context about the return format, pagination behavior, and authentication requirements that would be helpful for proper tool invocation.

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

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

With 0 parameters and 100% schema description coverage, the baseline score would be 4 even with no parameter information in the description. The description correctly aligns with the empty parameter schema by not mentioning any parameters, which is appropriate for this simple list operation.

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 ('List all labels') and target resource ('in the user's mailbox'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from its sibling 'get_label' (which presumably retrieves a single label), missing explicit differentiation that would warrant a perfect score.

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. With sibling tools like 'get_label' (for single label retrieval) and 'create_label' (for label creation), the agent receives no explicit or implied direction about appropriate contexts, exclusions, or prerequisites for using this list operation.

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 full burden for behavioral disclosure. While 'List messages' implies a read-only operation, it doesn't specify authentication requirements, rate limits, pagination behavior (beyond the pageToken parameter), or what format the returned messages will have. This leaves significant gaps for an agent trying to understand how this tool behaves.

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

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

The description is a single, efficient sentence that communicates the core functionality without unnecessary words. It's appropriately sized for a listing tool and gets straight to the point with no wasted verbiage.

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

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

For a read-only listing tool with comprehensive parameter documentation (100% schema coverage), the description is minimally adequate. However, without annotations or an output schema, it should ideally provide more context about authentication needs, rate limits, or typical use cases to help an agent understand the complete 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?

The description mentions 'optional filtering' which aligns with parameters like q and labelIds, but doesn't add meaningful semantic context beyond what's already in the schema descriptions. With 100% schema description coverage, the baseline is 3, and the description doesn't significantly enhance understanding of parameter purposes or relationships.

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 ('List messages') and resource ('in the user's mailbox'), making the purpose immediately understandable. However, it doesn't differentiate this tool from other listing tools like list_drafts or list_threads, which would require mentioning it specifically lists email messages rather than other mailbox items.

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

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

The description mentions 'optional filtering' but provides no guidance on when to use this tool versus alternatives like list_threads or get_message. There's no mention of prerequisites, typical use cases, or comparison with sibling tools that might serve similar purposes.

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 states the tool lists aliases but doesn't cover aspects like authentication requirements, rate limits, pagination, or error handling. This leaves significant gaps in understanding how the tool behaves in practice.

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

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

The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly.

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

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

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the return values look like (e.g., list format, fields included) or address behavioral aspects like permissions or limitations. For a tool with no structured data support, more detail is needed to be fully 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?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description mentions 'for the specified account', which implies an account context, but since there are no parameters, this doesn't add or detract significantly. A baseline of 4 is appropriate as the schema fully handles parameters.

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

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

The description clearly states the action ('Lists') and resource ('send-as aliases for the specified account'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'get_send_as' or 'list_delegates', which could cause confusion in tool selection.

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 like 'get_send_as' or 'list_delegates', nor does it mention prerequisites such as account specification. The description lacks context for distinguishing it from similar tools in the server.

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 states it 'Lists S/MIME configs,' implying a read-only operation, but doesn't specify if it returns all configs, paginated results, error conditions, or authentication requirements. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

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

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse quickly, which is ideal for conciseness.

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

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

Given the tool has no annotations, no output schema, and a simple parameter set with full schema coverage, the description is minimally adequate. It clarifies the tool's purpose but lacks details on behavior, output format, and usage context, which are needed for full completeness in this environment.

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 100% description coverage, with the single parameter 'sendAsEmail' clearly documented as 'The email address that appears in the 'From:' header.' The description adds no additional parameter details beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage.

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

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

The description clearly states the action ('Lists') and resource ('S/MIME configs') with specific scope ('for the specified send-as alias'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'get_smime_info' or 'insert_smime_info', which would require more specific comparison to achieve a score of 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 provides no guidance on when to use this tool versus alternatives like 'get_smime_info' (which might retrieve a single config) or 'insert_smime_info' (for creating configs). It lacks context on prerequisites, such as whether the send-as alias must exist or have permissions set up, leaving usage unclear.

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 full burden for behavioral disclosure. It states it's a list operation but doesn't mention whether it's read-only, paginated, rate-limited, permission-dependent, or what the return format looks like. For a tool with 6 parameters and no output schema, this leaves significant gaps in understanding its 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, direct sentence with zero wasted words. It's appropriately sized for a basic list operation and front-loads the essential action and scope immediately.

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 (6 parameters, no output schema, no annotations), the description is insufficient. It doesn't explain what a 'thread' entails in this context, how results are structured, whether authentication is needed, or any error conditions. For a list operation with filtering capabilities, more context is needed to use it effectively.

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 adds no parameter information beyond what's already in the schema, which has 100% coverage with clear descriptions for all 6 parameters. The baseline score of 3 reflects that the schema adequately documents parameters, but the description doesn't enhance understanding with examples, constraints, or relationships between parameters.

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

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

The description clearly states the verb ('List') and resource ('threads in the user's mailbox'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_messages' or 'list_drafts', which would require specifying what distinguishes threads from other mailbox items.

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

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

The description provides no guidance on when to use this tool versus alternatives. With siblings like 'list_messages' and 'get_thread', there's no indication of whether this is for browsing, searching, or retrieving specific threads, nor any prerequisites or exclusions mentioned.

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 full burden. It states 'modify' implying a mutation, but doesn't disclose behavioral traits like required permissions, whether changes are reversible, rate limits, or what happens on success/failure. This is inadequate for a mutation tool with zero annotation coverage.

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

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

The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, clearly stating the core functionality without unnecessary elaboration.

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

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

For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, side effects, or response format, leaving significant gaps for an AI agent to understand how to use this tool effectively.

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

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

Schema description coverage is 100%, so the schema already documents all parameters (id, addLabelIds, removeLabelIds). The description adds no additional meaning beyond what's in the schema, such as explaining label ID formats or interaction between add/remove operations. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the action ('modify') and target resource ('labels on a message'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'batch_modify_messages' or 'update_label', which could cause confusion about when to use this specific tool versus alternatives.

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 'batch_modify_messages' or 'update_label', nor does it mention prerequisites or context for usage. The agent must infer usage from the tool name and parameters 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 implies a mutation operation ('modify') but doesn't specify permissions required, whether changes are reversible, error handling, or rate limits. This leaves significant gaps for an agent to understand the tool's behavior beyond basic functionality.

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

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

The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded and wastes no space, making it easy for an agent to parse quickly.

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

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

Given the tool's moderate complexity (mutation with 3 parameters), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, usage context, and output, leaving room for improvement in completeness.

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 100% description coverage, clearly documenting all three parameters (id, addLabelIds, removeLabelIds). The description adds no additional semantic context beyond what's in the schema, such as format examples or constraints, so it meets the baseline for high schema coverage.

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

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

The description clearly states the action ('modify') and resource ('labels applied to a thread'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'update_label' or 'modify_message', which could involve similar label operations, so it doesn't reach the highest score.

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 'update_label' or 'patch_label', nor does it mention prerequisites or exclusions. It merely states what the tool does without contextual usage advice.

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 full burden. It states 'patch' implies mutation but doesn't disclose permissions needed, whether changes are reversible, rate limits, or what happens to unspecified fields. For a mutation tool with zero annotation coverage, this is insufficient.

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

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

The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy 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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, side effects, or response format, leaving significant gaps for an AI agent to understand tool usage.

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

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

Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no additional parameter semantics beyond what's in the schema, such as format examples or constraints. Baseline 3 is appropriate when schema does all the work.

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 ('patch') and resource ('existing label'), with 'partial update' specifying the type of modification. It distinguishes from 'update_label' (likely a full update) by mentioning partial updates, though not explicitly contrasting with sibling 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?

No guidance is provided on when to use this tool versus alternatives like 'update_label' (a sibling tool). The description implies partial updates but doesn't specify prerequisites, error conditions, or when to choose this over other label-related 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 full burden for behavioral disclosure. It states 'patches' which implies a partial update mutation, but doesn't clarify permissions needed, whether changes are reversible, rate limits, or what happens to unspecified fields. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps unaddressed.

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

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

The description is a single, efficient sentence that states the core function without unnecessary words. It's appropriately sized for what it communicates and is front-loaded with the essential information. Every word earns its place in this minimal 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?

For a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'patches' means operationally, what the response looks like, error conditions, or how this differs from 'update_send_as'. Given the complexity of a partial update operation and lack of structured behavioral information, the description should provide more 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 schema already documents all 6 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.

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 action ('patches') and resource ('specified send-as alias'), making the purpose clear. However, it doesn't distinguish this tool from sibling tools like 'update_send_as' or 'create_send_as', leaving ambiguity about when to use patch versus update operations. The description is specific enough to understand the basic function but lacks 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?

The description provides no guidance on when to use this tool versus alternatives like 'update_send_as' or 'create_send_as'. It doesn't mention prerequisites, exclusions, or specific contexts for patching versus other operations. Without any usage context, the agent must infer when this tool is appropriate based on 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?

No annotations are provided, so the description carries full burden. 'Removes' implies a destructive mutation, but it doesn't disclose whether this requires special permissions, if the action is reversible, what happens to associated data, or any rate limits. For a mutation tool with zero annotation coverage, this is inadequate behavioral disclosure.

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

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

The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple tool and front-loads the core action, making it easy 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 destructive mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'delegate' means in this system, what the removal entails, or what the agent should expect as a result. The context signals show minimal complexity, but the description fails to provide necessary 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%, with the single parameter 'delegateEmail' fully documented in the schema. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline score of 3 where the schema does the heavy lifting.

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

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

The description 'Removes the specified delegate' clearly states the action (removes) and the resource (delegate), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'delete_delegate' (which doesn't exist) or explain what a 'delegate' is in this context, preventing a perfect score.

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. With sibling tools like 'list_delegates' and 'get_delegate', there's no indication whether removal should follow verification or what prerequisites exist. The agent must infer usage from the tool 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 states the action ('send') but doesn't explain what happens after sending (e.g., does the draft get deleted or archived?), whether it requires specific permissions, or any side effects like rate limits. This leaves critical behavioral traits unspecified for a mutation 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?

The description is a single, efficient sentence with no wasted words, making it easy to parse. However, it's overly terse and could benefit from slightly more detail to improve clarity without sacrificing brevity, as it currently under-specifies the tool's behavior.

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

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

Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like what 'send' entails, potential errors, or return values, leaving significant gaps for an agent to understand and use the tool effectively.

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 100% description coverage, with the 'id' parameter documented as 'The ID of the draft to send'. The description doesn't add any meaning beyond this, such as where to find the ID or format requirements. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.

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

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

The description 'Send an existing draft' clearly states the verb ('send') and resource ('existing draft'), making the purpose understandable. However, it lacks specificity about what 'send' means operationally (e.g., sending an email) and doesn't distinguish it from sibling tools like 'send_message' or 'create_draft', leaving ambiguity about its exact scope.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a draft created first), exclusions, or comparisons to siblings like 'send_message' or 'create_draft', leaving the agent to infer usage context from the tool 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 mentions 'the mechanics of the raw parameter' which hints at some complexity, but doesn't explain what those mechanics are, whether this is a synchronous or asynchronous operation, what permissions are required, whether it's rate-limited, or what happens on failure. For a mutation tool with significant parameters, this leaves critical behavioral aspects unspecified.

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

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

The description is appropriately concise with two sentences. The first sentence clearly states the purpose, and the second sentence provides important technical context about parameter interaction. There's no wasted verbiage, though it could be slightly more structured by explicitly mentioning the parameter override behavior upfront.

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 (8 parameters, mutation operation, no annotations, no output schema), the description is minimally adequate but incomplete. It covers the core purpose and a critical parameter interaction, but lacks information about behavioral aspects, error handling, return values, and usage context relative to siblings. For a send operation in a rich email API, more context would be helpful.

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

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

The description adds meaningful context about the raw parameter that goes beyond the schema's technical description. While the schema has 100% description coverage for all 8 parameters, the tool description highlights that 'raw' overrides other parameters (to, cc, bcc, subject, body, includeBodyHtml), which is crucial semantic information not evident from the schema alone. This compensates well for the high schema coverage.

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

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

The description clearly states the tool's purpose: 'Send an email message to specified recipients.' This is a specific verb+resource combination that distinguishes it from siblings like create_draft or send_draft. However, it doesn't explicitly differentiate from batch operations or other message-related tools beyond the basic function.

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. With siblings like send_draft, create_draft, batch_modify_messages, and modify_message, there's no indication of when this direct send operation is preferred over creating/sending drafts or using batch operations. The note about the raw parameter is technical, not usage 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. It states 'Sets', implying a mutation, but doesn't clarify permissions required, whether changes are reversible, potential side effects (e.g., impact on email sending), or error conditions. This is a significant gap for a mutation tool with zero annotation coverage.

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

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy for an agent to parse quickly.

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

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

Given that this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavior, error handling, or what the tool returns, which are critical for safe and effective use. The high schema coverage helps with parameters, but overall context is insufficient.

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 both parameters ('sendAsEmail' and 'id') adequately. The description doesn't add any meaning beyond this, such as explaining the relationship between the parameters or providing usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the action ('Sets') and the target resource ('default S/MIME config for the specified send-as alias'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'update_send_as' or 'insert_smime_info', which might handle related configurations, so it misses the highest score.

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. For example, it doesn't mention prerequisites (e.g., needing an existing S/MIME config via 'insert_smime_info'), exclusions, or comparisons to siblings like 'update_send_as' that might modify send-as settings. This leaves the agent without context for tool selection.

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

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

No annotations are provided, so the description carries full burden. It mentions the action ('Stop receiving push notifications') which implies a state change operation, but doesn't disclose important behavioral traits like whether this requires specific permissions, whether it's reversible, what happens if no watch exists, or any rate limits. The description is minimal and lacks operational 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 a single, clear sentence that efficiently conveys the tool's purpose without any wasted words. It's appropriately sized for a simple tool with no parameters and gets straight to the point.

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

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

For a tool with no parameters, no output schema, and no annotations, the description provides the basic purpose but lacks important context about how the tool behaves operationally. It doesn't explain what 'the given user mailbox' means contextually or what happens after stopping notifications. The description is minimally viable but has clear gaps in operational transparency.

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

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

With 0 parameters and 100% schema description coverage, the baseline is 4. The description appropriately doesn't discuss parameters since none exist, which is correct for this tool configuration.

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 ('Stop receiving push notifications') and the target resource ('for the given user mailbox'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from its sibling 'watch_mailbox' (which presumably starts notifications), though the relationship is implied through naming conventions.

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

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

The description implies usage context (when you want to stop push notifications for a mailbox) but doesn't provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites like needing an active watch to stop. The relationship with 'watch_mailbox' is apparent but not explicitly 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 full burden but only states the basic action. It doesn't disclose whether this requires specific permissions, if the message is recoverable, what happens to associated data, or any rate limits/errors. For a mutation tool, this is insufficient.

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 zero wasted words. It's front-loaded and efficiently conveys the core action without unnecessary elaboration.

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

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

For a mutation tool with no annotations and no output schema, the description is too minimal. It doesn't explain what 'trash' means operationally (e.g., reversible, affects threads), expected outcomes, or error conditions, leaving significant gaps.

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

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

Schema description coverage is 100%, so the schema fully documents the single 'id' parameter. The description doesn't add any meaning beyond what's in the schema (e.g., format of ID, where to find it), meeting the baseline for high coverage.

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

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

The description clearly states the action ('Move') and resource ('a message to the trash'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'delete_message' or 'trash_thread', which would require 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?

No guidance is provided on when to use this tool versus alternatives like 'delete_message' (permanent deletion) or 'untrash_message' (reversal). The description only states what it does, not when it's 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Move to the trash') but doesn't explain what this means operationally—whether it's reversible, if it requires specific permissions, how it differs from deletion, or what happens to associated messages. This leaves significant gaps 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, efficient sentence that states the core functionality without unnecessary words. It's front-loaded and wastes no space, making it easy 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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like reversibility, permissions, or differences from similar tools, which are critical for safe and effective use in context with siblings like 'untrash_thread' and 'delete_thread'.

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 description coverage is 100%, with the single parameter 'id' clearly documented in the schema as 'The ID of the thread to move to trash'. The description doesn't add any additional parameter context beyond what the schema provides, so it meets the baseline for high schema coverage.

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

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

The description clearly states the action ('Move') and target resource ('a thread to the trash'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'trash_message' or 'delete_thread', but the specificity of 'thread' versus 'message' provides some implicit 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 like 'trash_message', 'delete_thread', or 'untrash_thread'. It lacks context about prerequisites, consequences, or typical scenarios for moving threads to trash.

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 states the action ('remove from trash') which implies a write/mutation operation, but doesn't specify whether this restores the message to its original location (e.g., inbox), what permissions are required, whether it's reversible, or what happens if the message isn't in the trash. For a mutation tool with zero annotation coverage, this leaves significant behavioral 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?

The description is a single, efficient sentence that states exactly what the tool does with zero wasted words. It's appropriately sized for a simple tool with one parameter and gets straight to the point without unnecessary elaboration.

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

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

For a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what happens after the operation (where the message goes, what the response contains), doesn't mention error conditions or permissions, and provides minimal behavioral context. Given the complexity of a state-changing operation in a messaging system, more contextual information would be helpful.

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

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

Schema description coverage is 100%, with the single parameter 'id' clearly documented in the schema as 'The ID of the message to remove from trash'. The description doesn't add any additional parameter information beyond what the schema provides, which is acceptable given the high schema coverage. The baseline score of 3 reflects adequate but minimal parameter documentation.

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

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

The description clearly states the verb ('remove') and resource ('a message from the trash'), making the purpose unambiguous. It distinguishes from sibling tools like 'delete_message' or 'trash_message' by specifying the trash context. However, it doesn't explicitly differentiate from 'untrash_thread', which performs a similar operation on threads instead of messages.

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 'delete_message' (permanent deletion) or 'trash_message' (moving to trash). It doesn't mention prerequisites such as needing a message to already be in the trash or any error conditions. The only implied usage is when you want to restore a trashed message.

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 full burden. It states the action ('Remove from trash') but doesn't disclose behavioral traits like whether this requires specific permissions, what happens if the thread isn't in trash, if the operation is reversible, or what the response looks like. For a mutation tool with zero annotation coverage, 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?

The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it immediately understandable without unnecessary elaboration.

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

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

Given the tool's mutation nature (restoring from trash), no annotations, no output schema, and incomplete behavioral disclosure, the description is inadequate. It should explain more about the operation's effects, error conditions, or return values to help an agent use it correctly.

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

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

Schema description coverage is 100% (the 'id' parameter is fully documented in the schema), so the baseline is 3. The description doesn't add parameter-specific details beyond what the schema provides, but with only one parameter, the lack of additional semantics is less critical. It implies the 'id' refers to a thread, which aligns with the schema.

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

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

The description clearly states the specific action ('Remove') and target resource ('a thread from the trash'), distinguishing it from sibling tools like 'untrash_message' (which operates on messages) and 'trash_thread' (which moves threads to trash). It uses precise terminology that matches the tool name without being tautological.

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

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

The description implies usage context (when a thread is in the trash and needs restoration) but doesn't explicitly state when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., thread must be in trash) or exclusions (e.g., cannot be used on permanently deleted threads), leaving some ambiguity.

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 full burden for behavioral disclosure. While 'Updates' implies a mutation operation, it doesn't disclose permission requirements, whether changes are reversible, rate limits, or what happens when forwarding is disabled. It provides minimal behavioral context beyond the 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, efficient sentence with zero wasted words. It's appropriately sized for a tool with good schema coverage and gets straight to the point without unnecessary elaboration.

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

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

For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after the update, whether there's confirmation, error conditions, or how to verify changes. Given the complexity of modifying forwarding settings, more context about the operation's impact is 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?

Schema description coverage is 100%, so the schema already fully documents all three parameters. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters or provide usage examples. The baseline 3 is appropriate when schema does all the work.

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 ('Updates') and resource ('automatic forwarding settings'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from its sibling 'get_auto_forwarding' beyond the obvious update vs. get difference, nor does it explain what aspects of forwarding settings are updated.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing 'get_auto_forwarding' first), when not to use it, or how it relates to similar tools like 'create_forwarding_address' or 'update_vacation' settings.

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 must fully disclose behavioral traits. 'Updates IMAP settings' implies a mutation operation, but it doesn't specify whether this requires authentication, affects email delivery, has side effects (e.g., disrupting existing connections), or provides confirmation. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

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

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

The description is a single, efficient sentence with zero waste—'Updates IMAP settings' is front-loaded and directly states the action. It's appropriately sized for a tool with a clear name and well-documented schema, though it could benefit from more detail to improve other dimensions.

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 (a mutation operation with no annotations and no output schema), the description is incomplete. It doesn't explain what 'IMAP settings' entail, the impact of updates, or what the tool returns. With no annotations to cover safety or behavior, and no output schema, the description should provide more context to guide the agent effectively.

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 100% description coverage, with clear documentation for all three parameters (enabled, expungeBehavior, maxFolderSize). The description adds no additional meaning beyond the schema, such as explaining relationships between parameters or usage examples. With high schema coverage, the baseline score of 3 is appropriate, as the schema handles the heavy lifting.

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

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

The description 'Updates IMAP settings' clearly states the verb ('Updates') and resource ('IMAP settings'), making the purpose understandable. However, it's vague about what specific settings are updated and doesn't differentiate from sibling tools like 'update_pop' or 'update_auto_forwarding' that also update settings. It's not tautological but lacks specificity.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing admin access), when it's appropriate (e.g., configuring email clients), or exclusions (e.g., not for POP settings). With many sibling tools for updating various settings, this omission leaves the agent without context for selection.

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

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

No annotations are provided, so the description carries full burden. 'Update an existing label' implies a mutation operation but doesn't disclose behavioral traits like required permissions, whether changes are reversible, rate limits, or error conditions. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

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

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

The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, though it could benefit from additional context—this score reflects conciseness, not completeness.

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

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

For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects, usage context, or return values, leaving gaps that could hinder an agent's ability to invoke it correctly. The high schema coverage doesn't compensate for missing 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 schema fully documents all 5 parameters. The description adds no meaning beyond what the schema provides—it doesn't explain parameter interactions, defaults, or examples. Baseline 3 is appropriate when the schema does all the work.

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 label' clearly states the verb ('update') and resource ('label'), but it's vague about what aspects can be updated and doesn't distinguish it from the sibling 'patch_label' tool. It provides basic purpose but lacks specificity about scope or differentiation from alternatives.

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 'patch_label' or 'create_label'. There's no mention of prerequisites, use cases, or exclusions, leaving the agent with no contextual decision-making help.

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. 'Updates language settings' implies a mutation operation, but it doesn't specify required permissions, whether changes are reversible, rate limits, or what the response looks like (e.g., success/failure indicators). For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

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

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

The description is extremely concise with 'Updates language settings', a single sentence that front-loads the core action and resource. There is no wasted verbiage or redundancy, making it efficient and easy to parse quickly.

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

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

Given this is a mutation tool with no annotations, no output schema, and a simple parameter, the description is incomplete. It lacks behavioral context (e.g., effects, permissions), usage guidelines, and any mention of return values or error handling. While the parameter is well-documented in the schema, the overall context for safe and effective use is insufficient.

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 100% description coverage, with 'displayLanguage' documented as 'The language to display Gmail in, formatted as an RFC 3066 Language Tag'. The description adds no additional parameter details beyond what the schema provides, such as examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't need to heavily.

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 'Updates language settings' clearly states the action (update) and resource (language settings), making the purpose understandable. However, it's somewhat vague about what specifically gets updated (e.g., Gmail display language vs. system-wide settings) and doesn't differentiate from potential siblings like 'get_language' beyond the verb difference. It avoids tautology but lacks specificity.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing 'get_language' first), exclusions, or compare it to similar tools like 'update_label' or 'update_vacation' in the sibling list. Usage is implied by the verb 'updates' but lacks explicit 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?

No annotations are provided, so the description carries full burden. It states 'Updates' implying a mutation, but doesn't disclose behavioral traits like required permissions, whether changes are immediate or reversible, error conditions, or effects on existing email access. This leaves significant gaps 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 extremely concise with just three words, which is efficient and front-loaded. However, it's arguably too brief for a mutation tool with no annotations, lacking necessary context that could justify more 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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what POP settings are, the impact of updates, or return values. Given the complexity of email protocol configuration, more context is needed for effective agent use.

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 clear enum values and descriptions for both parameters. The description adds no additional meaning beyond the schema, which already documents accessWindow and disposition thoroughly. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description states the action ('Updates') and target ('POP settings'), which is clear but vague. It doesn't specify what POP settings are or distinguish this tool from similar tools like update_imap or update_auto_forwarding, making it less specific than ideal.

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. There's no mention of prerequisites, related tools like get_pop for checking current settings, or context for updating POP settings versus other email protocol settings.

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 full burden for behavioral disclosure. 'Updates' implies a mutation operation, but it doesn't specify required permissions, whether changes are reversible, error conditions, or side effects. This is inadequate for a mutation tool with zero annotation coverage.

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

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

The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately understandable without unnecessary elaboration.

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

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

For a mutation tool with 6 parameters, no annotations, and no output schema, the description is insufficient. It doesn't address behavioral aspects like permissions, side effects, or error handling, nor does it provide usage context. The high schema coverage helps but doesn't compensate for these gaps.

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

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

Schema description coverage is 100%, so the schema fully documents all 6 parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain relationships between parameters or provide examples). This meets the baseline for high schema coverage.

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

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

The description clearly states the action ('Updates') and resource ('a send-as alias'), making the purpose immediately understandable. It distinguishes from sibling tools like 'create_send_as' and 'delete_send_as' by specifying an update operation rather than creation or deletion. However, it doesn't specify what aspects are updated, which prevents a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing send-as alias), differentiate from similar tools like 'patch_send_as', or explain use cases. This leaves the agent without contextual usage information.

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