Email an agent can operate safely
Sendly is email an AI agent can operate safely: a remote MCP server, permissions you tick yourself, and irreversible actions never granted by default.
Last updated 2026-09-04
The problem with giving an agent your email account
An agent that can read your contacts is useful. An agent that can mail all of them is a liability, and most integrations do not distinguish between the two — you hand over an API key, and the key can do whatever the key can do.
Email makes that worse than most surfaces, because the damaging actions are the ones you cannot take back. A sent campaign is in inboxes. A removed suppression entry means somebody who asked you to stop gets mailed again. There is no undo button in the dashboard for either, because there is no undo in the medium.
So Sendly's agent access is built around one rule: the actions that cannot be undone are never granted by default. They appear on the consent screen unchecked, each with a plain sentence naming the consequence, and you tick them yourself or you do not.
How agents connect
Sendly runs a remote Model Context Protocol server at https://app.sendly.now/api/mcp, over Streamable HTTP. Any MCP-capable client can use it — Claude Code, Claude on web and desktop as a custom connector, or anything else that speaks the protocol.
claude mcp add --transport http sendly https://app.sendly.now/api/mcpThe first tool call opens a browser, you sign in and choose permissions, and the connection persists. There is no application to pre-register: authorization is OAuth 2.1 with PKCE, dynamic client registration is open, and the protected-resource and authorization-server metadata documents are published at their conventional well-known URLs, so a client that has never spoken to Sendly can discover everything it needs and start the flow unattended.
A headless or CI agent uses a Sendly secret key on the Authorization header instead, and skips the browser entirely. The key's own permissions become the agent's permissions, it is bound to the one project it belongs to, and revoking it in your API-key settings stops the agent on its next call.
What you are actually granting
The consent screen opens on a named preset and then lets you tick individual boxes. A preset is a starting selection, not a stored role — what gets saved is the resulting list of permissions.
| Preset | What it covers | Tools | Irreversible actions |
|---|---|---|---|
| Read only | Look at everything in this project, change nothing. | 33 | None |
| Standard access (default) | Manage contacts, templates, segments and campaign drafts, and send yourself test emails. Cannot mail anyone else. | 61 | None |
| Send & campaigns | Everything in Standard access, plus sending email and running your automations. | 69 | 3 |
| Full access | Everything, including mailboxes, new projects and API keys. | 79 | All 9 |
Standard access is the default, and it is deliberately a capable grant: an agent that manages your contacts, segments, templates and campaign drafts, and that cannot put mail in anyone's inbox. A grant with nothing ticked is also valid — it means the client can sign you in and learn nothing else.
The nine that arrive unchecked
- emails:send — Mail sent this way reaches real inboxes and cannot be recalled.
- campaigns:send — This sends a campaign to your whole audience and cannot be recalled.
- workflows:write — An enabled workflow keeps sending on its own, long after this conversation.
- suppression:write — Removing an address lets Sendly mail someone who asked you to stop.
- projects:write — New projects count towards your plan and may be billed.
- api-keys:read — Reveals which keys exist and what each one can do.
- api-keys:write — A key created here keeps working even after you disconnect this app.
- mailboxes:write — A new mailbox starts receiving real mail on your domain, and deleting one erases every message it holds.
- mailboxes:send — Mail sent this way arrives from your own support address and cannot be recalled.
Drafting a campaign and mailing it are separate permissions, so campaigns:write is deliberately not on that list: an agent can build a campaign for you without being able to send it. That split is the single most useful thing on this page.
Enforcement, not decoration
An agent only sees the tools its grant covers. If you approve analytics reading and nothing else, the analytics tool and the project list are the only tools that appear — the rest are never registered, so the agent cannot attempt them and then be refused. It does not know they exist.
That matters more than a permission check at the end of a call. A tool that is visible but refused invites an agent to retry, rephrase, or route around it. A tool that was never registered is simply not part of the conversation.
A handful of tools need a signed-in person rather than a project, because the routes behind them identify a project admin from the user — creating a project, creating or deleting a mailbox, and the four API-key tools. Those are never offered to a key connection whatever its scopes say. Use an OAuth connection for them.
The rest of the agent surface
MCP is one way in. The same account is reachable over a plain REST API with a published OpenAPI contract, so an agent framework that prefers HTTP calls to a protocol has the whole surface documented for it — see the API reference.
- Idempotency keys on sends, so an agent that retries after a timeout cannot mail somebody twice.
- RFC 9457 problem responses, so a failure is machine-readable and says which field was wrong rather than returning prose.
- Cursor pagination everywhere, so an agent walking a large contact list cannot fall off a page boundary.
- A sandbox test send, so an agent can prove a template renders without mailing a real person.
- Official JavaScript and Python SDKs, both at 1.0.0 and both generated from the same contract.
The complete tool list, the consent-screen walkthrough and the notes on the three tools that hand back a URL rather than finishing inside the agent are all in the MCP guide.
Questions people ask
- Can an AI agent send email through Sendly?
- Only if you tick that permission yourself. emails:send arrives unchecked on the consent screen with a sentence saying that mail sent this way reaches real inboxes and cannot be recalled. Without it, the send tools are never registered, so the agent does not see them at all.
- What is the Sendly MCP endpoint?
- https://app.sendly.now/api/mcp, over Streamable HTTP. It accepts either an OAuth 2.1 access token obtained with PKCE, or a Sendly secret key on the Authorization header. Sending-only keys and dashboard sessions are refused.
- Do I have to register an application first?
- No. Dynamic client registration is open and the protected-resource and authorization-server metadata are published at their conventional well-known URLs, so a client that has never talked to Sendly can discover what it needs and start the flow on its own.
- How do I revoke an agent's access?
- An OAuth connection is revoked in Settings under Connected AI apps. A key connection is revoked by revoking the key in Settings under API keys, which stops the agent on its next call. A key connection deliberately does not appear in Connected AI apps, because there is no consent row behind it.
- Can an agent work across several projects?
- An OAuth connection can, choosing the project per call. A secret key cannot: it is bound to its own project, and a project id that disagrees is refused outright rather than quietly ignored.
- Why can an agent draft a campaign but not send it?
- Because those are two permissions rather than one. campaigns:write covers building the campaign and is a normal grant; campaigns:send covers putting it in your whole audience's inboxes and arrives unchecked. Splitting them is what makes a capable agent grant safe to give.
Something on this page out of date, or missing the case you are in? Write to support@sendly.now — we answer our own email. The full technical detail lives in the documentation.