Disposable, receive-only email inboxes for AI agents. Create an address, wait for the verification email, and get the one-time code or magic link back as structured fields. Long-polling wait_for_email with sender and subject filters, attachments, sanitised HTML, and restore for later password resets. OAuth 2.1, hosted in the EU, cannot send email.
Scored across 9 tools
Each tool targets a distinct resource and action: mailbox lifecycle (create/delete/restore/list), email access (list/read/wait), account info, and deleted-mailbox search. wait_for_email and read_email both return email content but are clearly differentiated by long-poll versus single-read purpose. No overlapping or ambiguous tools.
All tool names follow a consistent snake_case verb_noun pattern (create_mailbox, delete_mailbox, get_account, list_emails, etc.). Minor variation between get_ and list_ is still predictable and readable. No mixed conventions.
Nine tools is well-scoped for a disposable email service, covering the full mailbox and email lifecycle without bloat. Each tool earns its place.
The set covers create, delete, restore, list, and search for mailboxes, plus list, read, and wait for emails, and account/usage info. No critical gaps for the disposable inbox domain; minor missing operations like per-email deletion are not essential here.
Create a new disposable inbox with a random readable address (e.g. kavor-otter-4821@domain; the first part is fixed for your account). Your plan limits how many mailboxes can be active at once; delete one to free a slot. Domains: poofy.uk (permanent), poofbox.shop (rotating), poofbox.online (rotating), poofbox.site (rotating), poofbox.space (rotating), poofbox.store (rotating).
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Mail domain. Defaults to a random rotating domain. Pass a permanent domain when the address must keep working long term. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a non-read-only, non-destructive, non-idempotent, closed-world write. The description adds behavioral context the annotations cannot carry: the account-level plan cap on active mailboxes and the permanent-vs-rotating semantics of each domain. It does not note whether repeated calls are cheap or whether domain rotation is per-request.
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?
Front-loads the purpose, then the quota constraint, then the domain list. The domain enumeration is long but earns its space because the values are not expressed as a schema enum. No filler sentences.
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?
With no output schema, the description partially compensates by showing the address format that results from a successful call, plus the domain trade-offs. It does not state what the response body contains (e.g. the mailbox id needed for later read/delete calls), which a for a creator tool would be useful.
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 baseline is 3, but the description goes further by enumerating the concrete domain values and labeling which are permanent versus rotating — information absent from the schema (no enum present). This meaningfully informs domain selection.
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?
States a specific verb and resource ('Create a new disposable inbox') and immediately describes the artifact it produces, including the address shape. An agent can distinguish it from list_mailboxes, delete_mailbox, and restore_mailbox without opening any schema.
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?
Gives real usage context: plan-limited concurrent mailboxes and the advice to delete one to free a slot, which explicitly routes to the delete_mailbox sibling. It stops short of saying when to prefer restore_mailbox over creating a fresh inbox, so it is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a mailbox and all of its emails and attachments. Nobody else can ever get the address; restore_mailbox can bring it back (empty) later. No confirmation step.
| Name | Required | Description | Default |
|---|---|---|---|
| mailbox | Yes | Mailbox id (mbx_…) or full email address. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and non-idempotent, so the safety profile is known; the description goes further by specifying that all emails and attachments are destroyed, that the address can never be re-obtained by others, that restoration yields an empty mailbox, and that no confirmation prompt occurs. That is materially more than the annotations convey.
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 short sentences, front-loaded with the destructive action, then recoverability, then the no-confirmation warning. Every sentence carries decision-relevant information with no 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 single-parameter destructive tool with no output schema, the description covers what is destroyed, whether it is recoverable, and the lack of a confirmation gate — the exact facts an agent needs before invoking it. Annotations handle the safety hints.
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 the single "mailbox" parameter is fully documented in the schema (id or full email address). The description adds no syntax or format detail beyond it, so the 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?
States a specific verb and resource ("Permanently delete a mailbox") plus the blast radius ("all of its emails and attachments"), which immediately separates it from siblings like restore_mailbox and search_deleted_mailboxes. An agent can identify the operation without opening the schema.
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?
It names the recovery counterpart ("restore_mailbox can bring it back (empty) later") and flags that there is "No confirmation step," which tells the agent this executes immediately. It does not give an explicit when-to-prefer-this-over-alternatives rule, but the context is clear enough for routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Your plan, limits and current usage, the available mail domains, and your address prefix (every address you create starts with it; only those addresses can be restored). Also shows whether a bigger plan is available and where the user can upgrade.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. Beyond that, the description discloses the payload contents (plan, limits, usage, domains, prefix, upgrade path) and the non-obvious rule that only addresses sharing your prefix can be restored. It stops short of stating auth requirements or pagination/format, but for a no-parameter read this is solid added value.
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 primary payload contents are front-loaded in the first sentence, with supplementary upgrade info trailing. The parenthetical about the address prefix is a mild interruption, and the second sentence is somewhat expendable, but nothing is redundant enough to hurt.
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?
With no output schema, the description carries the return-value burden and does so reasonably, enumerating the main fields. Terms like 'current usage' and 'limits' remain imprecise (which metrics, what units), which is the main gap for a payload the agent must interpret.
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 takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4. No parameter-level detail is needed or missing.
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 names the resource (the account) and enumerates the specific content returned: plan, limits, current usage, available mail domains, address prefix, and upgrade availability. That is well beyond a tautology. It does not explicitly contrast itself with siblings like list_mailboxes, though the account-scoped content makes the distinction inferable.
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?
There is no explicit statement of when to call this versus alternatives; usage is only implied by the content it returns. It does contain an actionable domain rule — the address prefix governs what can be restored — which points toward restore_mailbox, but that is context rather than call guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List emails in a mailbox, newest first, with any detected verification codes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max emails to return (default 20). | |
| mailbox | Yes | Mailbox id (mbx_…) or full email address. | |
| unread_only | No | Only unread emails. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds value beyond that by disclosing sort order ('newest first') and a derived output feature ('detected verification codes') that the agent would not otherwise know to expect. It does not mention pagination or default-limit behavior, so it is not fully exhaustive.
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 zero filler. The resource and scope are front-loaded, and the two distinguishing modifiers (ordering, verification codes) follow 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 read-only list tool with full annotation coverage, a complete input schema, and no output schema, this covers what an agent needs to call it and know roughly what comes back. The one gap is routing context versus read_email and wait_for_email, which matters given the sibling set.
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 mailbox, limit, and unread_only are all documented in the schema itself. The description adds no syntax, format, or default information beyond that, so the 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?
States a specific verb and resource ('List emails in a mailbox') plus two distinguishing traits: newest-first ordering and surfacing of detected verification codes. It does not explicitly disambiguate from siblings like read_email or wait_for_email, which is the only thing keeping it off a 5.
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?
Usage is implied by 'list emails in a mailbox' — an agent can infer this is the bulk-listing call. However, no sibling is named as an alternative, and there is no guidance on when to prefer read_email (single message) or wait_for_email (blocking on arrival) over this list call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your active mailboxes with email and unread counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds real context beyond that: it limits results to 'active' mailboxes (a scoping constraint not in the schema or annotations) and discloses the returned fields. It does not mention pagination or result limits.
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 front-loaded sentence with no filler. Every clause (list, active, email/unread counts) carries 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?
For a zero-parameter read tool with full annotation coverage, the description supplies the essentials: what is listed, which subset, and what comes back. Only pagination/ordering behavior is unaddressed, which is a minor gap given there is no output 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?
The tool takes zero parameters, so the schema has nothing to explain and the baseline is 4. The description correctly implies a no-argument, account-scoped call rather than inviting filter arguments.
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?
States a specific verb and resource ('List your active mailboxes') and adds scope ('active') plus payload ('email and unread counts'). It is clearly distinguishable from the mutation siblings (create_mailbox, delete_mailbox, restore_mailbox), though it does not explicitly name an alternative.
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?
Usage is only implied — an agent can infer it should call this to enumerate mailboxes, and the word 'active' hints that deleted mailboxes require the search_deleted_mailboxes sibling. But there is no explicit when-to-use statement, no prerequisites, and no named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one email: sender, subject, text (and optionally sanitised HTML), extracted verification codes, ranked links and attachments. Marks it read.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Body format to include (default text). | |
| email_id | Yes | Email id (eml_…). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=false, an agent would otherwise be puzzled why a 'read' tool is flagged as a mutation; the description resolves this by stating 'Marks it read.' It also discloses the enriched return payload (verification codes, ranked links), which matters since there is no output schema. Missing only edge-case behaviour such as what happens when the id is unknown.
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 zero waste: the action and target lead, the payload inventory follows, and the side effect is placed last where it reads as a caveat. Nothing is padded or repeated from the schema.
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 two-parameter reader with no output schema, the description covers the return shape, the optional format choice, and the read-marking side effect. It stops short of error/not-found behaviour and any auth or rate-limit context, which are the only notable gaps.
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 both parameters are already documented in the schema, including the format enum. The description's 'optionally sanitised HTML' echoes the format parameter but adds no format syntax or default detail beyond it, so 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?
States a specific verb and resource ('Read one email') and enumerates exactly what is returned (sender, subject, text, HTML, verification codes, ranked links, attachments). That content scope clearly separates it from the sibling list_emails/wait_for_email tools, which cannot return a single fully-parsed message.
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?
Usage is only implied: the required email_id signals 'use when you already have a message id'. There is no explicit when-to-use, no when-not-to-use, and no pointer to sibling tools such as list_emails for discovery or search for locating an id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bring back an address you created earlier and deleted, e.g. to receive a password reset for an account you signed up with. Find it with search_deleted_mailboxes. It comes back empty (old emails are gone). Only your own addresses on domains still in service can be restored. Counts as a new mailbox for your limits. Returns a new mailbox id (mbx_…); the old id stays invalid, so use the returned id or the address.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | The full address, e.g. kavor-otter-4821@domain. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations: discloses that restored mailboxes are empty, that only own addresses on in-service domains qualify, that it consumes a new mailbox slot against limits, and that the old id is permanently invalidated in favor of the returned id. These are exactly the mutation side effects an agent needs and none are contradicted by 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?
Five short sentences, front-loaded with purpose, then discovery route, then caveats, then return-value contract. Every sentence carries distinct information with no padding.
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, and the description compensates by specifying the return value (a new mbx_ id) and the id-invalidation rule. Combined with the limit-counting and emptiness caveats, an agent has everything needed to call this 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% with a format example for address, so the baseline is 3. The description adds real semantic constraints on the value beyond the schema: it must be an address you own and on a domain still in service.
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+resource with scope: 'Bring back an address you created earlier and deleted' clearly distinguishes restore from create_mailbox and delete_mailbox. The example use case (receiving a password reset) further pins down intent.
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 routes the agent to search_deleted_mailboxes to locate the target, and warns that the mailbox comes back empty so the agent doesn't expect old emails. There is no explicit when-not-to-use or statement about preconditions being required beyond the 'own domain still in service' constraint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the addresses you created and later deleted, newest first. Use it to find an address to bring back with restore_mailbox (e.g. the one used to sign up for a service that now sends a password reset). Each entry says whether it can still be restored.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Part of the address, e.g. "otter" or "poofy.uk". Omit to list the most recent ones. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, idempotent), so the description's job is to add operational detail. It discloses result ordering ('newest first') and that each entry reports restorability, which is genuinely useful since there is no output schema. It does not mention result limits or pagination.
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 short sentences, no filler, with purpose and ordering front-loaded ahead of the usage example. 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 read-only search with no output schema, the description supplies the ordering and the restorability signal an agent needs to act on results. It stops short of noting result caps or whether the search spans the whole account, which are the only remaining unknowns.
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?
There is a single optional 'query' parameter, and the schema description coverage is 100% including examples and the omit-to-list behavior. The description adds no parameter detail beyond the schema, so the 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?
States a specific verb and resource ('Search the addresses you created and later deleted') plus a result ordering ('newest first'). This cleanly separates it from list_mailboxes, which presumably covers active mailboxes, without the agent needing to open either schema.
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?
Gives explicit usage context and names the downstream tool ('find an address to bring back with restore_mailbox') with a concrete example scenario. It lacks an explicit inverse exclusion (e.g. 'for active addresses use list_mailboxes'), so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait until a new email arrives in the mailbox (long-poll), then return it like read_email, including extracted codes and links. Returns {"timed_out": true} if nothing matching arrives in time; just call it again. By default only emails received after this call started count (or since the mailbox was created, if that was under 2 minutes ago); pass "after" (an email id or ISO time) to include earlier ones or skip ones you handled.
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | Only emails received after this email id (eml_…) or ISO 8601 time. Default: when this call started, or when the mailbox was created if that was under 2 minutes ago. | |
| mailbox | Yes | Mailbox id (mbx_…) or full email address. | |
| from_contains | No | Case-insensitive substring the sender name or address must contain. | |
| timeout_seconds | No | How long to wait (default 30, max 120). | |
| subject_contains | No | Case-insensitive substring the subject must contain. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses non-obvious behavior the annotations do not: the {"timed_out": true} return shape, the retry pattern, and the default lower-bound rule (call start, or mailbox creation if under 2 minutes ago) that governs which emails count. It does not reconcile the odd readOnlyHint=false annotation for what reads like a non-mutating wait, leaving a small ambiguity about 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?
Front-loads the core behavior, then the failure mode and retry advice, then the filtering caveat — every sentence carries information. The nested parenthetical about the 2-minute mailbox-creation rule is slightly dense but justified by non-obvious default semantics.
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?
With no output schema, the description still explains the return value (email like read_email plus extracted codes and links) and the timeout case, and the schema covers all parameters. An agent has everything needed to call it, interpret the result, and retry 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%, so all five parameters are already documented with defaults and bounds. The description restates the 'after' semantics and the default time window, adding narrative context but no syntax or format detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Wait until a new email arrives in the mailbox (long-poll)') plus the return contract ('return it like read_email, including extracted codes and links'). An agent can distinguish this from read_email and list_emails immediately: it blocks until arrival rather than reading what already exists.
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?
Gives clear operational context: it long-polls, returns a timed-out sentinel, and should simply be called again on timeout, plus guidance on when to pass 'after' to include earlier mail or skip already-handled messages. It does not explicitly say when to prefer read_email or list_emails instead, so routing is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_mailboxdelete_mailboxget_accountlist_emailslist_mailboxesread_emailrestore_mailboxsearch_deleted_mailboxeswait_for_emailDisposable email inboxes for AI agents: create an address, wait for mail, read OTP codes and links.
Receive-only temporary email addresses for AI agents: create an inbox, wait for an email, read it.
Disposable email inboxes for AI agents — read messages and verification codes.
Email for AI agents you can trust: disposable inboxes, verification codes, checked mail, held sends.
Add one secure layer between your agents and this server.
