get_email

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

With no annotations, the description carries the full burden of behavioral disclosure. It does so by stating exactly what the tool returns (headers, plain/HTML body, attachment metadata) and what it does not return (attachment content), with an explicit pointer to get_attachment. It stops short of discussing read-only side effects, error behavior, or permissions, but for a fetch operation the core behavior is well disclosed.

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 front-loads the action and target, then packs the return scope into a concise colon-separated list. Every clause earns its place, and there is no redundant or filler 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?

Given the absence of an output schema, the description sufficiently covers return values by naming headers, body variants, and attachment metadata, and prevents a wrong expectation by saying attachment content is not included. It does not explain how to obtain the folder or UID, nor what happens on missing emails, but for a simple two-parameter fetch the definition is nearly 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 input schema has 0% description coverage, so the description must add meaning beyond the raw fields. It does identify folder and uid as the identifying key ('by folder and UID'), which clarifies their roles. However, it provides no guidance on folder naming, how to obtain valid folder values, or UID format beyond the schema's integer constraint, leaving meaningful 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 is specific and action-oriented: 'Fetch full content of one email by folder and UID' names a concrete verb, a distinct resource, and the exact lookup method. It further clarifies scope by enumerating what is included ('headers, plain/HTML body, and attachment metadata') and distinguishes itself from get_attachment by noting attachment content is fetched separately.

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 conveys when this tool is appropriate: when you need the full content of exactly one email identified by folder and UID. It explicitly routes attachment content to get_attachment, giving a concrete alternative. It does not mention using list_folders or search_emails to obtain the folder/UID first, but the conditions for use are otherwise clear.

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