reply_email

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

With no annotations, the description carries the burden of behavioral disclosure. It explains that recipients are inferred, that extra cc/bcc can be added, and that the body can be text or HTML. It does not mention that this sends a real email or describe side effects, but the core reply behavior is adequately conveyed.

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

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

Two concise sentences, front-loaded with the primary action and the most important inference behavior. Every sentence earns its place and no schema details are unnecessarily repeated.

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 10-parameter action with no output schema and no annotations, the description covers the essential invocation semantics: target an inbound message, rely on inferred recipients, and provide a body. It omits details like default subject or return behavior, but the schema covers the parameters and the core usage is clear enough.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by clarifying that recipients come from the original message and that the text or html body must be provided. This goes beyond the schema's bare field names and helps an agent choose between the body 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 names a specific verb and resource: 'Reply to an inbound message.' It also adds the key differentiator that recipients are inferred from the original message, which clearly separates it from send_email. This lets an agent identify the tool's role without opening the schema.

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

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

The description clearly scopes this tool to replying to an inbound message, which tells an agent when to use it. It does not explicitly mention send_email as the alternative for new outbound messages, but the context is clear enough that no exclusions are needed.

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