ESPs, CDPs, MCPs and APIs: What lifecycle tools are allowing LLMs to do

Imagine giving an AI assistant a campaign brief and asking it to find the right template, prepare the email, build the audience, create the campaign, and leave everything ready for review.

Parts of that workflow are already possible. Which parts depend heavily on the platform, the account's permissions, and what we mean by words like "template," "segment," and "create."

For lifecycle marketers, this is a meaningful shift. AI can increasingly participate in campaign production, from preparing content to configuring platform objects. But evaluating that opportunity requires more precision than asking whether an ESP "has AI" or "has an MCP."

At Scalero, we look at three practical questions: Which actions does the platform expose? What do those actions actually change? And can the marketing team maintain the result afterward?

First, separate the products from the connections

These acronyms describe two different things: the platforms marketers use and the connections that let software work with them.

An ESP, or email service provider, is where we create and deliver email. Many platforms we casually call ESPs now handle SMS, push, in-app messaging, customer data, and orchestration as well.

A CDP, or customer data platform, helps collect, organize, and activate customer data. Depending on the product, that can include identity resolution, audience building, and moving data between systems. The boundary between CDPs and messaging platforms is increasingly blurry, so the label alone tells us little about what we can automate.

An API, or application programming interface, is a way for software to interact with another system. An API might let us retrieve a campaign, update a profile, upload HTML, or schedule a send.

MCP, or Model Context Protocol, is an open standard for connecting AI applications to external tools and information. A vendor's MCP server exposes capabilities that a compatible AI application can discover and use. It might call the vendor's APIs behind the scenes.

The ESP or CDP is the system where the work happens. APIs and MCP servers are ways to access that system.

What an MCP actually does

Start with an assistant that has no connection to a client's platform. It can help write copy or suggest a lifecycle strategy based on what we give it. It cannot independently inspect the client's current campaigns or save a draft in their account.

Connecting an MCP server can give the assistant access to specific operations. Each exposed tool has a name, a description, and a defined input structure. For example, a tool might retrieve a campaign using its ID. Another might create a template using a name and HTML content. The model can select an appropriate tool and supply arguments; the surrounding application and server execute the request and return the result.

There are three participants worth understanding: the AI application we use, the MCP client inside that application, and the MCP server providing access to the external system. The language model helps decide what to do. The integration performs the actual operation. MCP can also expose resources and reusable prompts, although callable tools are the most relevant part of this discussion.

Here is an illustrative workflow:

"Find our recent onboarding campaigns, compare their click rates, and prepare a revised version of the second email as a draft."

If the connected tools support it, the assistant could retrieve campaign records, request metrics, inspect the existing message, propose changes, and save new content. It would likely need several operations to complete the request. If a required operation is missing, the workflow stops at that boundary or needs another supported integration.

MCP does not supply the marketing judgment in this example. We still need to define which campaigns belong in the comparison, whether the reporting windows are comparable, and what makes the proposed revision useful.

Couldn't we just use the API?

Yes. An LLM does not need MCP to work with an API.

We can give an AI application custom functions that call an ESP's API. An assistant with an approved code execution environment can also run a script that makes authenticated requests. We can build a workflow in our own application or an automation tool and use the model for selected steps.

For example, we could write a small service that accepts approved copy, inserts it into a known HTML structure, creates an Iterable template, and returns the template ID. An LLM could help generate the copy or choose among approved structures without any MCP server being involved.

The difference is how the integration is packaged and maintained.

MCP's advantage is standardization. We can reuse an integration across compatible AI applications instead of designing a completely separate tool interface for each one. Tool discovery also lets an application learn what the server exposes. A thoughtfully designed server can package useful descriptions and operations that would otherwise take us time to assemble ourselves.

That does not make MCP inherently faster, cheaper, or more reliable than direct API calls. A fixed nightly process may be simpler as ordinary code. A conversational task that changes from request to request may benefit more from MCP.

Both approaches belong in a lifecycle team's toolkit. A useful automation can use a vendor MCP, direct API calls, or a combination of the two.

The industry is opening up unevenly

Lifecycle platforms are taking several approaches to external AI access.

Some expose useful reporting and retrieval tools, with selected write operations. Some support substantial campaign production. Others expose broader authoring capabilities through their MCP than we would infer from their public API documentation alone.

Customer.io is a useful example of the last pattern. Its MCP reaches the Journeys UI API, the CDP Data Pipelines API, and a Design Studio surface with its own reference — a different scope from simply wrapping the public App API. By contrast, Braze describes its MCP tools as mapping to specific platform operations, with important campaign features restricted to beta participants.

The practical consequence is that we need to evaluate the public API and the MCP separately. Neither is a reliable shorthand for the other.

An AI feature inside the vendor's own interface is another separate category, and Simon Data is the clearest current example. Its June 2026 release notes describe in-product chat agents that can create datasets, edit and validate templates, and create segments pending user approval — while its public documentation includes no MCP server and no public write API for those objects. The capability exists inside the product and not outside it. Likewise, a community-built MCP server is not automatically equivalent to an official, supported integration.

Access also varies within a single platform. Braze's documentation is explicit that its MCP server is unavailable on free trial accounts, incompatible with IP allowlisting, requires a company admin to approve the client's redirect URI, and is bounded by the signed-in user's dashboard permissions and OAuth scopes. The same MCP gives two people at the same company different capabilities.

What the platforms allow today

Here is how seven lifecycle platforms compare. "Unverified" means the capability is not established by the public documentation cited here. Private or partner options may exist.

A note on Braze: Salesforce signed a definitive agreement to acquire Braze in October 2026, with an expected close in Salesforce's fiscal 2028. No combined roadmap has been published, so the capabilities above describe Braze as it operates today.

Templates deserve a much closer look

"Can create a template" sounds straightforward until we consider the handoff.

A developer may be happy receiving an HTML email. A client marketer may expect to open that same email and move a two-column product row, replace an image block, or change mobile spacing in a visual editor.

Those are different deliverables.

An HTML template contains the code that renders the email. A native drag-and-drop template also needs the editor's structured representation of rows, columns, blocks, settings, and relationships. A reusable template adds another question: is the content saved in a shared library, or does it exist only inside one campaign?

The email looking correct in an inbox does not answer whether the client can maintain it in their preferred editor.

Iterable illustrates the gap clearly. Its API accepts HTML for email template creation, and its documentation explicitly states, of the email update endpoint: "This call does not work on templates made with the Drag and Drop Editor." Teams should not assume an assistant can use these endpoints to insert a native two-column row into an existing visual template. Worth noting that this restriction is documented at the API layer and is not restated in the MCP tool list — the MCP template operations do not establish a separate native visual-authoring capability.

Klaviyo documents native visual templates explicitly. Its API distinguishes three types: CODE for custom HTML, USER_DRAGGABLE for hybrid templates edited as HTML but compatible with the visual editor, and SYSTEM_DRAGGABLE for native drag-and-drop templates backed by a structured definition object. Its MCP inventory includes dedicated create_dnd_email_template and update_dnd_email_template tools, and those are not beta-gated.

The structural difference matters: Klaviyo's drag-and-drop distinction is a field-level choice between html and definition, not an endpoint that refuses visual templates. That makes it the most promising pilot for producing emails that remain visually editable, provided the team validates the supported blocks and the final editor experience.

Customer.io requires identifying the editor first. Design Studio has a documented content lifecycle through its API, and its component syntax supports visual editing. That API excludes emails made in other editors, including the classic drag-and-drop editor. Global styles can be read and updated through it, and a component change can be propagated across every referencing message — though as a deliberate two-step flow rather than one operation. Deleting a token or variant still requires the Design Studio UI.

Braze has an explicit visual-template restriction. Its email template information endpoint states: "Templates built using the drag-and-drop editor for email are not accepted." The restriction surfaces at the MCP layer too. HTML template support should therefore not be described as general visual-editor support.

Bloomreach separates sending from reusable assets. Its public API can send raw HTML, but that content is not automatically saved as an Asset Manager template, and Bloomreach's support documentation states plainly that it "doesn't provide a public API to programmatically create or update email templates." Loomi Connect adds campaign-content operations; that still does not establish a reusable-template authoring workflow.

SFMC treats templates as first-class assets. Its MCP ships sfmc_create_email_template alongside sfmc_create_email, and Content Builder's model is explicit that an asset can be a message containing a template, which is itself an asset. SFMC has no reusable-template limitation — the sharpest contrast with Bloomreach in this comparison. For marketers expecting editable blocks, the implementation still needs to preserve the appropriate structured asset rather than assume a single HTML string produces that experience. Testing the actual Content Builder handoff is essential.

For Simon Data, reusable-template and native visual-authoring support remain questions for the vendor. The public Audience API documentation is about accessing contact profiles, not evidence of template production support.

Journeys and segments have similar traps

"Journey support" can describe several different things: reading a journey, retrieving its performance, sending a person into an existing journey, changing a message, or building the entire set of branches and waits.

We need to name the action we mean. Iterable's MCP exposes exactly two journey tools, get_journeys and trigger_journey — retrieval and triggering, with no create, update, or delete. Braze's Canvas tools are get_canvas_list, get_canvas_details, get_canvas_data_series and get_canvas_data_summary, all read operations. Neither establishes journey construction.

Bloomreach, by comparison, explicitly documents draft scenario creation, full-definition updates, and individual-node updates — its documentation notes that to change one node "without resending the whole scenario, use update_scenario_node instead."

Segments require the same precision. Adding people to a static list is different from saving a dynamic rule such as "purchased within 90 days but not within 30." Retrieving members of an audience is different again.

This matters especially on the CDP side. Before asking an assistant to build a lapsed-buyer audience, we need to know where purchase history lives, which identifier connects the records, what counts as a completed purchase, and how refunds or missing timestamps should be treated.

An integration can execute a valid request while the audience is conceptually wrong. Someone who understands the data model still needs to define and check the result. That is the kind of work our data engineering practice exists to do before any assistant is pointed at a workspace.

The MCP quirks that affect real work

Several implementation details can change what a marketer sees after connecting an account.

Permissions are layered. Iterable's MCP server defaults to a read-only mode, with separate environment flags for writes, sends, and access to personal data — each off by default, and sends requiring writes. Klaviyo can expose a core subset of tools or its full inventory, with additional configuration for read-only mode, user-generated content, and beta tools. Braze gates campaign and segment operations behind beta participation. A tool appearing in documentation does not mean it is enabled for every client.

Read responses can be incomplete by design. Bloomreach's campaign list omits schedule, customer filter, email design, and A/B split configuration. Even a detailed campaign read strips the design fields unless include_design is set. An assistant preparing an edit needs the relevant full definition — and because Bloomreach's campaign update uses PUT semantics that replace the whole definition, a partial read before a write can silently drop configuration. Its documentation also notes that write tools have no automatic rollback.

Some operations finish asynchronously. Salesforce explicitly labels certain MCP tools asynchronous and notes that "the AI assistant uses a separate tool to check the status of the request." Publishing a journey and bulk-upserting Data Extension rows both work this way. Receiving an accepted request is different from verifying that the requested work completed.

These are practical engineering details, not reasons to avoid the tools. They are reasons to build repeatable workflows around them instead of assuming a successful chat response proves the account is correct.

Where lifecycle teams should start

At Scalero, our recommendation is to start with a few narrowly defined production workflows and measure their usefulness.

First, use connected reads to reduce preparation time. Campaign inventories, content audits, and reporting summaries are good candidates where the necessary data is exposed. The output should point back to the actual objects and reporting periods so a marketer can check it.

Next, produce drafts in the team's real working format. A useful pilot would take an approved brief, use a known template structure, populate content, save a draft, and return a preview and object link. Success includes a human opening the result and continuing to edit it normally.

Then connect audience and orchestration steps deliberately. We should define the rule, inspect the resulting audience, confirm exclusions, and verify how the campaign uses it. The goal is to make sound production judgment easier to apply consistently.

For example, consider this proposed task:

"Prepare next week's winback email using the approved offer and template. Build the agreed audience of customers who last purchased 90 to 180 days ago. Leave the campaign ready for review, and show the content, audience definition, estimated recipients, and exclusions."

Before automating this task, establish whether that platform supports the required template type, whether the audience is a dynamic segment or a separately maintained list, whether the assistant can create the campaign, and which actions could make it live.

Once the process works, we can decide which parts should remain conversational and which should become ordinary software. Repeated asset assembly or data transformations may belong in tested code, with the assistant coordinating the task and explaining exceptions.

We should measure time to a reviewable draft, corrections required, and whether the marketing team can maintain the result. A workflow that saves twenty minutes and produces dependable output is valuable even if a human still completes the final steps.

The opportunity for lifecycle teams is to spend less time translating clear decisions into repetitive platform actions. Data knowledge, lifecycle strategy, creative production, and QA determine whether that automation produces useful work. Those disciplines give an assistant the context it needs to produce something a marketer can confidently use.

A productive starting point is a specific question: which recurring task can your team take from brief to a verified, reviewable result with the capabilities available in your platform today?

If you want help answering that for your stack, our lifecycle marketing services include platform capability assessments across every system in this comparison.