Reply to an email

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

With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It mentions preserving threading headers, which is useful, but it does not state that the tool sends the reply, any required permissions, whether it creates a draft or sends immediately, or potential side effects on the original message. This is a mutation tool lacking critical behavioral context.

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

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

The description is a single, well-structured sentence that is front-loaded with the action and resource. It is concise with no wasted words, effectively covering the core purpose and a key behavioral detail.

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

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

The tool is relatively simple with five parameters and no output schema. The description covers the main purpose and an important behavioral nuance (threading headers). It lacks some details about side effects, but given the simplicity and schema richness, it is reasonably complete for an agent to select and 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 description coverage is 100%, so the schema already documents all five parameters. The description does not add parameter-specific details beyond what the schema provides, but the mention of threading headers gives context for why threadId and messageId are needed. This meets the baseline for schema-covered 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 tool's function: 'Reply to an existing message inside its thread, preserving threading headers.' This identifies the specific verb (reply) and resource (existing message in thread), and distinguishes it from the sibling google_gmail_send tool by emphasizing 'existing message' and 'preserving threading headers.'

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 intended use case (replying within an existing thread) and contrasts with sending a new message, but it does not explicitly state when not to use this tool or name alternatives. It is clear enough for an agent to infer the context, though a direct reference to google_gmail_send for new emails would strengthen guidance.

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