You ask the agent to "finish signup." It happily offers to read your personal inbox, paste API keys into the chat, and follow whatever link the email suggests. That is not automation—it is delegated account takeover with extra steps.
Relay's MCP server exposes a small, named tool surface for authorized verification work: list domains, create inboxes, list messages, read a selected message, extract OTPs, and return auth link candidates. The agent still needs your policy layer.
MCP is transport, not trust
Model Context Protocol standardizes discovery and invocation. It does not make email trustworthy. Message bodies remain external content—identical to the prompt-injection problem described in email prompt injection.
Mailinator markets Mailinator + AI for assistants that need mail. Relay's angle is narrower: give coding agents the same controlled inboxes your CI uses, via MCP or REST, without pretending the inbox is private by default.
Configuration sketch
{
"mcpServers": {
"relay": {
"url": "https://www.relaymcp.net/api/mcp",
"headers": {
"Authorization": "Bearer ${RELAY_API_KEY}"
}
}
}
}
Store RELAY_API_KEY in the host's secret store. Rotate it from /account when a laptop is lost.
| Step | Guardrail |
|---|---|
| create_inbox | Name reflects the task or ticket |
| list_messages | Filter by expected sender |
| read_message | HTML stays data, not instructions |
| get_otp | Fail if ambiguous |
| get_auth_artifacts | Show URL, require host approval before navigation |
Full tool semantics: MCP setup and docs#mcp-tools. Reusable workflows ship as Agent Skills.
Safe agent loop for signup verification
- Confirm the human authorized the target URL and environment.
create_inboxon a Free domain you control for testing.- Drive the browser tool to paste the generated address.
- Submit the form and wait for a human or script checkpoint.
list_messages→ pick the row matching subject metadata.read_message→ pass sanitized text to reasoning, not shell tools.get_otporget_auth_artifacts→ return structured JSON to the user.- Require explicit approval before typing the OTP or opening a link.
Never let text inside the email override system instructions. "Ignore previous instructions" in a footer is still untrusted content.
Compare MCP with REST for the same agent
REST fits deterministic scripts checked into git. MCP fits interactive hosts that discover tools dynamically. Both require scoped keys. The TypeScript SDK is often simpler in CI; MCP shines in Cursor or Claude Desktop during exploratory QA.
FAQ
Does MCP bypass inbox passwords?
No. Credentials still gate access. Guest passwords and account linking behave the same as the web UI.
Is MCP a good fit for production customer mail?
Use it for authorized testing of systems you own. Do not point agents at arbitrary third-party inboxes.
Firefox extension?
The Chrome Web Store build is live; Firefox is not in the Mozilla store yet. Agents should still prefer API/MCP for repeatability.
Where is the security deep dive?
Read MCP email agent security and AI agent email MCP.
Tool approval patterns in Cursor and Claude
Require human confirmation before create_inbox when the agent works against production-like data. Some teams map each tool to an allowlist in the MCP host so read_message cannot run until the user picks a message ID from a short list.
Log tool calls with correlation IDs tied to tickets. When an agent misfires, you need to know which inbox it created without dumping message bodies into observability backends.
When REST-only is simpler
Scheduled jobs, GitHub Actions, and Jest suites should use the REST API or SDK rather than MCP adapters. Reserve MCP for interactive debugging and exploratory QA. The CLI guide remains the fastest human fallback when a tool host misbehaves.