get_email

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

Annotations already declare the tool read-only and idempotent, and 'Read' is consistent with that. The description adds a useful prerequisite ('one complete returned identity') and narrows the output to safe headers/plain text, but it does not explain authentication, rate limits, or error behavior; the additional context is modest but not contradictory.

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

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

The description is a single front-loaded sentence with no filler; the read action and resource are stated first. The term 'complete returned identity' is slightly jargon-y and could be clearer, but the overall structure is 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?

An output schema exists, so return value details are not needed here, and annotations cover the safety profile. Still, the description does not indicate which sibling/prior call produces the complete identity or how max_text_chars behaves, leaving a clear but incomplete workflow picture.

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 zero schema descriptions, the phrase 'one complete returned identity' adds meaning by explaining that account_id, mailbox, uid_validity, and uid must form a single composite key returned together. It does not describe max_text_chars or the format of individual fields, so compensation for the 0% schema coverage is only 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 names a clear verb and resource ('Read safe headers/plain text') and limits the scope to a single returned identity, which helps distinguish it from plural/search and HTML-oriented siblings. It does not explicitly name a sibling, but the plain-text scoping is specific enough for an agent to infer the intended 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?

There is an implied usage instruction: use this after obtaining a complete returned identity, rather than using arbitrary IDs. No alternatives or exclusions are mentioned, so the agent must infer when to prefer this over get_emails or get_email_html.

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