163 Mail MCP

Overview Schema Related Servers Score Discussions

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: reading, sending, trashing, moving, search, and batch operations each target different actions. However, move_mail, trash_mail, set_read_state individually overlap conceptually with their batch counterparts, and preview_send/send_mail plus preview_batch_actions/execute_batch_actions form pairs that could cause mis-selection if an agent isn't careful about which stage is needed.
Naming Consistency4/5
Tools follow a consistent verb_noun pattern (list_folders, read_mail, send_mail, trash_mail, move_mail, download_attachments, set_read_state, mail_status). A minor deviation exists with search_mail_headers and the pair preview_batch_actions/execute_batch_actions, which use a descriptive phrase style rather than a single verb, but the overall naming is coherent and predictable.
Tool Count4/5
At 12 tools, the count is reasonable for a mail MCP server covering read, search, send, move, trash, mark, attachment, batch, and status operations. It sits slightly above the ideal core set but each tool serves a distinct function; a couple of tools could theoretically be merged (e.g., single-action operations could be covered by batch), but the count is well within acceptable bounds.
Completeness4/5
The surface covers core mailbox operations: listing folders, status, searching, reading, sending, moving, trashing, marking read state, batch operations, and attachments. Minor gaps include no explicit compose/save-draft tool (preview_send acts as a proxy), no message-level threading/folder management (create/delete folders), and no way to fetch full content beyond a single message, but the main workflows are covered without dead ends.
Average 3.6/5 across 12 of 12 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states two key behaviors: the confirm gate and never-overwriting files. With annotations declaring readOnlyHint=false, destructiveHint=false, and idempotentHint=false, the description adds the specific 'never overwrites' safety detail that annotations don't capture. However, it doesn't disclose error behaviors, what happens on partial failures, or the confirm failure case.
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?
Two sentences, both meaningful and front-loaded. The confirm requirement and overwrite behavior are the critical facts and they're placed first. Efficient with zero filler, though could use a brief sentence on output structure.
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?
With 7 parameters, 0% schema coverage, and an output schema present, the description should explain the non-obvious parameters (indexes format, size limits, uid/folder relationship). The description only covers confirm and the overwrite policy. For a mutating download tool with size limits and an indexes selection mechanism, the guidance is substantially incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full burden for explaining parameters. The description mentions 'selected attachments' (mapping to indexes) and the confirm constraint, but doesn't explain uid, folder, output_dir, or the size-limit parameters (max_total_bytes, max_download_bytes) at all. The indexes parameter semantics (how they're formatted, what they refer to) are left 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 the verb (download) and resource (attachments) clearly. It adds the important safety context that it requires confirm='DOWNLOAD' and never overwrites files, which distinguishes it from generic download behavior. However, it doesn't explicitly distinguish from sibling tools, though the verb+resource is specific enough to be unambiguous.
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 mentions a confirm requirement (confirm='DOWNLOAD') and the never-overwrite behavior, which are both usage constraints. However, it doesn't explain when to use this vs alternatives (e.g., batch download via execute_batch_actions), nor does it state prerequisites like needing indexes from a prior listing step. The guidance is thin but not misleading.
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?
Annotations declare readOnlyHint=false (it's a write operation), destructiveHint=false, and idempotentHint=true. The description adds the confirmation requirement (confirm='MARK') and explicit user approval need, which is useful context beyond the annotations. However, it doesn't mention side effects, failure modes, or what happens if approval isn't given.
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?
Two concise sentences, no wasted words. Front-loaded with the core action. The confirmation requirement is efficiently stated.
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 4-parameter tool with 0% schema description coverage, the description is thin. The uid and folder parameters are entirely unexplained. No mention of behavior on invalid uid/folder, return values/flags, or how approval is obtained. The output schema exists, but the description still leaves critical parameter and workflow gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full parameter documentation burden. It only mentions 'state' (read/unread, which the enum already covers) and 'confirm' (which the schema const already defines). The uid and folder parameters are completely undocumented in both the description and schema (no description coverage), leaving the agent guessing about their format and meaning.
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 the tool sets state to 'read' or 'unread', which is a specific verb+resource. However, it doesn't clarify what resource is being modified (mails/messages), relying on the tool name. The sibling tools like read_mail and mail_status suggest this marks mail read state, but the description doesn't spell this out.
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 mentions requiring 'exact user approval and confirm='MARK'' which conveys a prerequisite/confirmation requirement. However, it doesn't explain when to use this vs. alternatives like read_mail, or when NOT to use it. The sibling differentiation is minimal given mail_status and read_mail exist.
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 include readOnlyHint=false and destructiveHint=false, but idempotentHint=false indicates non-idempotent operations. The description mentions 'Requires user approval' and 'matching digest' which adds context, but doesn't explain what the digest is, how to obtain it, or behavioral details like email delivery semantics, rate limits, or failure modes. For a tool that actually dispatches emails, the description should disclose side effects more clearly.
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?
One concise sentence that packs essential usage constraints (approval, confirm value, digest matching). Zero waste, front-loaded with the core action. Could be slightly more structured but is efficient.
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 0% schema coverage and 8 parameters, the description leaves significant gaps. The digest parameter is mentioned in passing but its purpose/source is unexplained (it must come from preview_send presumably, but this isn't stated). The 'previewed draft' reference implies a workflow dependency on preview_send but doesn't make it explicit. With an output schema present, return values are covered, but the input semantics are underspecified for an 8-parameter send operation.
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 coverage is 0%, so the description carries full burden. It mentions 'confirm='SEND'' and 'matching digest' — these are critical parameter semantics (the confirm const and digest matching requirement). However, it doesn't explain to, subject, body_text, cc, bcc, or attachments, which the schema itself only labels with names and types. With 8 parameters and 0% coverage, the description should compensate more.
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 says 'Send the previewed draft,' which identifies the verb (send) and resource (previewed draft). However, it doesn't clearly distinguish this from preview_send or other mail actions, and 'previewed draft' is somewhat vague without explaining the preview→send workflow connection.
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 implicitly conveys when to use this tool (after previewing, requires approval, confirmation token 'SEND', and matching digest). It implies a workflow context with preview_send but doesn't name sibling tools explicitly or describe when NOT to use it.
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?
The description adds meaningful behavioral context beyond annotations: it explicitly states 'never issues EXPUNGE,' which clarifies the non-destructive side effects (moving without expunging the source). Annotations already declare destructiveHint=true and readOnlyHint=false, and the description complements rather than contradicts them. However, it doesn't disclose what happens on failure, whether the source folder's state changes, or any auth/permission requirements beyond the confirm token.
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 sentences, zero filler. Every word earns its place: the action, the approval requirement, and the EXPUNGE guarantee. This is exemplarily concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a destructive mutation (destructiveHint=true) with 4 required parameters and 0% schema coverage, so the description bears significant burden. The confirm requirement and EXPUNGE clarification are valuable, but the description omits any guidance on folder naming, UID format, failure behavior, or the relationship between from_folder and to_folder. An output schema exists which may help, but the description itself leaves important operational details unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only explains the 'confirm' parameter ('requires confirm="MOVE"'). The uid, from_folder, and to_folder parameters are entirely unexplained in prose — no format details for uid, no path conventions for folder names, no interaction semantics between from/to folders. With 0% coverage, the description must compensate but only addresses one of four parameters.
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 clearly states the verb (Move), resource (one UID), and a critical requirement ('after exact user approval'). However, it doesn't distinguish the tool from the sibling 'trash_mail' which is also a mutation moving messages out of folders, and 'execute_batch_actions' may also move messages. The single-UID scope is clear but sibling differentiation is implicit rather than explicit.
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 provides a clear precondition for use (requires exact user approval via confirm='MOVE'), which is strong usage guidance. However, it doesn't explain when to prefer this over trash_mail or batch_move, nor when one would use MOVE versus DELETE/EXPUNGE semantics. The 'after exact user approval' framing helps but exclusions/alternatives aren't addressed.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a write operation. The description adds the valuable 'rechecks every item before any write' detail, indicating safety validation behavior. However, it doesn't disclose what happens on validation failure, partial execution, or the confirmation requirement implied by the 'confirm' parameter. With destructive annotations present, some credit is warranted for the recheck disclosure, but more could be said about rollback/partial 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?
Single sentence, concise, front-loaded with the primary action. Every word earns its place — 'unchanged' and 'rechecks every item' add meaningful safety context. No padding or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a destructive batch operation with 3 undocumented parameters. The description provides the safety-critical 'rechecks every item' guarantee and the 'after approval' sequencing, but given its destructive nature and zero schema coverage, it would benefit from explaining what the digest represents, what the confirm field enforces, and what happens on mismatch. The output schema existing helps somewhat, but the description could still be more complete for a destructive tool.
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 compensate for the undocumented parameters. The description mentions 'rechecks every item' which implicitly explains the 'actions' and 'digest' parameters (the digest likely validates the batch is unchanged). However, it doesn't explain the 'confirm' constant requirement or the digest's exact purpose explicitly, leaving some ambiguity for a 3-parameter tool with zero schema coverage.
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 specific verb+resource: 'Execute the unchanged previewed batch after approval' — this makes the core purpose clear. It distinguishes itself from siblings like preview_batch_actions and preview_send by focusing on execution of a previously previewed batch, though it doesn't explicitly name alternatives.
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 phrase 'after approval' implies a prerequisite workflow (preview first, then approve, then execute), and 'unchanged previewed batch' signals that the input must match the previewed content. However, it doesn't explicitly say when NOT to use this tool or name alternative tools explicitly, leaving the guidance somewhat implicit.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds the 'Does not send' safety reassurance and mentions it 'returns the required digest,' which adds value beyond annotations. But it does not detail what the digest contains or format implications. With strong annotations covering the safety profile, 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?
Two short, front-loaded sentences with zero waste. The 'Does not send; returns the required digest' is efficient and clarifies both behavior and return. Could be slightly more informative about recipients format but is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters including complex arrays for cc/bcc/attachments, an output schema exists, and annotations are solid. The description tells the agent this is a non-sending validation + digest return, which combined with annotations and output schema gives reasonable completeness. However, with 0% schema coverage on 6 parameters and no param guidance in the description, there's a gap around what the digest actually validates (address format? attachment presence? sendability?).
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 compensate for 6 parameters. The description does NOT explain any parameter semantics, nor does it indicate which fields (email addresses vs filenames) the array parameters expect. Baseline should be 3 due to the coverage gap, and the description fails to add param-level meaning.
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 clearly states the verb (validate and preview), the resource (an exact draft), and explicitly disambiguates from sending ('Does not send'). It distinguishes from sibling send_mail well, though it doesn't elaborate on what the 'required digest' is or how it differs from other preview tools.
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 communicates the core context: this validates/previews rather than sends, implying it should be used before send_mail. However, it doesn't explicitly state when to use it versus alternatives like preview_batch_actions, nor when NOT to use it, and lacks guidance on prerequisites or ordering.
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?
Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, covering the safety profile. The description adds useful behavioral context: the never-issues-EXPUNGE guarantee and the confirmation requirement. However, it doesn't disclose what happens to the mail in the trash (recovery options, retention), which limits the additional value beyond annotations.
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 crisp sentences, zero filler. Every word earns its place — action, scope, and a critical safety guarantee are all front-loaded in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 required params and an output schema, and is a destructive operation with a confirm safeguard. The description covers the action and the confirm gate, but given the destructive nature, it could disclose more about side effects (HAS output schema helps, but the safety-critical confirm mechanism deserves more explicit callout about what happens without the confirm value).
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 compensate for parameter meaning. It names confirm='TRASH' as a required confirmation value and references folder/trash_folder implicitly, but doesn't explain what each of the 4 parameters means in detail (e.g., what 'folder' is versus 'trash_folder'). Partial compensation for the coverage gap.
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 clearly states the action ('Move one UID to a named trash folder') with a specific verb, resource, and destination. It distinguishes somewhat from the sibling 'move_mail' tool through the trash-specific naming and confirm requirement, though it doesn't explicitly differentiate the two move operations.
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 context (moving a single mail to trash, requiring a confirm='TRASH' param), but provides no explicit guidance on when to choose this over move_mail or other alternatives. The confirm requirement provides some usage guardrail but no comprehensive when/when-not guidance.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the useful behavioral note that 'message bodies are not fetched', which informs the agent that results will lack body content. However, it doesn't describe the output shape, pagination, or header fields returned beyond the schema.
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 short sentences, zero filler. The critical operational facts (date format, bodies not fetched) are communicated efficiently with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a rich output schema and heavy annotation coverage, which raises the baseline. Given 9 parameters including a dual-limit pattern (limit vs scan_limit) and multiple overlapping filters (query, folder, subject, from_filter, unseen), the description could benefit from explaining how these interact. It is adequate but leaves the dual-limit semantics ambiguous.
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 0% with 9 parameters, so the description must compensate for parameter understanding. It adds the date format convention (YYYY-MM-DD) and clarifies that bodies aren't returned, which helps interpret query/filter params. However, it doesn't explain the semantics of scan_limit vs limit, or the interplay of query/folder/subject/from_filter, leaving room for more 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 verb 'search' plus resource 'mail headers' clearly establishes the tool filters mail by headers (as opposed to body content). The date format note (YYYY-MM-DD) adds practical specificity. However, it doesn't explicitly distinguish from read_mail or list operations among siblings, though the 'headers only' scope differentiates it well.
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 this searches headers rather than bodies, which gives some context, but it doesn't explicitly state when to use this vs read_mail, mail_status, or list_folders. No when-not or alternative tool guidance is provided. The context is minimally clear but underdeveloped.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful reinforcement by explicitly stating 'without changing mailbox state,' which is valuable context confirming the non-mutating guarantee. This exceeds what annotations alone convey by reassuring users about side-effect-free behavior in prose form.
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 a single, efficient sentence with zero wasted words. Everything stated is necessary: the operation (list), the resource (folders), and the non-mutation guarantee. There is no redundant or filler content.
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 has 0 parameters, comprehensive annotations (readOnly, idempotent, openWorld, non-destructive), and an output schema, the description is complete for its simplicity level. It clearly covers purpose and side-effect safety. The only minor gap is lack of explicit guidance about when folder enumeration is needed (e.g., before sending/moving mail), but the output schema and annotations fill most context needs.
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 0 parameters with 100% schema coverage, so parameter semantics concerns are moot. The baseline for 0-parameter tools is 4, and the description doesn't need to add parameter meaning since there are none. The description's state-preservation note is the only semantically relevant addition and it's on point.
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 'List available mailbox folders without changing mailbox state' clearly identifies the verb (list), resource (mailbox folders), and the non-mutating scope. It doesn't explicitly distinguish from siblings, though among sibling tools (search, read, send, trash, move mail), 'list folders' is a fairly unique distinct operation, so differentiation is implicitly clear.
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 context (listing available folders is a read/preparation operation) but does not explicitly state when to use it versus alternatives or mention any exclusions. Since sibling tools are focused on mail items rather than folder enumeration, there's reasonable implicit guidance, but no explicit when/when-not guidance is given.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds meaningful context: it uses BODY.PEEK specifically to preserve unread state, and warns that returned content should be treated as untrusted (security context). These add value beyond the annotations. Strong disclosure of the unread-preservation behavior and security caution.
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 sentences, zero wasted words. Front-loaded with the primary action, then adds behavioral and security context. Every word earns its place. Extremely efficient and complete for its length.
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 tool has an output schema, so return-value explanation isn't required. The description covers core purpose, unread behavior, and security posture. With 4 parameters at 0% coverage, not addressing parameters represents a small gap, but the parameter names (uid, folder, max_chars, max_download_bytes) are reasonably self-explanatory. The output schema and annotations fill remaining gaps. Relatively complete for a moderately complex tool with an output schema.
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 coverage is 0%, meaning no parameter is described in the schema, so the description should compensate. However, the description does not mention any parameters (uid, folder, max_chars, max_download_bytes). The max_chars and max_download_bytes limits are not trivial to infer from names alone, though they are somewhat self-explanatory. With 0% coverage, the description should have addressed at least the limits parameters. Description adds zero parameter semantics; the names carry the meaning but limits purpose is not explained.
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?
Description states a specific verb+resource ('Read one message') and distinguishes from siblings by mentioning BODY.PEEK to keep it unread, which differentiates it from set_read_state and trash_mail. Could be clearer about the object being an email/mail, but 'one message' is unambiguous enough. Purpose is clear: read a single message without marking it as read.
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 BODY.PEEK detail implies this is for reading without changing read state, giving context about when to use it vs set_read_state. However, it doesn't explicitly name alternatives (e.g., for batch reading use search_mail_headers, or that read_mail is for a single message), though the tool name and single-uid required parameter make the scoping clear. Clear context lacking explicit exclusions or named siblings.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds value by stating 'makes no changes' explicitly and clarifying the input format (exact JSON action structures), which goes beyond the schema. It also demonstrates that target_folder uses localized values (like '已删除'), a useful real-world nuance. However, it doesn't detail what the returned digest contains or how batches over 50 are handled.
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 compact and front-loaded with the core purpose in the first sentence. The JSON examples are highly instructive and earn their space. It could arguably be slightly tighter, but each element adds real value with no filler.
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 there is an output schema covering the return value, the description's job is to cover inputs and behavior, which it does thoroughly. It explains the action schema, supported action types, count limits, and the no-op guarantee. Minor gap: doesn't specify what a valid uid looks like or confirm the action-type set is exhaustive, but overall it's strong for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the schema only provides a loose 'additionalProperties: string' object type with no field names or meaning. The description fully compensates by specifying the exact action schema (action/uid/source_folder/target_folder/state), giving concrete JSON examples for each of the three action types, and clarifying the 1-50 count constraint. This is exemplary parameter documentation.
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 verb (preview), resource (batch actions: move, trash, read-state), scope (1-50 actions), and outcome ('returns a digest and makes no changes'). It also distinguishes from unlikely siblings by noting the digest/no-changes behavior, setting it apart from execute_batch_actions.
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 clearly states when to use this (to preview actions before executing) via the 'makes no changes' clause, and the examples demonstrate the three supported action types. However, it doesn't explicitly name execute_batch_actions as the alternative to use when wanting to actually apply changes, though this is strongly implied by the sibling context and 'makes no changes' phrasing.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the tool's safety profile is well-covered. The description adds meaningful context beyond annotations: it performs a LIVE IMAP authentication check (implying network interaction) and explicitly disclaims reading messages. This enriches the agent's understanding of what side effects might occur.
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 a single, dense sentence that fully captures the tool's purpose: checking local config plus live IMAP auth, and explicitly noting it doesn't read messages. Zero waste—every word 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?
Given the tool has no parameters, rich annotations (readOnly, idempotent, non-destructive), and an output schema, the description adequately covers what's needed. The note about live authentication and not reading messages covers the behavioral dimensions not captured elsewhere. Not much more could be added without redundancy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema coverage, so per the rubric, the description carries no parameter burden. The description correctly conveys that the tool operates on the local environment's configuration with no user-supplied inputs, which is sufficient.
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 what the tool does: 'Check local configuration plus live IMAP authentication; does not read messages.' The verb 'check' + specific targets (configuration, IMAP authentication) makes the purpose unambiguous. It also differentiates itself from sibling tools by explicitly stating it does not read messages, distinguishing it from read_mail.
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 implies this is a setup/diagnostic tool for verifying configuration and connectivity before performing mail operations. It doesn't explicitly name alternatives or provide when-not-to-use guidance, but the 'check...does not read messages' framing gives clear context that this is a meta/diagnostic operation rather than a mail-reading operation.
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:

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

Score Badge

Copy to your README.md:

[![163-mail-mcp MCP server](https://glama.ai/mcp/servers/adjurtime/163-mail-mcp/badges/score.svg)](https://glama.ai/mcp/servers/adjurtime/163-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/adjurtime/163-mail-mcp'

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