Gives an AI agent its own email address: create mailboxes, send and reply, read the inbox, and block until a reply arrives. Includes a draft lifecycle so a human can approve outbound mail before it sends.
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.
Average 4.6/5 across 14 of 14 tools scored.
Each tool has a clearly distinct purpose. For example, create_draft vs send_draft are separated by intent (staging vs sending), and reply_email is distinct from send_email for threading. No two tools overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_draft, list_mailboxes, send_email). The pattern is uniformly applied across all 14 tools, making it predictable for an agent.
14 tools is well-scoped for an email management server. Each tool covers a necessary operation (mailbox creation, sending, receiving, drafts, domain listing) without being overly numerous or sparse.
The tool set covers nearly all core email operations: full draft lifecycle (CRUD + send), sending new and reply emails, inbox listing, reading, and waiting for replies. A minor gap is the absence of a delete_mailbox tool, but mailboxes are persistent and deletion may be intentionally restricted.
create_draftAInspectPrepare an email as a draft without sending it. Call this when you want to stage a message for later or for a human to review before it goes out — send it afterward with send_draft. Same fields as send_email, or omit to/subject and pass reply_to_message_id to draft a threaded reply. Returns the draft id with status "draft".
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Recipient address. Omit only when passing reply_to_message_id, which supplies it. | |
| text | Yes | Plain-text body, max 50,000 characters. | |
| subject | No | Subject line. Omit only when passing reply_to_message_id, which supplies it. | |
| mailbox_id | Yes | Id of the mailbox the draft belongs to, from list_mailboxes. | |
| reply_to_message_id | No | Optional. Draft a threaded reply to this message; recipient and subject are derived from it. Cannot be changed later with update_draft. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only and not idempotent, which is consistent with creating a draft. The description adds value by explicitly stating that it does not send the email, that it returns a draft id with status 'draft', and that reply_to_message_id supplies recipient and subject. It could improve by mentioning if drafts are saved automatically or require explicit save.
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 extremely concise at three sentences, with every sentence adding unique value. It front-loads the core purpose and immediately follows with usage guidelines and parameter nuances. 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?
The description covers the main workflow (draft then send), parameter relationships, and return value. It is complete enough for a tool with no output schema and clear parameters. Minor gap: it doesn't mention what happens to the draft if the mailbox is deleted or if there are any restrictions on the text format beyond max length.
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 description coverage is 100%, so baseline is 3. The description adds significant value beyond the schema by explaining that 'to' and 'subject' can be omitted when using reply_to_message_id (which supplies them), and that reply_to_message_id cannot be changed later with update_draft. This clarifies parameter relationships that the schema alone does not convey.
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 purpose: 'Prepare an email as a draft without sending it.' It uses specific verbs ('Prepare', 'stage', 'draft') and identifies the resource (email draft). It also distinguishes itself from siblings like 'send_email' and 'send_draft' by emphasizing the non-sending nature and the subsequent send_draft step.
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 explicitly tells when to use the tool ('when you want to stage a message for later or for a human to review before it goes out') and when not to use alternatives ('send it afterward with send_draft'). It also provides guidance on using reply_to_message_id to draft a threaded reply, making the usage conditions very clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_mailboxAInspectCreate a NEW email mailbox this agent owns. Call this when list_mailboxes shows you have no suitable mailbox yet — mailboxes persist across sessions, so creating a second one for the same purpose strands mail in the first. Returns a working address immediately. Optional slug personalizes the address (agent-@...). To create the mailbox on a custom domain instead of the shared one (@yourdomain.com), pass a domain_id from list_domains — the domain must be verified.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Optional. Personalizes the address as agent-<slug>@... Lowercase letters, digits and dashes, max 41 chars. Omit for a generated address. | |
| domain_id | No | Optional. Id of a VERIFIED custom domain from list_domains, to host the mailbox at <slug>@yourdomain.com. Omit to use the shared platform domain. | |
| display_name | No | Optional. Human-readable From name shown to recipients, e.g. "Acme Support Bot". | |
| extraction_schema_id | No | Optional. Id of a JSON Schema to extract inbound mail into. Without it, messages arrive cleaned and screened but with no structured extraction. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which indicate a non-read, non-destructive write), the description discloses that mailboxes persist across sessions, that creating a duplicate strands mail in the first, and that it 'Returns a working address immediately.' These behavioral traits are critical for the agent to make informed decisions.
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?
Four concise sentences, front-loaded with the essential purpose. Every sentence adds unique value: purpose, when-to-use, return behavior, and parameter hints. No redundant or irrelevant content.
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 creation tool with 4 optional parameters and no output schema, the description covers what, when, how (with parameter options), and behavioral implications (persistence, immediate return). References to sibling tools (list_mailboxes, list_domains) provide necessary context. No gaps remain.
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 description coverage is 100%, so baseline is 3. The description adds minimal new param-specific meaning (e.g., 'agent-<slug>@...' format and domain verification requirement are already in the schema). It does not introduce any parameter semantics beyond what the schema provides.
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 begins with 'Create a NEW email mailbox this agent owns', clearly stating the action (create), resource (mailbox), and scope (owned by agent). It distinguishes from siblings like list_mailboxes and list_domains by referencing them as prerequisites, making the tool's role unambiguous.
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?
Explicit guidance: 'Call this when list_mailboxes shows you have no suitable mailbox yet' and a warning against creating duplicates ('mailboxes persist across sessions, so creating a second one for the same purpose strands mail in the first'). This provides clear when-to-use and when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_draftADiscard a draft by its id so it will never be sent. Call this when a staged or pending-approval message should be withdrawn — e.g. it is no longer needed or was created by mistake. A draft that is already sending or sent cannot be deleted.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Id of the draft to discard, from create_draft or list_drafts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true and idempotentHint=true. The description adds value by stating the effect ('so it will never be sent') and the state constraint on deletion (cannot delete if sending/sent). This is beyond what annotations provide.
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 with no wasted words. The first sentence states the purpose and effect; the second provides usage guidelines and a limitation. Every sentence earns its place.
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 simple delete tool with one required parameter, no output schema, and annotations covering destructive and idempotent behavior, the description covers purpose, when to use, when not to use, and the source of the ID. It is complete for the agent to select and invoke correctly.
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% (one parameter fully described). The description adds the helpful source hint 'from create_draft or list_drafts,' which aids the agent in understanding where to obtain the ID. This goes beyond the baseline of 3 for high coverage.
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 states 'Discard a draft by its id so it will never be sent,' which is a specific verb+resource pairing. It clearly distinguishes this tool from its sibling draft tools (create_draft, get_draft, update_draft, send_draft) by being the only deletion operation.
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 explicitly says when to use the tool ('when a staged or pending-approval message should be withdrawn') and when not to use it ('A draft that is already sending or sent cannot be deleted'). It does not explicitly name alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_draftARead one draft in full by its id: recipient, subject, body text, and current status. Call this when you need the content of a specific draft — e.g. to review what is queued for approval after list_drafts, or before editing it with update_draft.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Id of the draft to read, from create_draft or list_drafts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, establishing the tool as a safe, read-only, idempotent operation. The description adds value by enumerating the exact return fields (recipient, subject, body text, current status), which is behavioral context beyond what annotations provide. No contradictions.
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 two sentences with no wasted words. The first sentence front-loads the purpose and return fields; the second provides usage context. Every word earns its place.
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 simplicity (one parameter, no nested objects, no output schema defined), the description is complete. It explains what the tool does, when to use it, what it returns, and how the parameter is sourced. The lack of an explicit output schema is mitigated by the description listing the return fields.
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 description coverage is 100%, so the baseline is 3. The schema already describes the single 'id' parameter with a UUID format and mentions it comes from create_draft or list_drafts. The description doesn't add new syntactic or semantic details about the parameter beyond reinforcing the source, which is helpful but not additional meaning.
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 states 'Read one draft in full by its id' with a specific verb+resource and lists the exact fields returned (recipient, subject, body text, current status). It clearly distinguishes from siblings like list_drafts (which returns summaries) and update_draft (which modifies a draft).
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 provides explicit when-to-use guidance: 'Call this when you need the content of a specific draft — e.g. to review what is queued for approval after list_drafts, or before editing it with update_draft.' It names specific sibling tools (list_drafts, update_draft) and gives concrete use case examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_domainsAList the account's custom sending domains with their id, name, and verification status. Call this when you want to create a mailbox on a custom domain (pass the id of a verified domain as create_mailbox's domain_id), or to check whether a domain has finished verifying. Only status "verified" domains can host mailboxes; an empty list means only the shared platform domain is available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent. The description adds useful behavioral context beyond annotations: the exact fields returned, the significance of verification status, and the implication that this is a safe listing operation. No contradictions.
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?
Very concise: two front-loaded sentences. First sentence states the core functionality, second sentence provides usage guidance. Every sentence adds value with no redundancy.
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 zero parameters and no output schema, the description fully covers what an agent needs: what the tool returns (id, name, verification status), how to use the results (pass verified domain id to create_mailbox), and how to interpret an empty list. Complete for this simple list tool.
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 exist (schema is empty), so the baseline is 4. No additional parameter description is needed; the description focuses on the tool's purpose and usage, which 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?
Clearly states the verb 'List' and the resource 'account's custom sending domains' with specific output fields (id, name, verification status). No sibling tool overlaps, as no other tool deals with domains.
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?
Explicitly tells when to call this tool: 'when you want to create a mailbox on a custom domain' or 'to check whether a domain has finished verifying'. Also explains the condition 'only status verified domains can host mailboxes' and what an empty list means, providing clear decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_draftsAList the open drafts in a mailbox (status draft, pending_approval, or sending), newest first. Call this when you need to see messages you have staged or that are queued waiting on human approval, e.g. after a send returned status "pending_approval".
| Name | Required | Description | Default |
|---|---|---|---|
| mailbox_id | Yes | Id of the mailbox whose drafts to list, from list_mailboxes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false. The description adds specific behavioral context: it lists only drafts with specific statuses and orders them newest first. This provides useful information beyond the annotations.
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 two sentences, front-loaded with the action, and every sentence serves a purpose. 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?
Given the tool's simplicity (one parameter, no output schema, rich annotations), the description is complete. It covers purpose, ordering, status filtering, and a concrete usage scenario. No additional information seems necessary for an agent to use it correctly.
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 description coverage is 100% (the only parameter mailbox_id has a description). The tool description does not add any additional meaning to the parameter beyond what the schema already provides. 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 lists open drafts (statuses: draft, pending_approval, sending) newest first. It provides a specific verb and resource, and distinguishes from siblings like get_draft, create_draft, and list_inbox by focusing on drafts in a specific state.
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 gives explicit guidance: 'Call this when you need to see messages you have staged or that are queued waiting on human approval, e.g. after a send returned status pending_approval.' It clearly explains when to use the tool but does not mention when not to use it or enumerate alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_inboxAList recent messages in a mailbox, newest first, with comprehension status per message. Call this when checking what has arrived; use read_email for full content and extracted data.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Optional. How many messages to return, 1-100. Defaults to a small recent page. | |
| mailbox_id | Yes | Id of the mailbox to list, from list_mailboxes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and idempotentHint=true. Description adds ordering ('newest first') and the presence of 'comprehension status' – useful context beyond what annotations convey. No mention of pagination or default limit behavior, but schema covers the limit parameter. Overall good disclosure.
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, front-loaded with the core action, then usage guidance. Every word earns its place. No redundancy or fluff.
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?
No output schema exists, but the description tells the agent what kind of data to expect (recent messages with comprehension status). For a simple read-only list with two well-documented parameters, this is sufficient. Could note that results are likely truncated at a default limit, but that is in the schema.
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 description coverage is 100% and both parameters have clear descriptions. The description adds value by explaining the overall context (listing recent messages, newest first) which gives meaning to the limit and mailbox_id parameters. It does not repeat parameter details but complements them.
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?
Description clearly states the action ('List recent messages'), the resource ('mailbox'), and additional distinguishing details ('newest first, with comprehension status per message'). It explicitly contrasts with read_email, making the purpose unambiguous.
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?
Directly tells when to use ('Call this when checking what has arrived') and provides an alternative ('use read_email for full content and extracted data'). This is explicit guidance that differentiates from a key sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_mailboxesAList the mailboxes you can use, newest first, each with its id and email address. Call this when you need a mailbox_id for any other tool, or to check whether you already have a mailbox before creating one — it is usually the first call in a workflow. Returns every mailbox on the account, or just your own if your API key is scoped to a single mailbox. An empty list means you have none yet — use create_mailbox.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and idempotentHint=true, indicating safe, read-only behavior. The description adds value by disclosing additional behavioral traits: ordering ('newest first'), output structure ('each with its id and email address'), account scoping ('Returns every mailbox on the account, or just your own if your API key is scoped to a single mailbox'), and the empty list result. No contradictions or hidden behaviors are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of three sentences with no redundancy. The first sentence states the primary purpose and output. The second sentence provides usage context. The third sentence handles the edge case. Every sentence is essential and front-loaded with the most critical 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 the tool's simplicity (no parameters, no output schema, no nested objects), the description is fully complete. It tells the agent what the tool returns, how results are ordered, the scoping behavior, and what an empty result means. No additional information is needed for correct invocation or interpretation.
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 the schema coverage is 100%. The description adds meaning by hinting at the output format (id, email address) and ordering, which the schema does not cover. Since there are no parameters to explain, the description effectively conveys what the agent can expect from the tool.
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 verb ('List'), the resource ('mailboxes'), and specifies the ordering ('newest first') and output fields ('id and email address'). It explicitly distinguishes this tool from siblings like list_drafts or list_inbox by focusing on mailbox enumeration. The purpose is specific and unambiguous.
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 provides explicit guidance on when to use this tool: 'Call this when you need a mailbox_id for any other tool, or to check whether you already have a mailbox before creating one — it is usually the first call in a workflow.' It also tells the user what to do in an edge case: 'An empty list means you have none yet — use create_mailbox.' This directly addresses when to call the tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_emailARead one email in full: cleaned body, sanitization report (screened against known hidden-content patterns), classification, and data extracted to the mailbox schema. Call this when you need the content or extraction of a specific message.
| Name | Required | Description | Default |
|---|---|---|---|
| message_id | Yes | Id of the message to read, from list_inbox or wait_for_email. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and closed-world behavior. The description adds meaningful behavioral details: the body is 'cleaned', a sanitization report screens hidden-content patterns, and data is extracted to the mailbox schema. No contradictions.
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, both front-loaded with the core purpose and output details. Every sentence earns its place with zero waste.
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 single-parameter tool with full schema coverage and annotations, the description sufficiently explains the return content (body, sanitization, classification, extraction). The lack of an output schema is offset by this description, though it could optionally mention response structure.
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 well-described message_id parameter. The description adds value by specifying the origin of the ID ('from list_inbox or wait_for_email'), which aids selection even though it does not repeat schema 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 uses a specific verb ('Read one email in full') and clearly distinguishes the resource and scope. It lists the returned content (body, sanitization report, classification, extracted data) which differentiates it from sibling tools like list_inbox or get_draft that either list or operate on drafts.
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?
Explicitly states 'Call this when you need the content or extraction of a specific message,' providing clear context for when to use this tool. While it does not explicitly list alternatives or when not to use, the context is sufficient given the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reply_emailAReply to an email you received. Call this when answering an existing message — recipient, subject, and conversation threading are derived automatically from the original. Pass a client_id (any unique string you make up) and reuse the SAME client_id if you retry after an error — that guarantees the reply is sent at most once. If the mailbox requires human approval, the reply is queued as a draft and returns {draft_id, status:"pending_approval"} instead of a message id — that is NOT a failure and must NOT be retried; it is sent once a human approves it (check with list_drafts).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Plain-text reply body, max 50,000 characters. | |
| client_id | Yes | REQUIRED idempotency key — any unique string you invent for this reply. Reuse the SAME value when retrying after an error and the reply goes out at most once; a new value sends a second copy. Cannot start with "draft:". | |
| mailbox_id | Yes | Id of the mailbox the original message arrived in. | |
| reply_to_message_id | Yes | Id of the message being replied to, from list_inbox or read_email. Recipient, subject and threading are derived from it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The idempotentHint annotation is already present, but the description adds crucial details: explains how client_id ensures at-most-once delivery, specifies the pending_approval edge case and that it must not be retried, and describes the non-error response. With zero contradiction (idempotentHint true matches the description), this adds significant 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet comprehensive—three sentences covering purpose, usage, idempotency, and edge cases. Every sentence adds distinct value, and the critical info (when to use, client_id behavior, approval handling) is front-loaded. No fluff.
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 4-param tool with no output schema, the description covers all essential aspects: what the tool does, how to use it correctly, idempotency behavior, and how to handle the draft-approval case. It also references a sibling tool (list_drafts) for follow-up. Given the complexity of idempotency and approval queuing, this is very 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 value by emphasizing client_id's idempotency role and explaining that reply_to_message_id determines threading, going beyond the schema's field-level descriptions. However, it doesn't elaborate on mailbox_id beyond what the schema provides, so the extra value is moderate.
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 it replies to an email, with recipient, subject, and threading derived from the original. It distinguishes itself from siblings like send_email (which sends new messages) and send_draft (which sends a saved draft). The verb 'reply' and resource 'email' are specific and unambiguous.
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 explicitly says 'Call this when answering an existing message' and notes that alternatives like creating a draft or sending a new email are different. It also warns about the pending approval case and directs to list_drafts for checking. This provides clear when-to-use and when-not-to-retry guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_draftASend a draft you prepared, by its id. Call this when a staged draft is ready to go out. If the mailbox requires human approval, this returns 202 {draft_id, status:"pending_approval"} — the draft is queued for a human to approve, which is NOT a failure and must NOT be retried; it is sent once approved. Otherwise it sends immediately and returns the message id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Id of the draft to send, from create_draft or list_drafts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false. The description adds critical behavioral nuance: the approval queue scenario (202 pending approval) and the immediate send case, including the instruction that 202 is not a failure and must not be retried. This goes beyond the annotations to explain real-world behavior.
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 compact and front-loaded: the first sentence states the core action, the second gives the usage condition, and subsequent sentences detail the two outcomes. Every sentence adds essential information with no redundancy or fluff.
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 has one parameter with full schema coverage and annotations that indicate safety, the description completes the picture by explaining the two possible responses (immediate send vs. approval pending) and clarifying that 202 is not an error. Without an output schema, this adequately describes what the agent can expect. Minor omission: no explicit mention of error cases (e.g., draft not found), but the parameter schema's format validation partially covers that.
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 covers the single parameter exhaustively with a description that tells the agent the id comes from create_draft or list_drafts. The tool description adds 'by its id' but does not provide additional semantics beyond what the schema already conveys. Schema coverage is 100%, so baseline is 3.
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 action 'Send a draft' by its id, using a specific verb and resource. It distinguishes from sibling tools like send_email (which sends a fresh email) and create_draft (which creates a draft). The purpose is unmistakable.
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?
Explicitly says 'Call this when a staged draft is ready to go out,' providing clear when-to-use guidance. It also explains the two possible outcomes and warns not to retry on 202. Lacks an explicit statement about when not to use this tool, but the sibling context and overall clarity compensate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_emailASend a new email from one of your mailboxes. Call this when starting a NEW conversation; to answer an email you received, use reply_email instead (it threads correctly). Pass a client_id (any unique string you make up) and reuse the SAME client_id if you retry after an error — that guarantees the email is sent at most once. If the mailbox requires human approval, the send is queued as a draft and returns {draft_id, status:"pending_approval"} instead of a message id — that is NOT a failure and must NOT be retried; the email goes out once a human approves it (check with list_drafts).
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient email address. | |
| text | Yes | Plain-text body, max 50,000 characters. | |
| subject | Yes | Subject line, max 200 characters. | |
| client_id | Yes | REQUIRED idempotency key — any unique string you invent for this send. Reuse the SAME value when retrying after an error and the email goes out at most once; a new value sends a second copy. Cannot start with "draft:". | |
| mailbox_id | Yes | Id of the mailbox to send from, from list_mailboxes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare `idempotentHint: true` and `readOnlyHint: false`, but the description adds significant behavioral context beyond this: the idempotency mechanism (client_id reuse guarantees at-most-once delivery), the two possible return states (message id vs draft with pending_approval), and the rule that pending_approval is not a failure and must not be retried. There is no annotation contradiction.
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?
Three sentences, each earning its place: the first states purpose and differentiation, the second covers the idempotency key usage, the third covers the approval workflow edge case. No filler words, direct instructions for the agent.
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 compensates by describing the two possible response shapes (message id on success, {draft_id, status:'pending_approval'} when requiring approval). For a mutating tool with 5 params and complex behavior (idempotency, approval), the description covers purpose, differentiation, retry logic, error handling, and next steps – it is 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 description coverage is 100% with good descriptions for each parameter (format, constraints, domain knowledge like mailbox_id coming from list_mailboxes). The description adds value by explaining the client_id 'reuse on retry' semantics in practical terms and the 'cannot start with draft:' constraint. However, it does not describe the `to` format in detail (the schema has a regex) or `text` encoding, so it gets a 4 rather than 5.
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 starts with 'Send a new email from one of your mailboxes' which is a specific verb+resource combination. It immediately distinguishes from the sibling `reply_email` by stating when to use this tool (new conversation) vs that one (reply to existing email, handles threading correctly).
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 provides explicit when-to-use ('starting a NEW conversation') and when-not-to-use ('to answer an email you received, use reply_email instead') guidance. It also explains retry behavior with the client_id idempotency key and how to handle the pending_approval case, including directing to `list_drafts` to check approval status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_draftAEdit the to, subject, or text of a draft that has not been sent yet — omitted fields keep their current value. Call this when a draft needs changes, e.g. a human declined to approve it and you are revising it. The reply target cannot be changed (create a new draft to reply to a different message), and a draft that is already sending or sent can no longer be edited.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Id of the draft to edit, from create_draft or list_drafts. | |
| to | No | Optional. New recipient address. Omit to keep the current one. | |
| text | No | Optional. New plain-text body. Omit to keep the current one. | |
| subject | No | Optional. New subject line. Omit to keep the current one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark idempotentHint=true and destructiveHint=false. The description adds valuable behavioral context: omitted fields retain current values, the reply target is immutable, and the draft cannot be edited once sending or sent. No contradictions with annotations.
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 tightly packed sentences. Each sentence serves a purpose: first defines the action and partial-update behavior, second gives usage context and constraints. No fluff or repetition.
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 simple update tool with 100% schema coverage, the description adequately covers what can be edited, partial updates, usage context, and key limitations. It does not mention return values, but no output schema is defined, so this is acceptable. Slightly more detail on success/failure could push to 5.
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 descriptions for each parameter. The description adds extra meaning by explaining that omitted fields keep their current value, which clarifies the semantics of optional parameters beyond the schema's wording.
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 edits the to, subject, or text of a draft that has not been sent yet, using a specific verb and resource. It distinguishes from siblings like create_draft (new) and send_draft (send) by focusing on editing an existing unsent draft.
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?
Provides a concrete use case ('a human declined to approve it and you are revising it') and states limitations (cannot change reply target, cannot edit after sent). It implicitly guides when to use by noting when to create a new draft instead, but does not explicitly name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wait_for_emailABlock until a matching email arrives in a mailbox (or time out). Call this when you just sent an email and need the reply, or are expecting an inbound message — instead of polling list_inbox yourself. Returns the full message on match, or {timed_out:true}.
| Name | Required | Description | Default |
|---|---|---|---|
| mailbox_id | Yes | Id of the mailbox to watch, from list_mailboxes. | |
| from_contains | No | Optional. Only match messages whose sender address contains this substring. | |
| timeout_seconds | No | Optional. How long to wait before giving up, 1-120 seconds. On expiry returns {timed_out:true} rather than an error. | |
| subject_contains | No | Optional. Only match messages whose subject contains this substring. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and idempotent, but the description adds valuable behavioral context: it blocks execution, returns full message on match or {timed_out:true} on expiry. It does not disclose resource consumption or side effects (e.g., connection state), but given the annotations cover safety, this is a minor gap.
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 two sentences long, front-loads the core purpose ('Block until...'), then gives usage guidance and return behavior. Every sentence is informative and concise with zero redundancy.
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 that there is no output schema, the description completes the picture by describing both possible return formats. The tool has moderate complexity (blocking, multiple filters), and the description covers the key points without needing to detail trivial aspects. Minor omission: does not hint that multiple filters act as AND or OR, but this is inferred.
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 schema already has 100% description coverage for all 4 parameters. The description does not repeat parameter details, nor does it need to. It focuses on overall behavior and return format, which is appropriate. Baseline 3 is correct.
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 blocks until a matching email arrives or times out. It specifies the verb 'Block' and the resource 'matching email in mailbox', which is distinct from polling tools like list_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 explicitly says 'Call this when you just sent an email and need the reply, or are expecting an inbound message — instead of polling list_inbox yourself.' This provides clear when-to-use guidance and names an alternative (list_inbox) that should be avoided in favor of this tool.
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.
No comments yet. Be the first to start the discussion!
