What Permissions Should an MCP Server Have Before It Sends?

Why this question matters more than it sounds like it does

An MCP server is the bridge that lets an AI assistant actually do things in your outreach account instead of just talking about them — draft, schedule, send, read replies. That's useful, but it also means a permission mistake isn't a typo in a chat window, it's a message that actually goes out to a real person, or a suppression entry that actually gets deleted. The question isn't whether to connect your assistant to your outreach account — it's which actions you let it take without you in the loop.

Permissions to insist on, scoped narrowly

Read access to campaign and reply data. The assistant should be able to see what's been sent, what bounced, what got a reply, and what the current deliverability signals look like. This is low-risk and it's also what makes the assistant's advice worth anything — without it, it's guessing.

Draft and propose, separate from send. There's a real difference between an assistant that can write a message and queue it for approval, and one that can write and send in the same action. For anything new — a new sequence, a new domain, a new list — drafting without sending is the safer default. Standing send permission for an established, already-warmed sequence is a different risk level than send permission for something that's never run before.

No unilateral control of suppression and unsubscribe handling. The list of people who've opted out or bounced is the one piece of data where a mistake is both a compliance problem and irreversible once a message has gone out. An assistant should be able to read this list and check against it, but editing it — removing someone, resetting a bounce flag — should require a person to confirm.

Credential scope and revocability. The connection between your assistant and your outreach account should be its own credential, not your personal login, and it should be something you can revoke in one step if you change tools, bring on new help, or just want to pause. If revoking access means changing a password everywhere, the permission was too broad to begin with.

An audit trail. Every send, every list change, every status update the assistant makes should be logged somewhere you can review — not because you expect it to misbehave, but because when something does go wrong, you want to know what happened and when, not reconstruct it from memory.

Red flags in a permission grant

If connecting your assistant requires sharing your actual account password, if there's no way to see a log of what it's done, if there's no separate switch for "send" versus "everything else," or if revoking access means more than one step — treat those as signs the integration wasn't built with this question in mind.

A simple permission table

Action	Should the assistant have standing permission?
Read campaign stats and replies	Yes
Draft new messages	Yes
Send on an established, already-running sequence	Often, with limits and logging
Send on a brand-new sequence or domain	No — require approval first
Edit the suppression/unsubscribe list	No — read only, edits need a person
Change compliance settings	No
Revoke its own access	Should be a one-click action for you, always

What to take away

• Treat MCP permissions the same way you'd treat handing someone the keys to your outreach account — scope them to exactly what's needed.
• Separate "can read" from "can draft" from "can send" — they are three different risk levels, not one setting.
• Suppression lists and compliance settings should never be editable by the assistant alone; a mistake there is the hardest kind to undo.
• Make sure revoking access is a single, obvious action you control, not a multi-step process.
• Ask for an audit log before you ask for a feature list — knowing what happened matters more than how fast it happened.