MailSlurp

@MailSlurp create a new inbox called 'support-test' and show me its email address so I can use it for integration testing

Created inbox 'support-test' with address `7f3a9b2c@mailslurp.net` (UUID: 7f3a9b2c-4d1e-4a8f-9c3b-2e5f8a1d6c9b). This is an HTTP inbox that can send and receive email. The address is live and ready to accept messages. You can reference this inbox by UUID in subsequent commands to check for received mail or send outbound messages.

MailSlurp generates random email addresses by default unless you've configured custom domains. HTTP inboxes support both send and receive; if you need receive-only behavior, specify SMTP type at creation. Inboxes persist until explicitly deleted, so remember to clean up test inboxes to avoid hitting account quotas.

@MailSlurp check the 'support-test' inbox for any emails received in the last hour and summarize the senders and subject lines

Inbox `7f3a9b2c@mailslurp.net` received 3 emails in the last hour: (1) from `user@example.com`, subject 'Password reset request' at 14:23 UTC; (2) from `noreply@service.io`, subject 'Your verification code is 482910' at 14:31 UTC; (3) from `alerts@monitor.app`, subject 'Server health check passed' at 14:47 UTC. All emails are unread and available for full retrieval by UUID.

This example demonstrates polling an inbox for received mail, a common pattern in end-to-end testing workflows. The Get Email tool can hydrate full content including parsed headers and attachments, but fetching may mark messages as read. If your tests depend on unread state, coordinate polling carefully or use separate inboxes per test case.

@MailSlurp pull the full content of the verification code email from 'support-test' and extract the six-digit code so I can complete the signup flow

Retrieved email from `noreply@service.io` (UUID: a1b2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d). Body excerpt: 'Your verification code is **482910**. This code expires in 10 minutes.' Extracted code: `482910`. The email was sent at 14:31:22 UTC and contains no attachments. This message is now marked as read in the MailSlurp inbox.

This workflow pairs MailSlurp's email retrieval with AI parsing to automate verification flows in integration tests. Be aware that fetching hydrated email content marks it as read, which may affect test isolation if multiple processes poll the same inbox. For high-volume testing, consider creating ephemeral inboxes per test run and deleting them afterward to stay within account quotas.

When MailSlurp beats manual QA for onboarding emails

A 6-person SaaS team ships a new user onboarding flow every two weeks and needs to verify that welcome emails, verification links, and password resets land correctly across Gmail, Outlook, and custom domains. MailSlurp wins here because you can spin up a fresh inbox per test run, fetch the email by UUID, parse the verification token from the body, and tear down the inbox—all in one Switchy workflow. The create-inbox and get-email tools handle 90% of the work. The threshold: if you're only testing one or two flows per quarter, a shared Gmail account is cheaper. But if your team runs regression suites or tests localization variants, MailSlurp's programmatic inbox lifecycle pays for itself in saved QA hours. Use this MCP when your onboarding emails are mission-critical and you need proof they work before each release.

Why MailSlurp isn't the right call for inbound support queues

A 3-person support team receives 40 customer emails daily and wants to route them into Linear or Notion based on subject-line keywords. MailSlurp can technically do this—create an inbox, poll for new emails, parse headers—but it's the wrong tool. The MCP has no webhook or real-time notification primitives, so you'd be polling the list-emails endpoint every few minutes and burning API quota. More importantly, MailSlurp inboxes are ephemeral by design; they're built for testing and automation, not long-lived support addresses. If you need a stable support@yourcompany.com that forwards to Switchy for triage, use a traditional email provider with forwarding rules or a dedicated helpdesk MCP. Save MailSlurp for scenarios where you control the inbox lifecycle and need programmatic access to transient addresses.

When MailSlurp solves the 'did the webhook fire' problem

A 4-person eng team integrates with a third-party payments API that sends transaction receipts and dispute notifications via email webhook. The API docs are thin, the staging environment is flaky, and the team needs to capture real email payloads to debug parsing logic. MailSlurp is the right call: create a dedicated inbox for the staging webhook URL, configure the partner to send notifications there, then use get-email to pull the raw headers and body into Switchy for inspection. The delete-inbox tool lets you reset state between test runs. This works because the inbox is short-lived and you control both ends of the flow. The trade-off: MailSlurp's 14 tools include contact-group and domain management that you won't touch for this scenario, so you're paying for scope you don't need. But if webhook email debugging is a monthly task, the MCP is faster than forwarding rules and manual Gmail searches.