Skip to main content
Glama
littlebearapps

Outlook Assistant

by littlebearapps
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Read Email

read-email
Read-onlyIdempotent

Retrieve a single email by ID to view subject, sender/recipients, date, and body as Markdown, or inspect forensic headers for authentication checks.

Instructions

Read a single email by id (read-only). Returns subject, from/to/cc, date and the body as Markdown (HTML stripped to text): up to 2,000 characters by default, up to 40,000 with outputVerbosity: full; a cut body ends with a note on how to get the rest. With headersMode: true: returns RFC-822 forensic headers in place of the body (DKIM, SPF, DMARC, Received chain, Message-ID, Authentication-Results) — importantOnly: true for the security-relevant subset, groupByType: true for a category-bucketed view, raw: true for JSON. With includeHeaders: true (non-headers-mode): adds basic headers alongside the body. If the id came from a shared/delegated mailbox (e.g. via search-emails or access-shared-mailbox with sharedMailbox set), you MUST pass the same sharedMailbox (or alias email) here — message IDs are mailbox-scoped, and reading a shared-mailbox id without it fails with 404 ErrorInvalidMailboxItemId.

Input Schema

NameRequiredDescriptionDefault
idYesID of the email to read
rawNoReturn the headers as raw JSON, not Markdown (headersMode only, default: false)
emailNoAlias for `sharedMailbox`.
groupByTypeNoGroup headers by category (headersMode only, default: false)
headersModeNoReturn forensic headers in place of the email content (default: false)
importantOnlyNoShow only important headers (headersMode only, default: false)
sharedMailboxNoEmail address of the shared/delegated mailbox the id belongs to. Required when the id was obtained from a shared mailbox — message IDs are mailbox-scoped and reading without it returns 404 ErrorInvalidMailboxItemId. Requires delegate access + Mail.Read.Shared. Work/school only; needs the server opt-in setting OUTLOOK_SHARED_MAILBOX (otherwise the call is refused with setup guidance).
includeHeadersNoInclude basic headers alongside email content (default: false)
outputVerbosityNoOutput detail level (default: standard). minimal: body preview only; standard: body up to 2,000 characters; full: adds IDs, body up to 40,000 characters. For a longer body, export it with `export` target=message.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv3.14.1
    • addedInput schema / properties / email
      Added value: +{
+  "description": "Alias for `sharedMailbox`.",
+  "type": "string"
+}
    • changedInput schema / properties / headersMode / description
      Previous value: -"Return forensic headers instead of email content (default: false)"New value: +"Return forensic headers in place of the email content (default: false)"
    • changedInput schema / properties / outputVerbosity / description
      Previous value: -"Output detail level (default: standard)"New value: +"Output detail level (default: standard). minimal: body preview only; standard: body up to 2,000 characters; full: adds IDs, body up to 40,000 characters. For a longer body, export it with `export` target=message."
    • changedInput schema / properties / raw / description
      Previous value: -"Return raw JSON instead of Markdown (headersMode only, default: false)"New value: +"Return the headers as raw JSON, not Markdown (headersMode only, default: false)"
    • addedInput schema / properties / sharedMailbox
      Added value: +{
+  "description": "Email address of the shared/delegated mailbox the id belongs to. Required when the id was obtained from a shared mailbox — message IDs are mailbox-scoped and reading without it returns 404 ErrorInvalidMailboxItemId. Requires delegate access + Mail.Read.Shared. Work/school only; needs the server opt-in setting OUTLOOK_SHARED_MAILBOX (otherwise the call is refused with setup guidance).",
+  "type": "string"
+}
  2. Changed1 schema field changedv3.7.4
    • addedInput schema / additionalProperties
      Added value: +false
  3. First observedv3.4.1

TDQS

A4.6/5.0
Behavior5/5

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

Well beyond the annotations: it discloses default truncation at 2,000 characters vs 40,000 with outputVerbosity: full, that truncated bodies end with a remediation note, the exact failure mode (404 ErrorInvalidMailboxItemId) for mailbox-scoped ids, and that shared-mailbox access requires delegate access, Mail.Read.Shared, and the OUTLOOK_SHARED_MAILBOX opt-in.

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?

A single dense paragraph, but it is front-loaded with the core behavior (read by id, what is returned, truncation limits) before moving to the mode flags and the critical sharedMailbox warning. Some phrasing duplicates the schema's sharedMailbox text, which costs a little efficiency.

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 9-parameter, mode-heavy tool with no output schema, the description covers what comes back, how much, how it is truncated, how the header modes alter the payload, and the single highest-risk failure mode. An agent has everything needed to call it correctly.

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 coverage is 100%, so baseline is 3, but the description adds cross-parameter semantics the schema does not: raw/importantOnly/groupByType are explicitly scoped to headersMode, and includeHeaders is described as the non-headers-mode variant. The outputVerbosity character budgets and the sharedMailbox 404 consequence go beyond the field-level descriptions.

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 ('Read a single email by id') and immediately scopes it as read-only, which distinguishes it from siblings like search-emails, send-email, and update-email. The return payload is enumerated concretely (subject, from/to/cc, date, body as Markdown).

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?

Gives clear mode-selection guidance (headersMode, includeHeaders, outputVerbosity) and a hard routing rule: if the id came from search-emails or access-shared-mailbox with sharedMailbox set, the same sharedMailbox MUST be passed here. It does not explicitly state when NOT to use this tool (e.g. for multiple messages), so it stops short of full when/when-not/alternatives coverage.

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