Skip to main content
Glama
codefuturist

Email MCP Server

by codefuturist
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get email

get_email
Read-only

Fetch the full content of a specific email by ID without marking it as read. Choose readable text, stripped replies/signatures, or raw body for parsing or review.

Instructions

Get the full content of a specific email by ID. Does NOT mark the email as seen (uses IMAP BODY.PEEK — non-destructive). format: text (default) = HTML converted to readable text with markdown; stripped = text minus quoted replies and signatures; full = raw body part (HTML mail returns raw HTML). Body is capped at 10000 chars by default — pass maxLength (0 = unlimited) to change. Set markRead=true only when you want to explicitly mark the email as read. A Bulk: line appears for list or machine-generated mail (📰 newsletter / 🤖 automated), derived from RFC headers, with the unsubscribe URI when the sender offers one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formatNoBody format: text=readable text with markdown links (default), stripped=text without quoted replies or signatures, full=raw body parttext
accountYesAccount name from list_accounts
emailIdYesEmail ID from list_emails or search_emails
mailboxNoMailbox path (default: INBOX)INBOX
markReadNoExplicitly mark the email as read after fetching (default: false — reading is non-destructive by default)
maxLengthNoTruncate body at this many characters (default 10000; 0 = unlimited). A hint shows how many characters remain.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.6.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedInput schema / properties / format / default
      Previous value: -"full"New value: +"text"
    • changedInput schema / properties / format / description
      Previous value: -"Body format: full=raw (default), text=plain text (strips HTML), stripped=plain text without quoted replies or signatures"New value: +"Body format: text=readable text with markdown links (default), stripped=text without quoted replies or signatures, full=raw body part"
    • addedInput schema / properties / maxLength / default
      Added value: +10000
    • changedInput schema / properties / maxLength / description
      Previous value: -"Truncate body at this many characters. A hint shows how many characters remain."New value: +"Truncate body at this many characters (default 10000; 0 = unlimited). A hint shows how many characters remain."
    • changedInput schema / properties / maxLength / minimum
      Previous value: -100New value: +0
  2. First observedv0.2.3

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the readOnlyHint/destructiveHint annotations: it discloses the IMAP BODY.PEEK mechanism, that the email is NOT marked seen, the 10000-char cap with the maxLength=0 escape, and the derived 'Bulk:' line with unsubscribe URI. These are exactly the side-effects and output quirks an agent needs.

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 purpose and the non-destructive guarantee, then parameter guidance, then the Bulk note. Dense but each sentence carries information; only the final Bulk/marketing line is somewhat peripheral.

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

Completeness5/5

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

With no output schema, the description carries the return-shape burden and does so: it explains body formats, truncation behaviour and the remaining-characters hint, and the Bulk header derivation. An agent can call this correctly and interpret the result without further docs.

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

Parameters4/5

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

Schema description coverage is 100%, so the 3 baseline applies, but the description adds real meaning: what 'stripped' actually removes (quoted replies and signatures), what 'text' converts to (HTML with markdown links), and that maxLength=0 means unlimited. It enriches semantics beyond the enum labels.

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?

States a specific verb and resource ('Get the full content of a specific email by ID'), which cleanly separates it from list_emails/get_emails (plural, summary) and get_thread (whole conversation). The scope word 'full' signals single-message retrieval.

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?

It clarifies when to set markRead=true and how format choices map to intent, which is genuine usage guidance. But it never names an alternative sibling (e.g. get_thread for a conversation, get_emails for summaries), so the agent must infer when this tool is the right pick versus its neighbours.

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