Graph Mail MCP

by hanhandly

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools are clearly distinct by resource and action: folders, auth, messages, threads, attachments, drafts. There is slight potential confusion between mail_get_message and mail_get_thread (both retrieve messages), but descriptions clarify the difference (single message vs conversation). mail_list_attachments and mail_get_attachment are distinct (list vs get). Overall, boundaries are clear.
Naming Consistency5/5
All tools follow the exact pattern mail_<verb>_<noun>, using snake_case throughout. Verbs are consistent: list, auth, search, get, create, update. This is a highly predictable and consistent naming convention.
Tool Count5/5
Nine tools is well within the ideal range (3-15). Each tool serves a distinct purpose in the email domain: folder navigation, auth, search, retrieval, thread handling, attachments, and draft management. No redundant or trivial tools.
Completeness4/5
The tool set covers core email operations: listing folders, searching/reading messages, handling threads, attachments, and creating/updating drafts. A notable missing operation is sending or deleting messages/drafts, which would be expected for a full lifecycle. However, the focus on drafts (without send) may be intentional. Thus, a minor gap.
Average 3/5 across 9 of 9 tools scored. Lowest: 1.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavior. It only states the listing action and omits any information about pagination, hidden folders, required permissions, or effects. There is no mention of what happens when optional parameters are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is good for conciseness, but it is under-specified rather than efficiently detailed. It conveys no additional information beyond the tool name and a slightly expanded phrase, so it fails to earn its place through useful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five optional parameters, no output schema, and no annotations, the description is far too minimal. It does not explain return format, pagination behavior, or the meaning of mailboxScope variants. An agent cannot reliably invoke this tool correctly with just this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema itself provides no parameter descriptions. The description adds no meaning to any of the five parameters (cursor, pageSize, mailboxScope, includeHidden, parentFolderId). The agent is left without any guidance on parameter format, purpose, or relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource ('List folders'), but 'selected mailbox scope' is vague and does not clarify what scopes exist or how they are chosen. It does not distinguish this tool from siblings like mail_list_attachments, but it does identify the primary action and target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or conditions that would route an agent to a sibling tool like mail_search_messages or mail_get_thread.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description does not disclose side effects, permissions required, rate limits, or the exact output format. It does not explain the meaning of 'bounded' or the maxBytes parameter's effect.
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?
The description is extremely concise, using only 5 words, and is well-structured as a single phrase without redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, 2 required, and no output schema, the description is insufficient. It does not explain return types, error handling, or any additional context needed for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema includes parameters like mode, maxBytes, messageId, attachmentId, and mailboxScope, but the description offers no explanation for any of them. The schema itself provides some structure, but the description adds no semantic detail.
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?
The description 'Get bounded attachment metadata/text/base64 content' clearly indicates the tool retrieves attachment content with a verb and resource. It distinguishes from sibling tools like mail_list_attachments. However, the term 'bounded' is vague and could be misinterpreted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not specify when to use this tool versus alternatives. It does not mention conditions or exclusions, leaving usage guidelines unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It only implies a read operation via 'List' and 'metadata', but does not disclose return format, pagination, ordering, size limits, or authentication needs. It does not contradict any annotation.
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?
The description is a single, front-loaded sentence with no filler. It is concise and readable, though the brevity sacrifices useful context. For what is actually written, the structure is clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotation metadata, so an agent does not know what fields the metadata list contains or how the results are scoped or paginated. The required messageId is evident from the schema, but a list tool needs more context about its return shape and behavior to be fully callable without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to compensate for the parameters, but it mentions neither messageId nor mailboxScope. The input schema itself documents the parameters well, but the description adds no meaning beyond that structured data.
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?
The description states a clear action ('List'), resource ('attachments collection'), and the nature of the output ('metadata'), which distinguishes it from the sibling mail_get_attachment. It does not explicitly say the scope is a single message, but the required messageId parameter makes that clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool instead of siblings such as mail_get_attachment or mail_get_message. There are no stated prerequisites, exclusions, or conditions that would help an agent choose between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only reveals that the email is not sent; it fails to mention that this persists a draft, may require authentication, or that reply/reply_all/forward modes depend on a sourceMessageId. In contrast to a simple read tool, this mutation's side effects are largely undisclosed.
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?
The description is a single sentence with no wasted words and it front-loads the action. It is appropriately brief for conveying the core purpose, though for a tool with this many parameters it is nearly too terse to be genuinely helpful. It earns its place but nothing more.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex: 11 parameters, nested objects, enums, and no output schema. The one-line description omits crucial context, such as the requirement of sourceMessageId for reply/forward modes, the role of comment/body in those modes, the meaning of mailboxScope, and what the tool returns after creating the draft. An agent cannot correctly invoke this tool reliably from the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate across the 11 parameters. It only paraphrases the mode enum ('new/reply/reply-all/forward'), providing no meaningful detail on recipients, body, importance, mailboxScope, comment, or sourceMessageId. The one piece of parameter info is redundant with the schema and leaves the remaining parameters unexplained.
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?
The description states a clear verb and resource: 'Create a ... draft', and it enumerates the possible draft types. The word 'without sending' distinguishes this from any send operation, though it does not explicitly contrast with the sibling mail_update_draft. Still, the core purpose is unambiguous.
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?
The description implies usage: use this when a draft is needed and should not be sent immediately. However, it provides no explicit guidance on when to prefer a sibling (e.g., mail_update_draft for modifying an existing draft) or when a different mode is required. The 'without sending' phrasing gives context but no exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must carry the behavioral burden. It mentions a preflight step implying some safety checks, but doesn't state whether the update requires draft ownership, whether it's reversible, or what the response is. For a mutation tool, this is lacking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it's under-specified. It refers to 'registry and Graph preflight' that isn't elaborated, adding jargon without clarity, so it trades completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested objects, 5 params, no output schema, no annotations), the description is insufficient. It doesn't explain the preflight conditions, the effect of expectedEtag, or what happens on conflict. An agent needs more to call this correctly.
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 0%, so the description must compensateason. It doesn't explain the semantics of 'patch' or 'expectedEtag' or what the preflight checks. The description adds no information about parameters beyond the schema, leaving the agent to infer meaning from types and names.
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?
The description states the specific verb 'update' and resource 'an MCP-owned draft', distinguishing it from create draft and other mail tools. It also mentions a preflight step, but the phrase 'after registry and Graph preflight' is somewhat vague and doesn't fully clarify what the preflight entails.
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?
The description implies a workflow where preflight passes before updating, but doesn't give explicit when-to-use or when-not-to-use guidance. It doesn't compare to siblings like mail_create_draft or mail_get_message, so an agent has to infer usage from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states 'read', which implies a non-mutating operation, but does not disclose authentication requirements, potential rate limits, error behavior, or that it returns only one message. The body mode does hint at output content, but the description is too terse to fully disclose behavior.
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?
The description is a single, efficient sentence that leads with the action and essential qualifiers. It is front-loaded and contains no filler. It could be improved by adding usage context, but as a concise statement of purpose it is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters, three identifier types, and a body-mode option, the description is too sparse. It does not explain the different locator kinds (Graph ID, immutable ID, internetMessageId) or when to use each, nor does it mention the mailboxScope parameter. Without an output schema, it should at least state that the response includes the requested body or headers, but it only hints with 'body mode'. An agent would need to rely heavily on the schema to understand the full behavior.
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?
The schema already covers 75% of parameters with descriptions (locator, bodyMode, includeHeaders). The description adds minimal value—it mentions 'explicit body mode' but does not elaborate beyond the schema. Since coverage is high, the baseline of 3 is appropriate; the description does not compensate for the uncovered mailboxScope parameter, but that is not its role given the baseline.
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 is precise: it names the verb 'read', the resource 'one message', and specifies three identifier types plus an explicit body mode. This clearly distinguishes it from sibling tools like mail_search_messages or mail_get_thread, which handle different operations. There is no ambiguity about what the tool accomplishes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention that it is for retrieving a single message by ID, that it should be used after a search, or that get_thread is for a whole conversation. The schema's locator description hints at IDs from search, but the description itself offers no such context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It mentions 'safely' and explains the difference between query and subject, and it hints at mode selection (safe KQL vs OData) but does not disclose details about rate limits, authentication needs, or potential side effects. It doesn't describe what happens on errors or how results are paginated. This is a moderate gap, so a 3 is appropriate.
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?
The description is very concise with two sentences, front-loading the core purpose ('Search messages safely') and then immediately providing practical guidance on parameter choice. There is no wasted wording, and it efficiently covers the most important usage hint. It earns a 4 for clarity and minimalism, though it could be slightly more structured with explicit sections.
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?
Given the tool's complexity (14 parameters, no output schema, no annotations), the description could be more comprehensive. However, the schema itself is rich with descriptions, and the description covers the key decision point (subject vs query). It does not explain return format or error behavior, but since the schema is detailed, the description is adequate for an agent to call it correctly. A 4 is fitting.
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 high at 93%, so the baseline is 3. The description adds some value by clarifying that subject should be preferred over query for known titles, which is a semantic nuance beyond the schema. It does not detail the exact behavior of mode, cursor, or other parameters, but the schema descriptions are already comprehensive. Thus, a 3 is justified.
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 clearly states the tool's purpose: 'Search messages safely.' It specifies the verb 'search' and the resource 'messages', and it distinguishes between subject and query usage, differentiating it from sibling tools like mail_get_message or mail_list_folders. The emphasis on safety and the guidance on when to use subject vs query make the tool's function unambiguous.
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?
The description provides clear usage context: it says to prefer subject for a known title and warns that query is full-text and may match message bodies. This helps an agent choose between parameters. However, it does not explicitly mention alternatives among siblings (e.g., when to use mail_search_messages vs mail_get_message), though the distinction is implied. There is no explicit 'use this when' or 'avoid this if' statement, but the guidance is strong enough for a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a key safety behavior ('without exposing tokens') and enumerates the returned information. However, it does not state whether authentication itself is required to call this endpoint, whether it has side effects (it clearly does not), or any rate limits. For a read-only status check this is adequate but not rich.
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?
A single, well-structured sentence that front-loads the primary output (authentication status) and lists key details, ending with a security-relevant behavior (without exposing tokens). No fluff, no redundancy.
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?
For a zero-input status-check tool, the description covers the main return values and the token-safety guarantee. It doesn't mention error cases or whether auth status implies the caller is authenticated, but for a simple status check this is near-complete. A 4 reflects the minor gap of not explaining what 'next login action' means or side effects.
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?
The tool has zero parameters, so the description has no obligation to explain inputs. Per calibration, baseline is 4. The description adds no parameter semantics because there are none to explain.
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 names a specific resource ('mail authentication') and the exact information returned (status, expiry, unexpected-scope warnings, next login action). It clearly distinguishes itself from sibling tools like mail_list_attachments or mail_search_messages, which operate on mail content rather than authentication state.
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?
The purpose implicitly signals when to use the tool (when you need auth state), but there is no explicit guidance about when not to use it or how it relates to siblings. For a status-check tool with zero parameters, the context is largely self-evident, but a mention of typical use cases or prerequisites (e.g., 'call after auth failures') would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does a good job in parts: 'Reconstruct' signals a non-mutating, read-style operation, and the statement 'Embedded forwarded chains are not separate messages' surfaces a genuinely surprising behavior. It stops short of details like errors or response envelope, but the core behavioral trait is disclosed.
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?
Two dense sentences, with the central operation and scope front-loaded and the important exception stated after. Every clause contributes new operational information rather than restating the tool name or 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?
The description together with the very detailed input schema provides enough to select and configure the tool: the required seed, optional folder and message bounds, and body modes are all recoverable from the schema, while the prose covers the returned content concept ('headers', 'body mode'). Without an output schema or annotations, one could still appreciate the thread-level return and non-mutating nature, though response shape details are left open.
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?
The schema already documents 80% of the parameters with meaningful descriptions, so the description need not repeat them. The prose only echoes the concepts behind bodyMode and bounded reconstruction without adding new semantic details about seed, mailboxScope, or maxMessages beyond what the schema gives.
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 names a specific resource ('mailbox-local conversation') and a clear operation ('Reconstruct'), and it goes beyond a tautology by specifying 'complete per-message headers' and the 'requested body mode'. The clause about embedded forwarded chains not being separate messages distinguishes this threaded behavior from a simple message fetch.
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?
The wording implies this is the tool to use when a conversation-level reconstruction is needed, and the sibling mail_get_message reinforces that contrast. However, there is no explicit statement of when to prefer this over mail_get_message or when not to use it, so the guidance remains mostly implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![graph-mail-mcp MCP server](https://glama.ai/mcp/servers/hanhandly/graph-mail-mcp/badges/card.svg)](https://glama.ai/mcp/servers/hanhandly/graph-mail-mcp)

Score Badge

Copy to your README.md:

[![graph-mail-mcp MCP server](https://glama.ai/mcp/servers/hanhandly/graph-mail-mcp/badges/score.svg)](https://glama.ai/mcp/servers/hanhandly/graph-mail-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hanhandly/graph-mail-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server