Skip to main content
Glama

Read a message

read_message

Retrieve the full body of an email by ID, including any verification code and attachment metadata. Optionally save attachments and HTML to disk.

Instructions

Read the full body of a message by id, including any verification code detected in it. Lists attachment metadata; pass save_dir to also save the attachments and the HTML body to disk (where the provider supports downloads).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesMessage id (from list_messages)
addressNoInbox address; defaults to the most recent inbox
save_dirNoDirectory to save attachments and body.html/body.txt into, written to <save_dir>/<message-id>/ (e.g. "/tmp")

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses the read-only nature, the detection of verification codes, the listing of attachment metadata, and the conditional saving behavior with the caveat 'where the provider supports downloads'. This gives the agent a solid behavioral model of the tool's side effects.

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

Conciseness5/5

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

Two sentences with no fluff: the main purpose is front-loaded, and the optional save behavior is stated concisely with the provider-support caveat. Every sentence adds value.

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

Completeness4/5

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

For a simple read tool with three parameters and no output schema, the description covers what is returned (body, verification code, attachment metadata) and the optional disk-saving behavior. It does not explain error cases or how it relates to wait_for_code, but these are minor gaps given the tool's simplicity.

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

Parameters3/5

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

Schema coverage is 100%, so the schema fully documents all three parameters. The description adds some context for save_dir (specifying it also saves the HTML body) and implies id comes from list_messages, but these are incremental beyond the schema. The baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb and resource: 'Read the full body of a message by id'. It also adds distinctive details (verification code detection, attachment metadata) that differentiate it from siblings like list_messages and wait_for_code.

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

Usage Guidelines3/5

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

The description implies when to use the tool (to read the full body of a message) and mentions an optional save behavior, but it does not explicitly contrast it with siblings like wait_for_code or list_messages. No when-not-to-use guidance is provided.

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

Deploy Server

Other Tools