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

With no annotations, the description carries the full burden, and it does substantial work: it discloses that the tool stages rather than sends, that attachments are interpreted as local file paths, that the draft resource is returned, and that sending is deliberately excluded as a workflow constraint. It does not cover auth/permission needs or rate limits, but the critical behavioral boundary (no sending) is clearly stated.

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?

Roughly 50 words across three sentences, with the core action front-loaded in the first sentence, attachments semantics in the second, and the send-limitation workflow in the third. Every sentence adds distinct information; there is no fluff or repetition.

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

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

Given no annotations, 0% schema parameter coverage, and an output schema that already covers the return value, the description covers the essential invocation knowledge: the operation's scope, the non-send constraint, and the local-path semantics of attachments. Minor gaps remain around address/message-id formats and prerequisites, but nothing blocks correct invocation for a straightforward draft creation.

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

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

Schema description coverage is 0%, so the description must compensate. It does clarify the one genuinely ambiguous parameter — 'attachments are local file paths' — and frames the rest as email-draft fields (to, subject, body, cc, in_reply_to) which are largely self-evident. However, it leaves in_reply_to's expected format (e.g., message-id) and cc/address format unspecified, so compensation is partial.

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

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

The description uses a specific verb+resource pair ('Stage a draft') and immediately disambiguates from sending with 'Does NOT send.' None of the sibling tools create or stage drafts, so an agent can distinguish this tool without opening the schema. The intentional non-send scoping makes the purpose unmistakable.

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

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

The description gives clear context that this tool is for staging drafts and explicitly excludes sending ('Sending is intentionally unavailable here'), routing the agent to the CLI for the send step. It lacks an explicit statement of when to use this tool over a sibling, but no sibling is a draft/send tool, so the exclusion plus named alternative (CLI) covers the key decision.

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, the description carries the behavioral burden. It discloses a hard platform restriction (forward actions rejected), a pre-submission validation step, and calls out the fact that the operation creates a filter. It doesn't discuss permissions or side effects beyond creation, but the core mutation and limitation are visible.

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

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

The description is only three sentences, front-loads the core verb/object, and uses code formatting for the spec shape. Every sentence adds either invocation or exclusion information, with no filler.

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

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

For a one-parameter nested-object tool with no annotations, the description covers the essential invocation details, the critical restriction, and the alternative path; the output schema covers return values. It could add more detail about permissible criteria/action keys, but the given example and structure are sufficient for a first call.

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 only says 'spec' is an object with additionalProperties, so the description adds essential meaning: spec is {criteria: {...}, action: {...}}, uses snake_case keys, and cites add_label_ids as an example. This turns an opaque generic object into an actionable structure.

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?

Description opens with the specific verb 'Create' and resource 'Gmail filter', immediately distinguishing it from sibling get/delete/list tools. The phrase 'from a declarative spec object' further defines the operation's input style.

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

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

It explicitly states when the tool is not appropriate: forward actions are rejected over MCP, and it names the alternative ('create forwarding filters with the CLI instead'). It also notes validation occurs before submission, clarifying the expected failure behavior.

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

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

With no annotations provided, the description carries the full burden. It discloses the destructive action ('Delete') and the return value ({deleted: <id>}). However, it does not mention that deletion is permanent and irreversible, nor any authentication or permission requirements. These are meaningful behavioral attributes that a well-rounded description should include.

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 concise sentence that front-loads the core action ('Delete a Gmail filter by id') and immediately follows with the return shape. There is zero wasted wording, making it highly efficient.

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

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

For a one-parameter destructive tool with an output schema hint, the description covers the essential behavior and return format. It is missing edge-case handling (e.g., non-existent id) and permanence warning, but these are not critical for a simple delete. The description is complete enough for an agent to invoke the tool correctly.

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

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

Schema coverage is 0%, so the description must compensate. It mentions 'by id' which indicates that filter_id is the identifier of the filter, adding minimal value over the bare schema. It does not explain the id format, where to obtain it, or any validation. This is adequate but not rich.

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

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

The description states a specific verb ('Delete'), a clear resource ('Gmail filter'), and the identifier ('by id'). This clearly distinguishes it from sibling tools like get_filter, list_filters, and create_filter, which handle retrieval and creation. The action and scope are unambiguous.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention that it requires an existing filter id obtained from list_filters or get_filter, nor does it suggest any exclusions. The user must infer usage solely from the tool name and description.

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 behavioral burden and does so well: it states the side effect (writes bytes to out), the return shape ({path, bytes_written}), and the explicit non-behavior (bytes are never returned inline). It stops short of disclosing overwrite behavior or access requirements, but the core action is transparent.

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

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

The description is compact and front-loaded, opening with the main purpose and adding two tightly scoped behavioral notes. Every sentence earns its place and there is no redundant wording.

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

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

For a simple 3-parameter tool with an output schema, the description covers the primary action, destination, return shape, and inline-return behavior. It is less complete on sourcing the required IDs and on usage context, yet the sibling set and tool name make the overall role reasonably clear.

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 only 33% (only `out` is documented), and the description does not compensate by defining `message_id` or `attachment_id` or explaining where they come from. It does clarify that `out` is the write destination, but two required parameters remain semantically implicit.

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

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

The description uses a specific verb ('Download') with a definite resource ('message attachment') and destination ('local file path'). It cleanly distinguishes this tool from sibling tools, which all concern filters, drafts, or raw messages rather than attachments.

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

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

The intended use is implied by the action itself: call this when you need attachment bytes written to a local file. However, there is no explicit guidance about when not to use it, how to source message_id/attachment_id, or how it relates to siblings like get_raw_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 must carry the behavioral burden. The verb 'Get' communicates a read-only retrieval operation, but the description does not address missing IDs, auth requirements, or error 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 compact sentence with no filler. The action, resource, and id selector are all immediately present and front-loaded.

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

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

For a one-parameter retrieval tool with an output schema, the description is sufficient for a basic call. The main gaps are explicit routing to list_filters and error-case behavior, but these are minor given the tool's simplicity.

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

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

With 0% schema description coverage, the phrase 'by id' adds the semantic role of filter_id as the resource selector. It compensates enough for the single obvious parameter, though no formatting or additional constraints are described.

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

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

The description uses a specific verb ('Get'), names the exact resource ('Gmail filter resource'), and scopes it to a single item by id. This clearly distinguishes it from siblings like list_filters, create_filter, and delete_filter.

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

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

The description implies the tool is for retrieving one known filter by ID, so an agent can infer the core use case. However, it does not explicitly state when to use list_filters instead or give exclusion criteria.

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, the description carries the full burden. It discloses the main side effect: raw bytes are written to 'out' and a {path, bytes_written} result is returned. However, it does not disclose overwrite behavior, error cases, or system-level effects like file replacement or permission requirements.

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

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

The description is short and front-loaded, with the main purpose in the first sentence and the return contract in the second. Both sentences carry useful information, though the first sentence has a minor grammatical issue that slightly undermines polish.

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

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

The description covers the primary file-writing behavior and return shape, and an output schema is noted as present. It remains incomplete as a standalone guide: message_id semantics and failure/overwrite behavior are absent, so an agent may still face edge-case ambiguity when invoking the tool.

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

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

Schema description coverage is only 50% and the description adds little for the undocumented message_id parameter. It mentions that bytes are written to 'out', but that parameter already has a schema description. message_id is never described in terms of format or source, leaving a gap that the description fails to fill.

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

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

The description states a clear action and resource: fetch a message's full raw RFC822 MIME and write it to a local file path. It distinguishes from download_attachment by emphasizing the raw message rather than attachments, but it does not explicitly name the sibling or differentiate itself. The phrasing is also slightly awkward ('Fetch... to a local file path'), which slightly weakens clarity.

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

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

There is no explicit guidance on when to use this tool versus download_attachment or other siblings. The phrase 'full raw RFC822 MIME' implies the intended use case, but no conditional direction or exclusions are provided. An agent must infer the distinction on its own.

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, the description carries the behavioral disclosure burden. It communicates a read-only listing behavior and specifies JSON resources as the output, but it does not mention authentication, pagination, rate limits, or collection-size behavior. Adequate for a simple list, but not rich.

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

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

A single, front-loaded sentence with no filler. 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?

For a zero-parameter, read-only list tool with an output schema present, this description is sufficient for correct invocation. The only enhancement would be explicit sibling routing, but that is a usage-guideline concern rather than a completeness gap.

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

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

The input schema has zero parameters)Skip and 100% schema coverage, so the schema fully handles any input concerns. Baseline for zero-parameter tools is 4, and the description adds nothing 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?

States a specific verb (List), resource (Gmail filters), and scope (all). This clearly distinguishes it from get_filter (a single filter) and create_filter/delete_filter (mutations).

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

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

The phrase 'List all' implies enumeration use, and the sibling tool names suggest alternatives, but the description does not explicitly tell the agent when to choose this over get_filter or when to use create/delete_filter. Usage context is present but only implied.

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