Mail-MCP

by Rixtayz

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a clearly distinct operation: folders, individual message retrieval, search, sender aggregation, move/delete by ID, bulk by sender, and unsubscribe. Overlap between search and sender summary is explicitly addressed by their descriptions and intended use cases.
Naming Consistency4/5
The mail_ prefix and snake_case style are consistent throughout, and most names use a verb_noun pattern. A few names like mail_senders_summary and mail_bulk_by_sender are noun/adjective phrases rather than clear verb-first names, which is a minor deviation.
Tool Count5/5
Nine tools is a well-scoped count for a mailbox management server. Each tool covers a meaningful operation without redundancy or unnecessary bloat.
Completeness4/5
The toolset covers the core mailbox triage workflow well: search, read, summarize, move, delete, bulk-manage, and unsubscribe. Missing operations like folder deletion/renaming, sending messages, or marking messages as read are notable but do not break the primary use case.
Average 4.5/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds meaningful behavioral details beyond that: body is converted to text, truncated at 25,000 characters, and includes unsubscribe options from headers. This provides concrete expectations about output format and limits, adding value without contradicting 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?
The description is two sentences with no filler. The first sentence front-loads the primary purpose and lists what is returned; the second sentence adds the truncation limit. Every piece of information earns its place, and the structure is efficient and scannable.
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 single-parameter schema, the presence of an output schema, and annotations covering safety and idempotency, the description provides all essential context: what content is returned, how it's formatted, and the truncation limit. No additional information is needed for correct invocation, so it is complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter-specific information beyond the schema; it never mentions the 'id' parameter or its format. The schema already documents that the id comes from mail_search or mail_senders_summary, so the description adds no extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Return') and resource ('full content of one message'), and enumerates specific included elements (body as text, recipients, attachment flag, web link, unsubscribe options). This distinguishes it from siblings like mail_search (which lists messages) and mail_unsubscribe (which acts on subscriptions). The purpose is unambiguous and specific.
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 does not explicitly state when to use this tool versus alternatives, nor does it name any exclusions. However, it implies usage for retrieving a single message's full details after locating an id via mail_search or mail_senders_summary. The contrast with siblings is inferable but not spelled out, so the guidance is implicit rather than explicit.
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?
The description discloses that the scan is cached for the session, which is useful behavioral information beyond the readOnly and idempotent annotations. It also clarifies that it scans a whole folder by default, implying no destructive or state-changing side effects. No contradiction exists with the provided annotations.
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 informative, covering behavior, sorting, caching, and suggested follow-up actions. The opening phrase 'KEY TOOL FOR TRIAGE' is a minor stylistic flourish rather than essential information, but it does not detract much from overall clarity.
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's moderate complexity, the description adequately covers the scanning behavior, default folder, summary fields, sorting, caching, and follow-up tools. Since an output schema exists, the description does not need to detail return structures, and no important context appears missing.
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 for parameters is 100%, so the baseline is 3. The description mostly restates the folder default and does not add meaningful semantics beyond the schema descriptions for top, since, or folder. Thus the description does not significantly enhance parameter understanding.
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 that the tool scans a folder and aggregates messages by sender, which distinguishes it from siblings like mail_search, mail_get_message, and mail_bulk_by_sender. It also specifies the summary contents: count, unread, latest message, and unsubscribe method. This makes the tool's purpose 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 frames the tool as a key triage tool and suggests follow-up actions with mail_unsubscribe and mail_bulk_by_sender, giving useful workflow context. It does not explicitly state when to prefer this over mail_search or mail_list_folders, but the purpose is clear enough for an agent to choose appropriately.
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 flag destructiveHint=true, but the description adds valuable nuance: 'Deletion goes to Deleted Items unless permanent: true.' This goes beyond the schema and annotations, disclosing the non-permanent default behavior and the effect of the permanent flag. It also implies the tool is safe to preview via dryRun.
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 with zero waste. The primary action and scope are front-loaded, followed by the critical safety tip (dryRun) and the deletion destination nuance. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, destructive nature) and that an output schema exists, the description covers all essential operational aspects: what it does, the default folder, the dryRun safeguard, and deletion behavior. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a meaningful description (e.g., dryRun 'count only, change nothing', targetFolder 'Required when action = move'). The description adds no new parameter details beyond what the schema already provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact action ('Move or delete EVERY message from a sender') with a specific resource (sender address, folder) and clearly distinguishes it from single-message tools like mail_move and mail_delete. It also specifies the default folder, leaving no ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit usage recommendation: 'Use dryRun: true first to learn how many messages match.' This is clear operational guidance. However, it does not explicitly name alternatives or state when to use this tool versus the single-message siblings, leaving some inference to the agent.
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 idempotentHint=true, and the description restates this with 'if a folder with the same name already exists it is returned without error.' While the description adds a slight detail ('without error'), it does not introduce new behavioral information beyond the annotation. Other behaviors (e.g., auth requirements, error on missing parent) are not 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?
The description is three sentences with zero fluff: action, idempotency, and examples. It front-loads the core purpose and uses a compact, informative format that an agent can parse quickly.
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's simplicity (2 params, both documented), the presence of an output schema, and annotations covering idempotency and safety, the description covers everything an agent needs to invoke it correctly. No critical information is missing.
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% and both parameters are described. The description adds concrete usage examples ('Newsletters', '2025' with parent 'Invoices') that clarify how to structure calls, which goes beyond the schema's terse descriptions and helps an agent compose correct inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create'), a resource ('Outlook folder'), and scope ('at the root or under a parent'). It clearly differentiates from siblings like mail_list_folders and mail_move by its action, leaving no ambiguity about what the tool does.
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 context for when to use the tool (creating folders) and includes practical examples. It does not explicitly name alternatives or exclusions, but the purpose is so distinct among siblings that an agent can infer usage without confusion.
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 cover readOnly=false, destructive=false, and idempotentHint=true. The description adds critical behavioral context: Outlook assigns new ids and the result maps old to new. This goes beyond annotations and is essential for interpreting results.
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 two sentences plus a note, all front-loaded with the main action and limit. The note about id reassignment is placed after the main action but is concise and high-value. Zero waste.
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 two simple parameters, the description covers the essential behavior (move, limit, folder format, id mapping) and the alternative for bulk moves. It doesn't mention error handling, but with an output schema present (though not shown) and moderate complexity, it's sufficient.
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% (both parameters have descriptions), giving a baseline of 3. The description adds meaning beyond the schema by specifying that the folder parameter can be a name, path, or id, which is not in the schema's generic 'Destination folder' text.
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 'Move' and resource 'messages', with limits (up to 500 ids) and destination format (folder name/path/id). It explicitly differentiates from the sibling mail_bulk_by_sender by naming it, so an agent can distinguish without opening other schemas.
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?
It states the use case ('Used for filing') and gives an explicit exclusion: 'To move every message from a sender, prefer mail_bulk_by_sender.' This provides a clear when-to-use and when-not-to-use condition with the alternative named.
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, covering safety. The description adds value by specifying the returned fields and the relationship to other tools' folder-identification formats. No contradictions; it doesn't address potential performance or pagination, but for a read-only list tool this is minor.
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 with no fluff. The primary action and output are front-loaded, followed by targeted usage context. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with an output schema and safety annotations, the description is complete. It states what it returns, when to call it, and how the results integrate with sibling tools. Nothing essential is missing.
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 schema covers everything (coverage 100%). The description doesn't need to explain parameters, and it doesn't attempt to—correctly leaving that to the schema. Baseline for no parameters is 4.
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 (List), the resource (every folder of the Outlook.com mailbox), and the specific output (path, total message count, unread count). It also distinguishes itself from sibling tools like mail_create_folder or mail_search by focusing on listing folders.
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?
It explicitly says 'Call it before filing messages to learn which folders exist,' giving a concrete use case. It also explains how other tools consume folder references (by name, path, well-known name, or id), implying this tool provides that mapping—effective guidance for when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description explains the exact attempt order (RFC 8058, email, browser, none), clarifies that it deletes nothing, and describes the return method. This adds significant behavioral context not present in annotations, and does not contradict them.
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 structured with a numbered list for the method attempts, and every sentence adds value: the method order, the 'deletes nothing' note, and the parameter preference. It is detailed without being verbose.
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's complexity (multi-step unsubscription), the description covers the full behavior, the return value possibilities, and the parameter source. The output schema presumably documents the return structure, and the description fills in the behavioral nuances. Nothing essential is missing.
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?
While the schema already fully describes the id parameter (100% coverage), the description adds practical context by recommending the lastMessageId from mail_senders_summary as the source, which helps the agent pick the right value. This goes beyond the schema's generic 'Id of a representative message'.
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: unsubscribing from a mailing list, with a specific verb 'unsubscribe' and a resource 'mailing list of a message'. It distinguishes itself from sibling tools (list, search, move, delete) by focusing on unsubscription, and outlines a concrete method sequence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on when to use (for unsubscribing) and even recommends passing the lastMessageId from mail_senders_summary, which is useful guidance. However, it does not explicitly state when not to use it or name an alternative tool, so it stops short of full explicit guidance.
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?
The read-only, idempotent, non-destructive behavior is already covered by annotations, and the description adds meaningful behavioral context: newest-first ordering, compact summary output, cursor pagination, default inbox, and full-text query exclusivity. It does not mention error cases or rate limits, but those are not required given the annotation coverage.
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 compact and front-loaded; the first sentence states the core purpose and defaults, and each subsequent sentence adds a distinct useful fact (query behavior, return summary, pagination, sibling alternative). No unnecessary words or repetition.
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 an output schema is present, the description does not need to detail return fields, but it still mentions the compact summary. It covers defaults, filters, pagination, exclusivity, and sibling redirects, making it complete for an agent to invoke correctly.
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 100%, and the description adds extra semantic value beyond the schema: 'exact sender address' with an example, 'simple KQL' for query, exclusivity constraints, cursor reuse, and folder defaults. This goes well above the baseline for high schema coverage.
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 opens with a specific action and resource: 'List messages of a folder', and clarifies default sorting and filtering. It explicitly distinguishes itself from siblings by pointing to mail_get_message for full content and mail_senders_summary for a whole-mailbox-by-sender view.
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?
It states when to use the tool and when not to: use it for compact message listing/searching, use mail_get_message for full content, and prefer mail_senders_summary for whole-mailbox-by-sender. It also documents that the query filter is exclusive with the other filters, which is crucial usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the irreversible nature of permanent deletion and the recoverability of default deletion. Annotations already mark destructive and idempotent, but the description adds concrete details about the default behavior and recovery path.
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 concise sentences, each packed with essential information. No redundant words or unnecessary details.
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's complexity, it covers all key aspects: action, limits, default vs permanent behavior, recovery, and idempotency. The output schema exists but is not needed for the description to be complete.
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 descriptions cover both ids and permanent with constraints. The description reinforces these by explaining the effect of permanent and the recovery mechanism, adding value beyond 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?
Clearly states the action (delete) and the resource (messages), with a specific limit of up to 500 ids. It implicitly distinguishes from sibling tools like mail_move and mail_search.
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?
Explicitly explains the default behavior (move to Deleted Items) versus permanent deletion, and notes recovery via mail_search and mail_move. It also instructs to use permanent only when explicitly requested, providing clear usage guidance.
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

Mail-MCP MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![Mail-MCP MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/Rixtayz/Mail-MCP/badges/card.svg)](https://glama.ai/mcp/servers/Rixtayz/Mail-MCP)

Score Badge

Copy to your README.md:

[![Mail-MCP MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/Rixtayz/Mail-MCP/badges/score.svg)](https://glama.ai/mcp/servers/Rixtayz/Mail-MCP)