Skip to main content
Glama
Sign In
gmail-mcp

gmail-mcp

by DimitrisPasakaleris
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

read_email

Fetch a full Gmail message by its message ID to retrieve subject, sender, recipients, date, plain-text or HTML body, and labels for reading or processing.

Instructions

Fetch the full content of an email by its Gmail message ID.

Returns subject, from, to, date, body (plain text), html_body, and labels.

Required:
  message_id (str) — the Gmail message ID from list_emails or
    get_thread_messages. NOT an email Message-ID header.

Returns on success:
  {"id": "...", "subject": "...", "from": "...", "to": "...",
   "date": "...", "body": "plain text...", "html_body": "HTML...",
   "labels": ["INBOX", "IMPORTANT"]}

Workflow note: body may be None if the email is HTML-only.
  html_body will be present for HTML emails. Labels include system
  labels like INBOX, SENT, TRASH, UNREAD and custom labels.
  Use list_attachments(message_id) to find downloadable files.

Input Schema

NameRequiredDescriptionDefault
message_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4/5.0
Behavior4/5

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

No annotations are supplied, so the description carries the full burden, and it does meaningful work: it discloses the exact return shape, warns that body may be None for HTML-only mail, and explains what labels contain (system and custom). It omits permission/auth requirements and any statement of read-only behavior beyond the verb 'Fetch'.

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

Conciseness4/5

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

Front-loaded with the one-sentence purpose, then structured sections for required params and returns. Slightly redundant in that the prose sentence 'Returns subject, from, to, date, body...' is repeated verbatim in the JSON return block, but the block itself earns its place given there is no output schema.

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?

With no output schema and no annotations, the description correctly supplies the return shape, the HTML-only edge case, and the follow-up attachment step, so an agent can call it and interpret the result. The only missing piece is differentiation from the read_emails / read_emails_full siblings.

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

Parameters5/5

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

Schema description coverage is 0% and the schema only says 'Message Id', so the description must compensate — and it does, explaining where the ID comes from and explicitly warning that it is NOT an email Message-ID header. That disambiguation is exactly the kind of meaning the schema cannot provide.

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

Purpose4/5

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

States a specific verb and resource ('Fetch the full content of an email') plus the keying mechanism (Gmail message ID). It also names list_emails and get_thread_messages as the source of the ID. It does not distinguish itself from the plural sibling tools read_emails and read_emails_full, which an agent could easily confuse with this one.

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?

Usage is implied through the workflow note: obtain message_id from list_emails or get_thread_messages, then call list_attachments afterwards for files. There is no explicit statement of when to use this versus read_emails / read_emails_full, nor any exclusion guidance, so the agent must infer the boundary.

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