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.
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 3.8/5 across 7 of 7 tools scored. Lowest: 3/5.
Each tool targets a distinct action on emails or account management. read_inbox and read_sent clearly separate incoming from outgoing, while get_email and delete_email operate on specific email IDs. wait_for_email serves a unique polling purpose, and register_email is distinctly for account creation.
All tool names follow a consistent verb_noun pattern using lowercase snake_case. Examples include delete_email, send_email, and wait_for_email. The use of read_ for list operations and get_ for retrieval is semantically appropriate and maintains a uniform style.
The set of 7 tools is well-scoped for an email management server. It covers the essential actions (register, send, read, retrieve, delete, poll) without unnecessary redundancy or bloat. The count is within the ideal range for a focused MCP server.
The tool surface covers the core email lifecycle: account creation, sending, listing (inbox/sent), fetching full content, deleting, and waiting for incoming messages. Minor gaps like attachment handling or account info retrieval are not critical for typical email workflows, so they are acceptable.
delete_emailBInspectDelete an email from your inbox by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Email ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not state whether deletion is permanent, whether the email is moved to trash, what permissions are required, or any side effects. This is a significant gap 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?
The description is a single, direct sentence with no redundant wording. It is appropriately sized for the tool's simplicity and front-loads the key verb and object.
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 having a simple schema with one well-documented parameter, the description omits essential operational context such as the permanence of deletion, return behavior, or any undo path. Given the absence of annotations, the tool is under-specified for safe invocation.
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% for the single 'id' parameter, which already describes it as 'Email ID to delete'. The description adds the phrase 'from your inbox' which provides slight scope context but does not meaningfully go beyond the schema's own documentation. Baseline 3 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?
The description clearly states the action ('Delete'), the target ('an email from your inbox'), and the method ('by ID'). This is a specific verb+resource combination that cleanly distinguishes from sibling tools like get_email or send_email.
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 is provided about when to use this tool versus alternatives such as read_inbox or send_email, nor any exclusions or prerequisites. The usage context is purely implicit in the verb 'Delete'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_emailAInspectGet the full content of an email by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Email ID from read_inbox |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It clearly indicates a read-only retrieval ('Get') with no side effects, but it does not disclose any additional behavioral details such as whether attachments are included or if the email is marked as read. For a simple getter, this is adequate but not rich.
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, front-loaded sentence that directly states the action and target. It contains no unnecessary words or repetition, earning a perfect score for conciseness.
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, no annotations), the description sufficiently conveys its core function. It does not describe the return structure, but 'full content' hints at the response. This is complete enough for a straightforward getter, though a bit more detail on return value could make it fully 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% since the only parameter 'id' has a description ('Email ID from read_inbox'). The tool description simply says 'by ID' without adding further meaning beyond the schema, so the baseline of 3 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?
The description uses a specific verb ('Get') and resource ('email') with a clear scope ('full content' by ID). It distinguishes itself from siblings like read_inbox (which likely lists emails) and read_sent, as it targets a single email's full content.
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 itself offers no explicit guidance on when to use this tool, but the parameter description ('Email ID from read_inbox') implies it should be used after retrieving an ID from read_inbox. This is implied usage rather than explicit exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_inboxAInspectList 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'List emails' clearly implies a read-only operation, and the filter options add behavioral detail. It does not explicitly state side effects, but for a list operation this is sufficient; the description adds context beyond the schema by defining the action.
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 core action and followed by optional filters. Every word earns its place, with no redundancy or filler.
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 two-parameter, read-only tool with no output schema, the description is complete. It states the resource, the action, and the filter parameters. It does not mention response format or pagination, but these are not required for a basic list operation and the description sufficiently guides invocation.
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%, as both q and from have descriptive text in the schema. The description merely restates these parameters ('keyword (q)' and 'sender (from)') without adding new meaning. Thus the baseline 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?
The description uses a specific verb ('List') and identifies the exact resource ('emails in your inbox'), clearly distinguishing it from siblings like read_sent, get_email, and send_email. The mention of 'inbox' and optional filters provides clear operational scope.
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 states the tool lists inbox emails and gives filtering options, which provides clear context for when to use it. It does not explicitly name alternatives or exclusions, but the 'inbox' specification and sibling names make the intended use obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_sentAInspectList 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states this is a list operation, implying read-only behavior, and mentions optional filters. However, it does not disclose return format, ordering, pagination, or any potential side effects, though the simplicity of the tool reduces the need.
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 sentence that front-loads the purpose and mentions filters. No wasted words, perfectly 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?
For a simple list tool with two optional filters, the description is largely complete. It states the action, resource, and filter options. It does not detail return values, but no output schema exists, so that is not required. It lacks explicit exclusions or prerequisites, but the tool's simplicity makes them unnecessary.
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 both q and to parameters having descriptions. The description merely restates 'keyword (q)' and 'recipient (to)' without adding new meaning beyond the schema, which is already explicit.
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 sent emails, distinguishing it from read_inbox (received emails) and get_email (single email retrieval). It uses a specific verb 'List' and identifies the resource (sent emails).
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 clarifies the use case (listing sent emails) and indicates optional filters, which implies when it should be used. It does not explicitly mention alternatives, but the context makes it distinct from sibling tools like read_inbox.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_emailAInspectRegister 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 ' 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a key behavior (no auth needed) and provides critical post-registration steps (api_key returned and required as a header on all future MCP calls). It does not mention potential errors or idempotency, but for a simple registration tool, this is sufficient.
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 main purpose, followed by a vital usage note. Every sentence earns its place with no filler or 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?
For a simple tool with one parameter and no output schema, the description covers the critical aspects: what it does, auth requirements, and what to do with the result. It does not explicitly state what the response contains (though 'api_key' is implied) or whether the email address uses the 'name' parameter, but the context is sufficient for correct invocation.
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 provides 100% coverage for the single parameter 'name', including its format. The description adds nothing beyond the schema, so it provides only the baseline value. It does not explicitly map 'name' to the email address, but that is implied.
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 ('Register') and the resource ('a new agent email at phobomail.com'). It is specific and naturally distinguishes itself from sibling tools like get_email or send_email, which are email operations after registration.
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 clear usage context: it emphasizes that no auth is needed for this call, and explicitly instructs to save the api_key and use it as a header on future requests. This implies this is the initial setup tool, but it does not explicitly contrast with alternatives or state conditions like 'only use once'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_emailAInspectSend 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the action and source address but does not disclose side effects, prerequisites, or failure behavior. It is not misleading, but it under-delivers for a mutating 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?
A single sentence with no wasted words. It is front-loaded with the essential action and context.
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 is adequate for a simple tool with straightforward parameters, but it omits return-value or post-condition information. Given no output schema and no annotations, more context 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?
The input schema already provides clear descriptions for all three parameters (100% coverage). The description adds no parameter-specific meaning beyond what the schema offers.
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 the specific verb 'Send' with 'email' as the resource and clarifies the source ('from your phobomail.com address'). This clearly distinguishes it from sibling tools like read_inbox or delete_email.
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 sending email but does not explicitly state when to use it over alternatives or any exclusions. Sibling names suggest context, but no direct guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wait_for_emailAInspectPoll 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) |
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. It only states the basic polling behavior but does not disclose the timeout behavior, what happens on no match, whether it is non-destructive, or whether it blocks. This is a significant gap for a polling operation with a timeout_seconds parameter.
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 only two sentences and immediately states the core action and common use case. Every word adds value, with no filler or redundant restatement of the tool name.
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 no output schema and no annotations, the description must explain what the tool returns upon success or timeout, plus any side effects. It only covers the purpose and typical use case, leaving out critical operational details like what happens when timeout_seconds elapses or how strict the matching is. This makes it incomplete for an agent to confidently invoke the 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?
The schema has 100% description coverage for its 3 parameters, so the baseline is 3. The description does not add additional meaning beyond the schema; it just says 'matching email' without detailing how q and from are used. It neither enhances nor contradicts the schema, so a neutral 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 begins with a specific verb and resource: 'Poll inbox until a matching email arrives.' It clearly distinguishes this from sibling tools like read_inbox or get_email, which are likely non-blocking retrieval operations, while this tool is explicitly a wait-for-condition 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 phrase 'Ideal for OTP and verification codes' provides clear context for when to use this tool, which helps the agent choose it over reading an inbox directly. However, it doesn't explicitly state when NOT to use it or name alternative tools, so it lacks the exclusionary guidance needed for a 5.
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!
