MCP Email Server

Overview Schema Source Related Servers Discussions Admin

get_emails_content

Idempotent

Retrieve complete email content, including body and reply-thread headers, for one or more emails by their IDs to enable full message inspection.

Instructions

Get the full content (including body and reply-thread headers) of one or more emails by their email_id. Use list_emails_metadata first. This tool is non-read-only because mark_as_read=true changes remote flags.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`mailbox`	No	The mailbox to retrieve emails from.	INBOX
`email_ids`	Yes	One or more email_id values to retrieve, supplied as an array (obtained from list_emails_metadata).
`body_offset`	No	Character offset into each email body to start reading from. Use together with max_body_length to page through long emails: if a returned body ends with the '...[TRUNCATED]' marker, fetch the next chunk with body_offset += max_body_length.
`account_name`	Yes	The name of the email account.
`mark_as_read`	No	If True, mark each successfully retrieved email as read. If marking fails, a warning is logged and retrieval still succeeds.
`max_body_length`	No	Maximum number of body characters to return, counted from body_offset. If the body extends past this window, the '...[TRUNCATED]' marker is appended after the requested body window.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`emails`	Yes
`failed_ids`	Yes
`output_bytes`	No
`output_sha256`	No
`content_omitted`	No
`output_lifetime`	No
`requested_count`	Yes
`retrieved_count`	Yes
`output_file_path`	No
`output_media_type`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.6.2Sep 5, 2026

addedOutput schema / $defs / EmailBodyResponse / properties / provider_keywords

Added value: +{
+  "items": {
+    "maxLength": 128,
+    "type": "string"
+  },
+  "maxItems": 100,
+  "title": "Provider Keywords",
+  "type": "array"
+}

addedOutput schema / $defs / EmailBodyResponse / properties / semantic_tags

Added value: +{
+  "items": {
+    "maxLength": 128,
+    "type": "string"
+  },
+  "maxItems": 100,
+  "title": "Semantic Tags",
+  "type": "array"
+}

Addedv1.1.1Aug 1, 2026
Removedv1.0.1Jul 25, 2026

Changed2 schema fields changedv0.14.0Jul 6, 2026

addedInput schema / properties / body_offset

Added value: +{
+  "default": 0,
+  "description": "Character offset into each email body to start reading from. Use together with max_body_length to page through long emails: if a returned body ends with the '...[TRUNCATED]' marker, fetch the next chunk with body_offset += max_body_length.",
+  "minimum": 0,
+  "title": "Body Offset",
+  "type": "integer"
+}

addedInput schema / properties / max_body_length

Added value: +{
+  "default": 20000,
+  "description": "Maximum number of body characters to return, counted from body_offset. If the body extends past this window, the '...[TRUNCATED]' marker is appended after the requested body window.",
+  "maximum": 100000,
+  "minimum": 1,
+  "title": "Max Body Length",
+  "type": "integer"
+}

Addedv0.8.0May 26, 2026
Removedv0.7.0May 22, 2026

Changed2 schema fields changedv0.6.3May 4, 2026

changedOutput schema / $defs / EmailBodyResponse / description

Previous value: -"Single email body response"New value: +"Single email body response - extends EmailMetadata with body content"

changedOutput schema / $defs / EmailBodyResponse / required

Previous value: -[
-  "email_id",
-  "subject",
-  "sender",
-  "recipients",
-  "date",
-  "body",
-  "attachments"
-]New value: +[
+  "email_id",
+  "subject",
+  "sender",
+  "recipients",
+  "date",
+  "attachments",
+  "body"
+]

Addedv1.0.0Jan 3, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context by explaining why it is non-read-only: mark_as_read=true changes remote flags. This goes beyond the annotations and helps the agent anticipate 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?

Three sentences with no filler: the first states the action and scope, the second gives the prerequisite, and the third explains the key side-effect. The most important guidance is front-loaded and each sentence earns its place.

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?

For a tool with six parameters, the input schema already documents pagination, limits, and defaults, and an output schema exists, so the description does not need to repeat those. It successfully adds the prerequisite and side-effect warning, making the definition complete for correct invocation.

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 description coverage is 100%, and each parameter already has detailed meaning: email_ids explains its source, body_offset and max_body_length explain pagination and truncation, and mark_as_read explains failure behavior. The tool description adds no additional parameter semantics beyond the schema, so 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 states a specific action ('Get the full content') and resource ('one or more emails by their email_id'), and specifies exactly what is included: body and reply-thread headers. This clearly distinguishes the tool from list_emails_metadata and get_attachment_content without needing to inspect sibling tools.

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

Usage Guidelines4/5

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

It explicitly provides a prerequisite: 'Use list_emails_metadata first.' It also warns that the tool is not read-only and identifies the exact condition that causes mutation (mark_as_read=true). It does not explicitly name alternatives like get_attachment_content, but the stated scope is enough for most routing decisions.

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

Deploy Server