I recently hosted a Trailblazer Community session on exactly this topic, walking through what the MCE MCP is, how to set it up, what to watch out for, and — most importantly — a live demo showing both where it shines and where it falls flat on its face. This article is the written companion to that session. It stands on its own, but if you want to see the demo warts and all, the recording is linked at the bottom.
Let me be honest about the framing up front: this isn’t a glossy “look how magical AI is” piece. The MCP had been in production for less than a month when I gave this talk. It’s a genuinely powerful new tool, and it’s also far from perfect. Both of those things are true at the same time, and pretending otherwise doesn’t help anyone who actually has to use it.
What is the MCP?
MCP stands for Model Context Protocol. It’s an open standard — not a Salesforce invention — that lets any large language model connect to external tools in a structured, secured way. The analogy that’s doing the rounds is “the USB standard for AI,” and for once the analogy is actually good. Before USB, every device needed its own connector and its own driver. USB gave everything a common way to plug in. MCP does the same thing for AI: it’s a common way for a model to plug into a system and take action inside it.
The Marketing Cloud Engagement MCP Server is Salesforce’s implementation of that standard for Marketing Cloud. It gives your LLM of choice — Claude, ChatGPT, Gemini, whatever you prefer — the tools to take action directly inside Marketing Cloud.
Here’s the distinction that matters most. Without the MCP, your AI is a consultant. It can generate content, write you a SQL query, draft a brief, sketch out a campaign plan. But it stops at the plan. Someone still has to open the UI and build everything by hand.
With the MCP, your AI becomes an operator. The plan comes to life. Ask it to build the journey, and it builds the journey. Ask it to create the data extension, and the data extension exists.
A small example I kept coming back to in the session: imagine you want the SQL for “everyone who opened an email in the last 30 days, ranked by opens.” An LLM can write that query for you today, no problem. That’s the consultant. But with the MCP, the same request can go further — the model writes the query, creates the data extension to hold the results, builds the query activity, and drops it into an automation. That’s the operator. One thread, two very different levels of capability.
How the MCP actually works
It’s tempting to treat the MCP as a black box: natural language goes in, things happen in Marketing Cloud. But it’s worth opening the box, because understanding the mechanics is what separates people who use this well from people who get burned by it.
There are really two halves to what happens, and the boundary between them is the single most important thing to understand.
The reasoning half lives in the LLM. When you connect your client to the MCP server, the server hands over a manifest — a list of every tool it offers, each with a description and a schema telling the model what inputs it expects. That manifest gets loaded into the model’s context. So when you type “create a Holiday Shoppers data extension with email, first name, last name,” the model reads your request against the tools it knows about, picks the right one, and builds a structured set of arguments — mapping “email” to the EmailAddress data type, setting a primary key, inferring sensible field lengths. This half is probabilistic. The model is reasoning, and reasoning can be wrong.
The execution half lives in the server. It takes the structured tool call, validates it, and translates it — deterministically — into the actual Marketing Cloud REST API call, authenticated with your credentials. This half doesn’t guess. It faithfully executes whatever instruction it receives.
The handoff between those two halves — where fuzzy natural language becomes a precise, structured tool call — is where all the interesting risk and all the interesting power lives. It’s also worth knowing that the MCP itself is stateless. Each call stands alone. The conversation, the memory, the context of what you’re doing — all of that lives in the LLM, not in the server. The server has no idea what it did five seconds ago.
That single fact has big consequences for logging, which I’ll come back to.
What it enables
The MCP is essentially a wrapper around the existing Marketing Cloud Engagement APIs. That’s not a criticism — it’s the whole point. Nearly everything you can do through the API, you can now do through natural language. In practical terms, that breaks down into a handful of areas:
Journeys — build, publish, pause, and manage them end to end. Data extensions — create schemas, add fields, query and update records, run SQL. Automations — create and run Automation Studio workflows. Content — draft emails, templates, and Content Builder assets. Contacts — retrieve and update attributes and subscription status. And messaging — send definitions across email, SMS, and, increasingly, push.
When I gave the session, the server exposed around 99 individual tools. That number is worth sitting with for a second. This is more mature than the “less than a month old” timeline would suggest. It’s not a toy proof-of-concept; it’s a broad, functional surface across the platform.
Tools versus skills — the terminology that matters
There’s a distinction in the MCP world that trips people up, and getting it straight will save you frustration.
Tools are the specific actions the server can take — “create a data extension,” “add a journey activity.” These are built and maintained by Salesforce. You don’t write them; you use them.
Skills are the instructions you provide to guide how the model uses those tools for your specific business. Grounding files, naming conventions, rules about how your organization does things. You write these.
The way I put it in the session: if tools are the hammer and nails, skills are the custom instruction manual tailored to your team’s conventions and processes. Tools give the model the ability to act. Skills are what make it act correctly — the way your organization actually works, with your naming standards and your guardrails.
This matters more than it sounds, because the quality of your skills directly determines whether the model gets things right the first time or spends three attempts guessing. Which brings us to the honest part.
The honest bit: it doesn’t think for you
Here’s the thing I want anyone reading this to take away above all else: the LLM doesn’t think for you.
In the live session I ran real demos, and I deliberately left the failures in. Two stand out.
I asked the model to add Einstein Send Time Optimization to a journey. Instead of using the dedicated STO tool that exists for exactly this purpose, it built a custom Journey Builder activity — for no reason I could explain on the spot. It worked around the right tool rather than using it.
In another demo, I had it build a data extension from a messy CSV. It cheerfully told me it had created three text fields at different lengths — some at 150 characters, some at 500. Then I checked. Every single field was 100 characters. It had claimed one thing and done another, without any indication that anything was off.
I didn’t hide those moments, and I’d encourage you not to be surprised by them either. This is the actual experience of working with the tool today. It is powerful and it is helpful and it will occasionally do something baffling with total confidence. That’s not a reason to avoid it — it’s a reason to stay in the loop, to review what it’s doing, and to bring your own platform knowledge to the table. You still need to understand Marketing Cloud. The MCP doesn’t remove that requirement; if anything, it raises the stakes on it.
Security: the version without the marketing gloss
The security story around the MCP tends to get compressed into reassuring phrases like “enterprise-grade” and “trust layer.” Those phrases are doing a lot of work, and practitioners deserve the unglossed version. There are four things worth understanding.
OAuth scopes are your floor. The MCP authenticates through an installed package, and the agent acts as the authenticated user. Its powers are the intersection of the package’s scopes and your own permissions. This is real, meaningful security — but it’s about access governance, not data privacy. Grant only the scopes a use case genuinely needs. A read-heavy reporting workflow and a write-heavy build workflow probably shouldn’t share the same package.
Prompt injection is a real, if low-probability, risk. Because the model reads data from Marketing Cloud into its context — journey names, content, contact attributes — anything seeded maliciously in that data could, in principle, influence what the model does. It’s not a common attack today, but it’s a genuine one, and grounding files plus constrained scopes are your defense.
There is no native logging, because the MCP is stateless. This is the one that surprises people. The MCP doesn’t keep a log of what it did — it can’t, it’s stateless and everything runs as you. And Marketing Cloud’s own Audit Trail is a security access log (logins, authentication events), not an API activity log. So if you need to answer “what did the agent create last Tuesday, and why,” none of that is captured for you out of the box. If governance matters in your organization — and in regulated industries it absolutely does — logging is something you have to design and build yourself, either at your client layer or via a proxy.
Data leaves Salesforce, and there’s no trust layer when you use an external client. This is the big one. When you use Claude, ChatGPT, or any external client to drive the MCP, the LLM doing the reasoning is not behind Salesforce’s Einstein Trust Layer. The trust layer protects the boundary between Salesforce and Salesforce’s own model gateway. It does not cover data that an external model processes. For most marketing operations that’s perfectly fine. For anything involving real, sensitive PII in a regulated context, this needs to be a deliberate architectural decision — not an assumption.
One thing I found myself wishing for during the session: I’d love it if MCE’s permission model were granular enough to let an agent read the structure of a data extension — its schema, its fields — without reading the actual records inside it. For a lot of analysis and documentation work, structure is all you need, and the records are exactly the sensitive part. Today the scoping isn’t that fine-grained. Maybe it will be.
The summary I’d offer: the MCP’s security model is genuinely solid on access governance. It is not a data-privacy guarantee at the model boundary. Know the difference, design for it, and — as best practice number one — test everything in a sandbox before it touches production.
MCP versus Agentforce — complementary, not competing
A question that comes up constantly: how does this relate to Agentforce? They sound like they overlap. They don’t, really.
Think of the MCP as an internal build tool. Your marketing team uses it behind the scenes to create campaigns, assets, and journeys faster. It’s operated by marketers, for marketers.
Agentforce is customer-facing. It handles live, real-time, two-way conversations directly with your customers — support, engagement, conversion.
The clean way to hold it in your head: the MCP builds the content and the machinery that fills the funnel; Agentforce is what engages customers once they’re in it. One stack, two distinct jobs. They’re complementary.
Getting started, safely
If you’re going to try this — and you should — here are the principles I’d hold onto. None of them are a sequence; they’re all just true at once.
Test in a sandbox first. The agent can delete things. Find that out somewhere safe.
Be specific in your prompts. Your prompt is the instruction, and because the model does the translating, vague intent produces vague — or wrong — tool calls. Garbage in, garbage executed.
Use plan mode. Review what the agent intends to do before it acts, and dry-run anything destructive — especially schema changes that can ripple across dependent data extensions.
Grant least privilege. Only the scopes a use case needs. Permissions are a strategy, not a checkbox.
Ground it with skills. Give the model the files and instructions that tell it how your business works. This is the single biggest lever on getting correct results the first time.
Verify the output. AI-written SQL is often close but not quite right. Keep your session context clean and check the results — every query, every send definition.
Where this is genuinely useful today
For all my honesty about the failures, let me be equally clear about the wins, because they’re real.
My favorite use case — and the one the session audience responded to most — is documentation. Point the model at an undocumented automation and ask it to write the description and annotate every step. I love building things, but I have never in my life written that much comment on an automation. Having it done for me, accurately, in seconds, is the kind of unglamorous productivity that actually changes how you work.
Building a data extension from a messy CSV, with data types inferred. Spinning up a journey from a plain-language description and staging it in draft for review. Running a query conversationally instead of clicking through Automation Studio. These are all real, they all work, and they all save meaningful time.
The pattern across all of them: the MCP is at its best when it handles the tedious, mechanical, well-defined work — and at its most dangerous when you hand it something ambiguous and stop paying attention.
Watch the recording
This article covers the concepts, but the live demo is where you see the tool actually behave — including the two failures I described, in real time, and how I worked through them. If you want the full picture, including the Q&A where we got into MC Next, row limits, API consumption, and error handling, the recording is well worth 45 minutes of your time.