Fetch a full email by its UID, including headers, plain-text or HTML body, and attachment list. Specify folder and UID to read messages directly.
Lê um e-mail completo pelo UID: cabeçalhos, corpo (texto por padrão, ou HTML) e lista de anexos. Use download_attachment para salvar anexos. max_chars=0 usa o limite padrão (MAX_BODY_CHARS).
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | ||
| folder | Yes | ||
| max_chars | No | ||
| prefer_html | No | ||
| mark_as_read | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose default body format and max_chars behavior, but it omits the significant side effect that mark_as_read defaults to true, meaning a 'read' operation mutates email state. This hidden mutating behavior is central and undocumented.
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 two tight, front-loaded sentences with no filler. The main purpose is stated first, then a routing pointer, then a parameter-default clarification. Every sentence 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?
The description covers the core inputs (UID), the main output components (headers, body, attachment list), and the most nuanced default (max_chars). With no output schema and no annotations, it is reasonably complete for a read tool, but the missing mark_as_read side effect and unstated folder semantics leave a meaningful 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?
Schema description coverage is 0%, so the description must add parameter meaning. It explains max_chars=0 behavior and the text-vs-HTML body selection tied to prefer_html. However, it does not clarify the semantics of folder or mark_as_read, leaving two important parameters underdocumented.
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 reads a complete email by UID and enumerates the returned content: headers, body (text or HTML), and attachment list. It names download_attachment as the related tool for saving attachments, but it does not explicitly distinguish itself from the sibling get_raw_email, so it stops short of a 5.
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 a clear usage context: use this tool to read a full email by UID, and use download_attachment when the goal is to save attachments. There is no explicit exclusion of alternatives like get_raw_email or search_emails, so it is not fully exhaustive, but the guidance present is concrete and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.