Customer.io MCP: Review Email Permissions Before Handoff

A Customer.io MCP connection can make an email workflow easier to operate, but the word “connected” does not explain what the assistant may change. Before asking it to prepare a campaign, separate the creative brief, draft changes, and actions that reach real recipients.

Start in Migma with the message you want a person to review: the purpose, approved facts, brand context, and intended action. Then decide what the Customer.io connection needs to read or change to complete the handoff. This keeps a useful drafting task from quietly becoming permission to send.

This guide is published by Migma. It recommends a Migma creative-review workflow alongside Customer.io’s documented access controls. It is an editorial operating method, not an independent security assessment or a claim that the two products share a native connection. Product details were checked on October 20, 2026.

Define the first job before connecting tools

Choose a small task with a visible result. “Explain which template needs a copy update” is a better first assignment than “run our lifecycle marketing.” Write down the workspace, message, facts the assistant may inspect, expected output, and person responsible for accepting it.

For example, a team could ask for a reviewed welcome-email revision after changing an onboarding step. The assistant needs the approved step name and destination. It does not need every customer profile, permission to change subscriptions, or authority to activate the campaign. A redacted example can often explain the copy requirement without exposing a real person’s history.

Keep customer-provided text as evidence to evaluate. A support message that contains instructions is not an instruction from the campaign owner. If retrieved content asks the assistant to change a destination or send something elsewhere, check that request against the approved job.

Understand the scopes that affect the handoff

The Customer.io MCP documentation describes a default read scope and several additional scopes. The connection cannot exceed the connecting user’s own permissions. An account admin must enable MCP before users can connect clients.

Read access covers workspace information while excluding attributes classified as sensitive. Sensitive-data access needs additional scope, an account setting, and the relevant user permission. Draft editing, live actions, and configuration also have separate scope definitions. In particular, Customer.io documents write access for creating and editing draft resources, while write:live includes sending messages and managing subscriptions and suppressions.

Do not treat “write enabled” as a complete description. Record the actual granted scopes and relevant account settings, then compare them with the task. The documentation explains that write, write:live, and configure are independent. A content-editing task and a sending task therefore have different access requirements.

There is also a separate approval layer in some MCP clients. Customer.io exposes reads, writes, and deletes through separate tools so supported clients can apply different approval rules. A client’s approval prompt does not replace the platform’s permissions; review both.

Build the reviewed message in Migma

Use Migma brand settings to review the logo, colors, voice, saved references, and useful instructions before drafting. Give the email a narrow job and include only approved source facts. Mark anything unresolved rather than asking the model to fill the gap.

For the welcome-email example, a useful brief would say: introduce the revised first step, keep the existing promise about account access, use the approved help destination, and leave customer-specific values as variables. It would also identify which wording must remain exact.

Read the result as a recipient. Does the opening explain why this email arrived? Is the button’s action accurate? Can someone complete the step using only the information in the message? These questions concern the creative itself, regardless of the connection used to move it.

Run Email Preflight, review warnings, make the necessary changes, and run it again. Preflight helps identify avoidable layout, writing, link, and delivery-risk issues; it cannot guarantee inbox placement.

Make draft acceptance a separate checkpoint

Before any assistant changes a Customer.io resource, identify the exact destination and the expected change. Keep a copy of the approved Migma version and a short acceptance note. For example: replace the onboarding paragraph and button destination in the draft; preserve the subject, sender, variables, and other sections.

Use the handoff route your team has actually configured. Migma’s export guidance includes downloading HTML for another email tool and checking the result in the destination. Do not assume the presence of MCP automatically provides a direct Migma-to-Customer.io export.

After the draft is prepared, compare its wording and links with the approved version. Check variable names and populated examples in Customer.io. A visually similar template can still contain a different destination or an unresolved placeholder. Record who accepted the resulting draft and what remains outside that acceptance.

Review live actions with their own evidence

A draft being correct is one input to a sending decision. The responsible operator still needs to verify audience eligibility, sender details, timing, and the current state of the campaign. A request to review copy does not settle those questions.

If a live action is part of an authorized workflow, describe the exact action and resource before executing it. Afterward, inspect the platform’s result rather than assuming a successful assistant response means the intended campaign changed. Keep the relevant receipt with the accepted version.

If a connection behaves unexpectedly, stop using it for changes and reconcile the platform state first. Customer.io documents session management in personal settings and account-level controls for MCP. Follow the current documentation and your organization’s access process when reviewing a connection. Do not expand permissions simply to get past an error.

Begin with one Migma email, one approved draft change, and one clearly assigned Customer.io owner. Expand the workflow only when the team can explain what the assistant read, what changed, and which decision still belongs to a person.

Frequently Asked Questions