Skip to main content
Glama
devyhan

ms-graph-mcp

by devyhan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Get one mail message

mail_get_message
Read-onlyIdempotent

Fetch a single email by ID from Microsoft Graph, including sender, recipients, timestamps, and body text or preview; attachments need a separate call and reading does not mark it read.

Instructions

Returns one message with its body plus sender, recipients, timestamps, importance, conversationId and webLink. The body defaults to plain text and is capped at 8000 characters; raise maxBodyChars for a long thread, or pass format:"preview" to skip the body when you only need to identify the message. Attachment contents are never included — use mail_list_attachments. Reading a message here does not mark it read; use mail_mark_read for that. DO NOT loop this over a reply chain: each message quotes the ones before it, so reading a thread one call at a time returns the same text again and again — on a measured 24-message thread that was 381,000 characters, four times what the same content costs through mail_fetch_thread, which folds the repeats. Use this tool for a single message, and mail_fetch_thread for two or more of one conversation. bodyRendering says where the text came from: "exchange-text" is Exchange's own conversion, "stripped-html" means the tags were removed locally and every link went with them (linksLost counts how many), "html" is raw markup.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesThe message id, as returned by mail_list_messages.
formatNoHow to return the body. "text" (default) asks Graph for plain text and strips any HTML that comes back anyway. "html" returns the raw markup, which costs several times more tokens. "preview" skips the body entirely and returns only the 255-character bodyPreview — use it when you just need to confirm you have the right message.text
foldLinksNoReplace click-tracking URLs — those over 200 characters — with a marker naming the host and the original length. On a notification mail those redirectors are most of the body and none of the meaning; ordinary links of any normal length are returned untouched. Set false only if you need a tracking URL verbatim.
maxBodyCharsNoCharacter budget for the body. Defaults to 8000, which covers most messages. The server's own output cap still applies on top of this.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.0
    • addedInput schema / properties / foldLinks
      Added value: +{
+  "default": true,
+  "description": "Replace click-tracking URLs — those over 200 characters — with a marker naming the host and the original length. On a notification mail those redirectors are most of the body and none of the meaning; ordinary links of any normal length are returned untouched. Set false only if you need a tracking URL verbatim.",
+  "type": "boolean"
+}
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare the safe-read profile (readOnlyHint, idempotentHint, destructiveHint=false), and the description adds substantial context beyond that: reading does not mark the message read, the body is capped at 8000 chars, attachment contents are never returned, and bodyRendering/linksLost explain provenance and lossy HTML stripping. This is rich disclosure that annotations alone could not convey.

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 return shape, then constraints, then routing — a sensible order. It is long (~200 words) for a single-message getter, but nearly every sentence carries actionable information (caps, non-mutating behavior, bodyRendering semantics); only the bodyRendering detail verges on over-explaining.

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-value burden and does so fully: it enumerates the fields returned and explains bodyRendering and linksLost. Combined with the cap, format, and non-marking behavior, an agent has everything needed to call and interpret this tool 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 the baseline is 3, but the description adds decision context the schema does not: raise maxBodyChars for a long thread, and use format:"preview" to skip the body when only identifying a message. It stops short of explaining foldLinks, which is left entirely to the schema.

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 ('Returns one message with its body plus sender, recipients, timestamps, importance, conversationId and webLink') and explicitly demarcates itself from siblings: 'Use this tool for a single message, and mail_fetch_thread for two or more of one conversation.' An agent can distinguish it from mail_list_messages, mail_fetch_thread, and mail_list_attachments without opening any schema.

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

Usage Guidelines5/5

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

Gives explicit when/when-not and named alternatives: use mail_list_attachments for attachment contents, mail_mark_read for marking read, mail_fetch_thread for two or more messages of one conversation, and format:"preview" when you only need to identify the message. The anti-pattern (looping over a reply chain) is called out with a concrete cost measurement.

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