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.
Agent tool platforms · Arcade claims checked July 2026
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.
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".
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.
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.
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.
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.
Every row is a claim we could defend with their documentation open beside it. Where they are ahead, the row says so.
Ask what the recipient should see in the From line. The answer decides this.
"From Maria at Acme"
Delegation. Arcade, or Graph with application permissions. The agent is acting as a person.
"From Acme Support"
Dedicated identity. An address here, its own key, its own history.
Both in one product
Common. Personal-assistant features delegate; the company-facing agent writes as itself.
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.
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.
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.
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.
Keep the tool platform for the tools. When the agent needs an identity of its own rather than access to someone else's, that is what this is.
The free tier is 3,000 emails a month across three agent inboxes, no card, with receiving, threading, and search included. Enough to watch a real conversation happen before you decide.
More Agent tool platforms