PhoboMail
Server Details
PhoboMail gives AI agents their own @phobomail.com email address with zero human involvement. Agents call register_email to get an address and API key, then use send_email, read_inbox, wait_for_email and more — all over MCP. Ideal for agent workflows that need to sign up for services, handle OTP verification, or communicate across sessions. Hosted on Cloudflare.
- 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 3.4/5 across 7 of 7 tools scored.
Each tool has a clearly distinct purpose with no overlap: delete_email removes emails, get_email retrieves content, read_inbox and read_sent list emails from different folders, register_email sets up the account, send_email sends messages, and wait_for_email polls for incoming emails. The descriptions make it easy to differentiate between listing, retrieving, sending, deleting, and waiting for emails.
All tool names follow a consistent verb_noun pattern using snake_case: delete_email, get_email, read_inbox, read_sent, register_email, send_email, and wait_for_email. The verbs (delete, get, read, register, send, wait) are clear and appropriately matched to their actions, creating a predictable and readable naming convention throughout.
With 7 tools, this server is well-scoped for email management. It covers essential operations like reading, sending, deleting, and waiting for emails, plus account registration. Each tool serves a distinct function without redundancy, making the count appropriate for handling email workflows efficiently.
The tool set provides comprehensive coverage for core email operations, including CRUD-like actions (create via send_email, read via get_email/read_inbox/read_sent, delete via delete_email) and specialized functions like registration and polling. A minor gap is the lack of an update tool (e.g., to mark emails as read or move them), but agents can work around this with the existing tools for most use cases.
Available Tools
7 toolsdelete_emailBInspect
Delete an email from your inbox by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Email ID to delete |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Delete' implies destruction, the description fails to specify whether this is permanent, if items move to trash first, whether recovery is possible, or required permissions—critical gaps for a destructive operation.
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 efficient sentence with zero waste. The action verb leads the description, immediately communicating the tool's function without extraneous 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 simple single-parameter structure and 100% schema coverage, the description is minimally adequate. However, for a destructive operation without annotations or output schema, it lacks necessary safety context about consequences or return behavior.
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?
With 100% schema description coverage, the schema already fully documents the 'id' parameter. The description mentions 'by ID' which aligns with the parameter, but adds no additional semantic context such as ID format, examples, or constraints 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 provides a specific verb (Delete), resource (email), and scope (from your inbox by ID). It distinguishes this from sibling read/search tools by clarifying the operation targets the inbox specifically, though it doesn't explicitly contrast with the 'get_email' or 'send_email' siblings.
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 provided on when to use this tool versus alternatives (e.g., when to delete vs. archive), no prerequisites mentioned, and no warnings about the permanence of the operation despite it being a destructive action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_emailCInspect
Get the full content of an email by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Email ID from read_inbox |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal detail. It does not clarify what constitutes 'full content' (headers, body, attachments?), mention error handling for invalid IDs, disclose rate limits, or confirm the read-only nature of the operation.
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 single-sentence description is appropriately brief and front-loaded with the action verb. However, it borders on under-specification given the lack of output schema and annotations; an additional sentence explaining return value characteristics would improve utility without sacrificing clarity.
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 single-parameter retrieval tool, the description is minimally adequate. However, given the absence of an output schema, it should ideally characterize the return value (e.g., whether it includes metadata, HTML vs. text bodies, or attachments). The description leaves significant ambiguity about the 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?
The input schema has 100% description coverage ('Email ID from read_inbox'), establishing a baseline of 3. The description mentions 'by ID' which aligns with the parameter, but adds no additional semantic context—such as ID format, validation rules, or sourcing requirements—beyond what the schema already 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 uses a specific verb ('Get') and resource ('full content of an email') with clear scope ('by ID'). It effectively distinguishes this single-item retrieval tool from sibling listing tools like 'read_inbox' and 'read_sent' through the 'by ID' qualifier, though it could explicitly name the siblings for stronger differentiation.
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 no explicit guidance on when to use this tool versus alternatives like 'read_inbox' or 'wait_for_email'. While the parameter schema implies this follows a 'read_inbox' call ('Email ID from read_inbox'), the description text itself lacks when-to-use or prerequisite guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_inboxBInspect
List emails in your inbox. Optionally filter by keyword (q) or sender (from).
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Search keyword (subject + body) | |
| from | No | Filter by sender email |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to mention critical execution details such as pagination behavior, result limits, sort order, whether emails are marked as read, or any rate limiting. It only covers the filtering capability.
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 two efficient sentences with zero redundancy. It is front-loaded with the core purpose ('List emails in your inbox') before detailing optional modifiers, making it easy to scan and understand immediately.
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 low complexity (2 optional parameters, no nested objects, no output schema), the description provides minimal viable coverage of inputs. However, without an output schema or annotations, it omits expected behavioral context like result set size or pagination that would be necessary for robust agent operation.
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?
With 100% schema description coverage, the schema already documents that 'q' is a search keyword and 'from' is a sender filter. The description maps the parameter names to these concepts ('keyword (q)' and 'sender (from)'), adding minimal semantic value beyond the schema itself, meeting the baseline for high-coverage schemas.
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 ('List') and resource ('emails in your inbox') that clearly scopes the tool to inbox retrieval. It implicitly distinguishes from siblings like 'read_sent' (inbox vs sent) and 'get_email' (list vs single retrieval) through the resource naming, though it doesn't explicitly contrast with them.
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?
While it mentions optional filters, the description provides no guidance on when to use this tool versus alternatives like 'read_sent' (for sent items) or 'wait_for_email' (for blocking until arrival). There are no explicit when/when-not conditions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_sentBInspect
List emails you have sent. Optionally filter by keyword (q) or recipient (to).
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Search keyword (subject + body) | |
| to | No | Filter by recipient email |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'List' implies a read operation, the description does not explicitly state it is safe/non-destructive, describe the return format (list vs single object), mention pagination behavior, or note whether emails are marked as read when accessed.
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 two efficient sentences with zero waste. The primary purpose ('List emails you have sent') is front-loaded, followed by optional parameters, making it easy to scan and comprehend immediately.
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 2-parameter tool with 100% schema coverage, the description is minimally adequate. However, given the lack of output schema and zero annotations, it should ideally describe the return structure (e.g., 'returns array of sent emails') or mention read-only safety characteristics to be 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?
With 100% schema description coverage, the baseline is 3. The description confirms parameters are optional (matching the 0 required parameters) and maps 'q' and 'to' to human-readable concepts, but does not add syntax details, format examples, or constraints beyond what the schema already 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 clearly states the tool 'List emails you have sent' with specific verb and resource. It implicitly distinguishes from sibling read_inbox by focusing on 'sent' rather than received mail, but does not explicitly contrast with get_email or other siblings in the text.
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 mentions optional filtering capabilities but provides no explicit guidance on when to use this tool versus alternatives like get_email (which likely retrieves specific emails) or read_inbox. No prerequisites or exclusion criteria are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_emailAInspect
Register a new agent email at phobomail.com. No auth needed. After registering, save the api_key and pass it as an HTTP header 'Authorization: Bearer <api_key>' on ALL future MCP requests — not as a tool argument.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Agent name: 3-32 chars, lowercase letters, numbers, hyphens only |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. Discloses side effects (creates email account), output behavior (returns api_key), and stateful auth pattern for subsequent requests. Minor gap on error cases or idempotency, but covers the critical behavioral contract.
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 zero waste: first establishes purpose and auth requirements, second provides essential post-call handling instructions. Front-loaded with action verb and appropriately sized.
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?
Despite missing output schema, description adequately explains the key return value (api_key) and its usage. Covers the setup workflow completely, though could explicitly state the generated email address format.
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?
Input schema has 100% description coverage for the 'name' parameter. Description does not add parameter-specific semantics, but baseline 3 is appropriate since schema documentation is complete.
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?
Specific verb 'Register' + specific resource 'agent email at phobomail.com'. Clearly distinguishes from operational siblings (send_email, read_inbox, etc.) by indicating this is account creation/setup rather than message handling.
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 'No auth needed' for this call, then provides critical workflow guidance: save the returned api_key and pass it as HTTP header 'Authorization: Bearer <api_key>' on future requests. Explicitly warns 'not as a tool argument', preventing incorrect usage patterns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_emailBInspect
Send an email from your phobomail.com address.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient email address | |
| text | Yes | Email body (plain text) | |
| subject | Yes | Email subject |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden for a write operation. Mentions sender identity (phobomail.com) but omits critical behavioral details: delivery guarantees, idempotency, rate limits, side effects (e.g., creates sent item), or error conditions.
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 efficient sentence of seven words. Front-loaded with the core action, zero waste, appropriate length for the tool's simplicity.
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?
Adequate for a 3-parameter tool with complete schema coverage, but gaps remain regarding prerequisites (registration requirement) and success behavior (no output schema to indicate return values). Minimum viable but not exemplary.
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?
Input schema has 100% description coverage (to, subject, text all documented). Description does not add parameter-specific semantics, but with complete schema coverage, the baseline score of 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?
Clear verb 'Send' and resource 'email' with specific scope 'from your phobomail.com address'. Distinguishes from siblings implicitly through action verb (vs read/delete/get/register/wait), though it does not explicitly contrast with register_email which may be a prerequisite.
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 guidance or prerequisites mentioned. Fails to indicate that register_email may need to be called first to have a phobomail.com address, or when to use this vs wait_for_email for bidirectional communication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wait_for_emailAInspect
Poll inbox until a matching email arrives. Ideal for OTP and verification codes.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Keyword to match in subject or body (e.g. 'verify', 'code') | |
| from | No | Expected sender address | |
| timeout_seconds | No | Max seconds to wait (default 60) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It successfully discloses the polling mechanism and blocking behavior ('Poll... until'), but fails to specify timeout behavior (what happens when timeout_seconds elapses?) or return value format. It also does not clarify if polling marks emails as read or has other side effects.
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 zero waste. First sentence establishes mechanism and behavior; second establishes use case. Every word earns its place and critical information is front-loaded.
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?
Adequate for a polling tool with well-documented parameters, but gaps remain. Without an output schema, the description should ideally indicate what is returned upon success (the email content? metadata?) versus timeout failure. The behavioral contract (blocking vs. immediate return) is clear but return values are unspecified.
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 the schema fully documents all three parameters (q, from, timeout_seconds). The description implies their use ('matching email') but does not add semantic detail beyond what the schema already provides (e.g., no format guidance for 'from' or examples for 'q'). 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 uses specific verb 'Poll' with resource 'inbox' and clearly states the blocking nature ('until a matching email arrives'). It distinguishes itself from siblings like read_inbox and get_email by emphasizing the polling/waiting behavior rather than immediate retrieval.
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 clear context with 'Ideal for OTP and verification codes,' indicating when to use this tool (asynchronous waiting scenarios). However, it lacks explicit exclusions or named alternatives (e.g., does not state 'use read_inbox instead if checking existing messages').
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!