radmail-mcp
Server Details
Email OS for agents - real-inbox search, triage, commitments, and a verifiable BEC hard-stop.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4/5 across 6 of 6 tools scored.
Each tool serves a distinct purpose: drafting replies, listing commitments, showing urgent messages, searching, triaging inbox, and explaining rankings. No two tools overlap in functionality.
All tool names use a consistent verb_noun pattern (draft_reply, list_commitments, list_right_now, search, triage_inbox, why_surfaced) in snake_case, making the set predictable.
With 6 tools covering essential email management tasks (search, triage, commitments, drafts, explanations), the count is well-scoped without being excessive or sparse.
The set lacks a send operation (draft_reply explicitly cannot send), no full inbox listing (only a 'right now' lane), and no archive/delete functionality, creating notable gaps for a mail assistant.
Available Tools
6 toolsdraft_replyAInspect
Draft a reply for a thread. It returns text for a human to review — it does not and cannot send it.
| Name | Required | Description | Default |
|---|---|---|---|
| guidance | No | Optional steer for the draft. Never sent — review-only. | |
| message_id | Yes | An id from triage_inbox to draft a reply for. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description clearly states the tool does not send the reply and returns text for review. It could benefit from mentioning if any side effects exist or if it requires a specific thread context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with the key action and limitation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description notes return of text for review, which is sufficient. However, adding detail about the return format (e.g., plain text) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds context: message_id is tied to triage_inbox, and guidance is clarified as 'Never sent — review-only'. This adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool drafts a reply for a thread and returns text for human review, explicitly noting it does not send. This distinguishes it from tools that perform sending actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use after reviewing a thread from triage_inbox but does not explicitly state when to use or avoid this tool versus alternatives like search or triage_inbox.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_commitmentsAInspect
Extract the open commitments in the correspondence, both owed by you and owed to you, with who and by-when.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says 'extract', implying read-only, but lacks disclosure of side effects, permissions, or whether data is modified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 17 words, front-loaded with action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool without output schema, description clarifies output includes who and by-when, but could detail return format. Adequate given low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema, so description need not add param info. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it extracts open commitments from correspondence, specifying direction and details (who, by-when). Distinct from sibling tools like 'search' or 'list_right_now'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs siblings. No mention of prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_right_nowAInspect
Return only the 'Right Now' lane — the most recent and most important messages that genuinely can't be missed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states what is returned (the lane) but does not disclose any behavioral traits such as side effects, authentication needs, rate limits, or how 'most important' is determined. The behavior is simple enough, but the description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the key verb and resource. Every word earns its place, with no redundancy or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and zero parameters, the description is mostly complete for a simple retrieval operation. However, it could provide more context on what qualifies as 'most important' or how ordering works, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100%. The description does not need to add parameter information. It effectively states the tool's purpose without needing param details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning the 'Right Now' lane, specifying it contains the most recent and most important messages. It effectively distinguishes from siblings like 'search' or 'triage_inbox' by naming a specific lane.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The context implies it is for focusing on urgent messages, but it does not compare to siblings like 'list_commitments' or 'why_surfaced', leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchAInspect
Find a specific message by sender, subject, or content. Results come back most-relevant + newest first, and every hit says where it matched (from / subject / body) and why. On this hosted sandbox it searches the built-in demo inbox; run the radmail-mcp package with RADMAIL_API_KEY set and the same tool searches your REAL ingested inbox read-only (with from / after / before filters) via the v1 search API.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max hits to return (default 10). | |
| query | Yes | Words to find, matched against from / subject / body. Every word must appear somewhere in a message. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: results ordering (most-relevant + newest first), hit location and reason, and the read-only nature when using the real API. No annotations are provided, so the description carries the burden well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose, but the second part about environments is a bit long-winded. Still, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two modes, no output schema, no annotations), the description covers purpose, behavior, parameter usage, and environment differences adequately. It is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining that query matches against from/subject/body and every word must appear. This goes beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds a specific message by sender, subject, or content. It uses a specific verb and resource, and the function is distinct from sibling tools like draft_reply or list_commitments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the two usage contexts (sandbox vs real inbox) but does not provide explicit guidance on when to use this tool versus alternatives or when not to use it. Usage is implied but not fully guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
triage_inboxAInspect
Rank a mailbox on two axes (importance x urgency) and return what needs a human now versus what can wait or is already handled — with each thread's open commitment (the promise you owe or are owed, and whether it's overdue) surfaced inline, so the follow-through is visible on the very first call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It transparently describes the ranking axes, classification of items, and inline commitment surfacing. However, it does not disclose potential side effects (none expected), authentication needs, or rate limits, which are minor for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, lengthy sentence. While front-loaded with the action verb 'Rank', it contains flowery language ('follow-through is visible') that could be trimmed without losing meaning. It is adequately compact but not optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return values (rankings, classifications, commitments) but omits the structure format and error cases. For a zero-parameter tool, this is minimally sufficient but lacks details on edge scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so according to guidelines the baseline score is 4. The description does not need to add parameter semantics as there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: ranking the mailbox on importance and urgency, and returning items needing human attention vs. those that can wait or are handled. It also specifies the surfacing of commitments. This distinguishes it from siblings like list_commitments or list_right_now, as it focuses on triage rather than listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for initial inbox review but does not explicitly state when to use this tool versus alternatives like search or why_surfaced. No when-not or exclusion criteria are provided, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
why_surfacedAInspect
Explain in plain English why a given message was surfaced — the signals (sender, urgency, commitment) behind its rank.
| Name | Required | Description | Default |
|---|---|---|---|
| message_id | Yes | An id from triage_inbox, e.g. m_001. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, but the description accurately describes the tool as an explanatory read operation. No side effects are mentioned, which is acceptable for a simple info tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with purpose, no unnecessary words. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the tool's purpose but lacks specification of output format. However, given no output schema, the description could be more detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter described. The description adds no extra detail beyond the signals, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: to explain why a message was surfaced, listing specific signals (sender, urgency, commitment). This distinguishes it from siblings like 'search' and 'triage_inbox'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when explanation of ranking is needed) but lacks explicit when-not-to-use or comparison with other tools, though sibling names provide some context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!