AI Email Agents: API vs CLI vs MCP Permission Matrix

An email agent can be a chat panel inside a product, an MCP connector, a command-line program, or code calling an API. Those surfaces may reach the same account, but they do not create the same control boundary.

Editorial disclosure: Prepared by Marketing Wiki Research Automation under standing direct-publication authorization and not independently reviewed. Product capabilities are vendor-documented unless labeled otherwise; sources were refreshed on September 1, 2026.

Use this comparison to decide what an agent may read, draft, change, schedule, or send. It covers official documentation reviewed on August 14, 2026. It does not test output quality, reliability, latency, or permission enforcement in live accounts. For the protocol-level distinction, read the Model Context Protocol reference. For the broader choice between prompts, skills, and agents, use Prompts vs skills vs agents.

Four surfaces, four different boundaries#

• API: an HTTP contract. Your application owns sequencing, retries, approval logic, credentials, and logs around the request.
• CLI: a terminal wrapper around an API or product-specific workflow. It is convenient for coding agents, but a command can still mutate an audience or send mail.
• MCP: a tool interface that lets a model discover and call product actions. MCP standardizes the connection; it does not, by itself, add human approval.
• Built-in agent: an assistant inside the vendor product. It may share the current user's role, page context, and product-native confirmation flows.

“Not established” below means the reviewed official sources did not prove a programmatic action. It does not mean the platform lacks that action. “Unknown” marks a current documentation conflict or rollout-sensitive state.

Surface inventory#

This routing map makes no ranking. A built-in confirmation step may matter more than the number of available tools.

Action and permission matrix#

Cells name only surfaces proven by the reviewed sources. “Dashboard” is included when a programmatic workflow deliberately hands control back to a human interface.

The approval boundary is the real comparison#

Customer.io: separate draft access from live access

Customer.io MCP separates reads, ordinary writes, deletes, live writes, and configuration. Connections default to read. A write scope can create or edit drafts, while write:live covers sending, subscriptions, suppressions, and other live actions. An account admin must first allow MCP to edit live data.

The Customer.io CLI gives terminal agents direct access to the API surface. Service-account tokens can inherit a user or system role, and user tokens can be permanently restricted to read-only. The in-product Agent is a separate surface: it can create emails, segments, automations, and one-time sends, but it follows normal approval and sending flows by default. Admin-enabled live editing and Auto mode change that boundary.

Practical reading: Customer.io documents the most granular distinction here between draft mutation and live mutation. It still requires the team to decide who may enable live access and which external AI provider may receive customer data.

Kit: MCP adds a provider-side handoff that the API does not

Kit API V4 can create and send broadcasts and manage subscriber records. Its broadcast endpoints support drafts and scheduled delivery, while a separate endpoint returns broadcast statistics.

Kit MCP exposes account data, audience operations, drafting, editing, and analytics through an external AI client. Kit labels tools by risk. For a broadcast send, sequence deletion, unsubscribe, or webhook fire, MCP returns a deep link; the action runs only after the user confirms inside Kit.

That is narrower than saying “MCP is safer.” The safety property comes from Kit's implementation, not the protocol. A custom integration using the API needs its own approval policy.

Loops: MCP exposes API operations through four tools

The current Loops API page documents contacts, events, transactional sends, draft campaigns, message editing, preview sends, and Guardian checks. The agents hub says campaign drafts should be reviewed and sent from the dashboard. This creates a clear handoff for marketing campaigns, while transactional endpoints remain direct-send operations.

The Loops MCP page now labels its hosted OAuth server “Available now.” It documents four tools: search, describe, execute, and teams. Together they find an API operation, inspect its request shape, run it against a selected team, and list accessible teams. The page explicitly includes contacts, mailing lists, events, and transactional email, plus the other operations exposed by the Loops API.

The documentation establishes availability only. Before adoption, connect a non-production account, inspect the runtime tool inventory and described operation, then run a read-only call.

Migma: broad email operations share the underlying permission model

Migma's API reference documents projects, email generation and editing, validation, previews, contacts, campaigns, and exports. The CLI wraps the API for generation, validation, export, audience work, sends, scheduling, and metrics. Migma MCP exposes creation, validation, test sends, campaign drafts, exports, audience management, and results to agent clients.

MCP does not create a separate security plane: Migma states that MCP calls use the same permissions as SDK, CLI, and REST requests. OAuth shows requested scopes, and email:send allows both test and live sends. Migma recommends keeping human approval enabled before sends, exports, audience changes, and campaign changes. Because this review did not execute the clients, it does not claim every MCP host forces that confirmation.

Use a key without email:send for research and drafting. Add send permission only to the job that owns the final recipient and approval decision. Recheck export connections and permission filtering in a non-production account before adoption; these paths are release-sensitive.

Resend: API, CLI, and MCP all reach consequential operations

The Resend CLI can send and schedule messages, create and send broadcasts, manage contacts, publish templates, register webhooks, and inspect request logs. Resend MCP exposes the same kinds of actions to a model, including email and broadcast sends, scheduling, contacts, automations, events, API keys, webhooks, and logs.

Reviewed documentation shows OAuth approval when connecting hosted MCP, but it does not establish a Resend-side confirmation before each send, schedule, audience mutation, or automation change. The agent host or surrounding application therefore needs the approval gate. For measurement, webhooks provide programmatic email events; request logs are operational evidence, not a substitute for campaign-performance reporting.

A permission design that survives surface changes#

Do not give one credential every action merely because a vendor exposes them through one interface. Split the workflow by consequence:

Where the platform cannot enforce those roles, enforce them with separate keys, separate service accounts, short-lived sessions, read-only modes, and an approval record outside the model conversation.

Selection questions for an agent builder#

1. Does the job need deterministic HTTP calls, terminal orchestration, conversational discovery, or product-native context?
2. Can the credential be restricted to read and draft actions?
3. Does “send” require a provider-side confirmation, a client-side prompt, or only possession of a key?
4. Are draft writes separated from live-resource writes?
5. Can audience data be hidden from the model or limited to aggregate results?
6. Is there a dedicated validation action, or only a test delivery?
7. Can the workflow export an approved artifact without granting send permission?
8. Are scheduling and immediate send separate permissions?
9. Can retries be idempotent and audited?
10. Does the current documentation match a live non-production connection?

Choose the smallest surface and permission set that completes the job. Add a more agentic interface when tool discovery and multi-step orchestration justify the additional data and action boundary, not because MCP, CLI, or “AI agent” appears on a feature list.