# MCPmailer vs Arcade

Arcade solves authorized tool calling for agents acting as a user. MCPmailer gives the agent its own identity, so there is no user to act as.

Also searched as: Arcade AI alternative, agent authorization vs agent identity.

## What Arcade is

Arcade is a tool-calling platform whose distinguishing idea is authorization: agents act on behalf of a specific user, with the consent flow handled properly rather than with a shared token in an environment variable. Gmail is among its toolkits, and the security thinking is serious.

## Where Arcade is the better choice

When an agent genuinely must act as a named human, in their mailbox and under their permissions, that is the problem Arcade is built for and it is a real answer to it. Do not replace it with a dedicated address if the requirement is "send as Maria".

## Where MCPmailer differs

We take the other branch of the same question. Instead of borrowing a person's identity, the agent gets its own address on your domain with a key scoped to that mailbox. The audit trail becomes obvious and the blast radius of a bad prompt is one inbox wide, with no consent screen and no token refresh.

### Two different security models

Delegated access is least-privilege inside someone else's account. Dedicated identity is isolation by construction: the agent has nothing to over-reach into, because its own mailbox is all there is. Which is safer depends entirely on whether acting as a person is a requirement or a workaround.

### Email primitives, not generic tools

Arcade's job is authorization across a catalogue. Ours is one domain done deeply: threading on ingest, wait_for_reply, reply-first quotas, suppression enforced pre-send, contact memory, mail rules. Those are not tools a general platform would build.

### Nothing expires

Consent flows and refresh tokens are the operational tax of delegation. A scoped key does not expire on a schedule, does not need a human present, and is revoked one agent at a time when you want it gone.

## Choosing a model

Ask what the recipient should see in the From line. The answer decides this.

1. **"From Maria at Acme"** Delegation. Arcade, or Graph with application permissions. The agent is acting as a person.
2. **"From Acme Support"** Dedicated identity. An address here, its own key, its own history.
3. **Both in one product** Common. Personal-assistant features delegate; the company-facing agent writes as itself.

## Side by side (checked July 2026)

| | MCPmailer | Arcade |
| --- | --- | --- |
| Built for | Agents holding conversations. The mailbox is the product, not an endpoint bolted onto a sender. | Authorized tool calls on behalf of a user. |
| Inbox per agent | The agent has its own address and key. It never borrows a person's account. | No. Delegated access to a user's mailbox. |
| Receiving and threading | Inbound MX, parsed MIME, In-Reply-To threading. The whole conversation stays queryable. | Via the connected provider. |
| MCP server | We are the MCP server. Nothing sits between the agent and the mailbox. | Yes, with an authorization layer around tools. |
| Waiting for a reply | wait_for_reply long-polls the mailbox until the other side answers, up to five minutes per call. | Not an email primitive. |
| Human oversight | Every thread is readable in your dashboard and you can take any of them over yourself. | Authorization and call auditing. |
| Sending limits | Reply-first. Replies into an inbound thread are near-unrestricted; cold outreach is quota gated. | Inherited from the provider. |
| Your domain | Instant you.mcpmailer.email subdomain, then verify agents.yourcompany.com with a guided DNS wizard. | The user's own domain. |
| Search | Full-text search across the workspace, exposed to the agent as search_inbox. | Provider search. |
| Beyond the inbox | A shared contact book with per-contact memory, notes, an encrypted vault, and a public hostname per agent. | A tool catalogue with per-user authorization. |
| Free tier | 3,000 emails a month, 100 a day, 3 inboxes, no card. | Developer tier. |
| Content privacy | We never read message content and never train on it. Enforcement is behavioral and metadata only. | Scoped delegated access; content passes through. |

## Questions

### Which model is safer for AI agents?

A dedicated address limits a confused agent to one mailbox, and that containment is structural. Delegation is safer when the agent legitimately must act as a person, because permissions and audit follow that person. The unsafe option is a shared token in an environment variable, which both of us exist to replace.

### Can the agent still send as a person?

Not from here. Every message leaves from the agent's own address. If sending as a named human is the requirement, delegation is the right tool.

### Do you support per-end-user isolation?

Per agent, yes: an identity per agent, keys scoped to it, and other identities invisible unless access is granted. Per end user of your product, you would map users to identities yourself.

### Is a scoped API key really safer than delegated OAuth?

Neither is strictly safer; they fail differently. A leaked key exposes one mailbox and is revoked in one click. A leaked delegated token exposes a person's mail until the grant is found and pulled. Pick based on whether acting as a human is a requirement.

All comparisons: https://mcpmailer.com/vs
Docs: https://mcpmailer.com/docs.md
Pricing: https://mcpmailer.com/pricing.md