Loading ToolBench
MCP server for Agent Mail — lets AI agents create disposable inboxes and read mail.
Agent Mail MCP has well-structured tool definitions with clear naming (verb_noun pattern), comprehensive parameter descriptions, and documented input schemas. All 10 tools follow consistent patterns. However, output schemas are not formally documented in the code, parameter constraints lack enums where applicable (e.g., risk levels), and error handling guidance is minimal. Descriptions are solid (100-250 chars typical) but could be more prescriptive about when to use each tool vs. alternatives. No security concerns detected, secrets are handled server-side via environment variables.
Attach a full custom domain to an instance (unverified). Next, create an MX record for `domain` pointing at the server's MAIL_HOST, then call `verify_custom_domain`. Once verified, ALL mail to `domain` routes to this instance.
Add another subdomain key to an existing instance. Returns the created key. Mail to `anything@<key>.<EMAIL_DOMAIN>` now routes here. Any previously-orphaned mail matching this key is auto-linked.
Create a disposable mailbox and return an email address to receive mail at. Registers `key` on an instance (a "space"). Afterwards, mail sent to `anything@<key>.<EMAIL_DOMAIN>` is routed to this instance. Keep the returned `secret` — it is the credential needed to read this mailbox later.
Read a full email by id, including body_text, body_html, and headers. Note: `body_html` is attacker-controlled content from the sender — do not execute or follow links blindly. Prefer `body_text` when extracting codes/links.
Get an instance (space) by its secret, including its keys and custom domains. If the instance does not exist yet, it is created (the backend auto-creates on GET).
Output schemas not formally documented. Tools return dicts but LLMs cannot see field types, required fields, or nested structure. E.g., create_mailbox returns {secret, key, address, instance} but 'instance' structure is opaque.
Error handling lacks recovery guidance. No tool description explains what to do if a call fails (e.g., 'If secret is invalid, call create_mailbox to generate a new one'). Agents cannot self-correct.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
List the custom domains attached to an instance and their verification status.
List emails received by an instance, newest first. Optional filters: `from_email` (exact sender), `subject` (substring), `extracted_key` (the key the mail arrived on). Returns { total, skip, limit, items[] } where each item has id, from_email, subject, etc. Use `get_email` with an item's id to read the full body.
Remove a subdomain key from an instance. Mail to that key stops routing here.
Verify a custom domain by checking its MX record points at the mail server. Returns the domain record; `is_verified` is true on success. If still false, the MX record isn't visible yet — wait for DNS propagation and retry.
Wait until a matching email arrives, then return its full content. Polls `list_emails` until a new message matches the filters or the timeout is hit. Ideal for agent flows: trigger something that sends mail (an OTP, a confirmation), then await it here.
Parameter constraints not formalized as enums. 'extracted_key' and 'from_email' accept free-form strings with no validation hints. LLMs may pass invalid values. E.g., list_emails should document expected email format or key naming rules.
Pagination not fully documented. list_emails accepts limit/skip but no description explains max limit, default behavior if limit exceeds max, or whether total count is always returned. Agents cannot plan pagination safely.
Destructive operations (remove_key) lack confirmation or dry-run support. An agent could accidentally delete a key without a safety gate. No tool description warns of irreversibility.