Salesforce Released an MCP Server. I Used It to Cut a Marketing Cloud Build in Half.

Salesforce released an official MCP server, and it quietly changes how I work in Marketing Cloud.

If you have not run into MCP yet, the short version is this. The Model Context Protocol is a standard way to give an AI model access to real tools and real systems. Salesforce shipping their own means I can point Claude directly at a Marketing Cloud org and let it read schemas, run queries, and work with automations against live data, not a copy I pasted into a chat window.

I wanted to try it on something real, so I used a solution I already knew well.

The solution

It is an IP warming solution. If you have never had to warm an IP, the idea is simple even if the execution is not. When you start sending from a new IP or domain, mailbox providers do not trust you yet. You earn that trust by ramping your volume gradually and watching engagement, so you land in the inbox instead of the spam folder.

Mine is mostly automated, with a human-in-the-loop validation step at the points that actually matter. A set of Data Extensions, a few Automations built from SQL queries and SSJS, and a CloudPage tying it together. The same corner of SFMC where click tracking once broke my CloudPage links. It worked. It was also more complicated than it needed to be, and I knew it.

What changed

I gave Claude scoped access to the org and walked it through the solution.

The biggest win was the SSJS. Several of those steps existed only to populate reference data, the supporting values the rest of the automation reads from. That is a reasonable way to build it. It is not the simplest way. Working against the live schema, we refactored those steps into something cleaner, and a chunk of the SSJS simply went away. Reference data that used to be assembled in script became something the queries could produce directly.

Fewer SSJS steps meant fewer Data Extensions feeding them. By the time we were done, the number of moving parts was cut roughly in half. Same outcome, half the surface area to maintain.

The queries improved too. Not rewritten for the sake of it, tightened. When the model can see the actual tables and the actual columns, its suggestions are grounded in what is really there.

It wrote the documentation too

Something I did not plan for. As we went, Claude documented the work. Every change, why we made it, and how the pieces fit together now.

So I did not just end up with a simpler solution. I ended up with a simpler solution that another consultant could pick up and run with, without me in the room to explain it. On a client engagement that is the difference between a clever refactor and a real deliverable. Documentation is the thing that always gets promised and rarely written. Here it happened alongside the work, for free.

Why direct access is the difference

I have pasted plenty of SFMC code into a chat window. It helps, but the model is always guessing at the half of the picture it cannot see. It does not know your schema. It does not know what that Data Extension actually contains, or how the automations really connect.

Direct access removes the guessing. The model reads the schema itself. It sees the data. It follows the automation from one step to the next. That is the difference between advice about your code and work on your system.

What surprised me was how easy it was, and how much of the improvement came from Claude noticing things. I expected to lead every step. Instead it kept recommending simplifications I agreed with, the same calls I would have made given time to sit with the whole thing. It felt less like using a tool and more like working with a sharp engineer who had already read the entire solution.

Where the judgment stayed mine

This is the part I want to be clear about, because it matters.

When you configure the MCP server, you define its scope. Read, write, send, each one is something you grant or withhold. That is the first and most important control, and it happens before the model does anything. For this work I gave it read and write on the pieces we were refactoring. I did not give it send. There was no reason to, so I did not.

Scope is the box. Review is what happens inside it. I read every change before it touched anything that mattered, and the human-in-the-loop validation the solution was built around did not move. It is still there, still human.

That is the honest shape of AI in an enterprise platform right now. Not let it run. Not keep it out. You scope what it can do, then you stay in the loop on the things that carry risk. I have written before about directing Claude like you would a strong engineer rather than a magic box, and this was that same idea applied to a production Marketing Cloud org.

What it signals

The interesting part is not that I saved time on one solution. It is that the wall between AI and enterprise platforms like Salesforce is coming down on purpose, with the vendor handing you both the tools and the scopes to do it safely.

The people who get the most out of that are not the ones who know the most about AI. They are the ones who already know what a good solution looks like. The model could simplify this build because I could tell it was too complex, recognize the right simplification when it surfaced, and take responsibility for the result. The expertise is still the point. The MCP server just gave it a shorter path to the org.