Salesforce Headless 360 & MCP: The Beginning of AI-Native Marketing Cloud Development

For years, working with Salesforce Marketing Cloud has meant moving between interfaces such as Automation Studio, Journey Builder, Contact Builder, Content Builder, APIs, SQL activities, scripts, and external integration tools.

That model is beginning to change.

Salesforce is increasingly turning its platform capabilities into services that AI agents can discover and execute directly. Two technologies are at the centre of this shift: Headless 360 and Model Context Protocol, or MCP.

The interesting part is that this is not simply another AI assistant sitting beside Marketing Cloud.

It represents a potentially different way of interacting with the platform itself.

What exactly is MCP?

Model Context Protocol is an open standard that allows AI applications and agents to connect with external systems through a common interface.

Instead of building a completely different integration for every AI model and every enterprise platform, an MCP server exposes tools that an authorised AI agent can understand and invoke.

Conceptually, the flow becomes:

AI Agent → MCP → Salesforce Capability → Execution

The agent is not limited to answering questions about Salesforce.

With the correct authentication and permissions, it can potentially perform actions.

That distinction is important.

Traditional generative AI:

"Here is the SQL query you should execute."

Agentic AI through MCP:

"I found the relevant capability, prepared the request and executed the operation."

That is a significant change in the developer experience.

Marketing Cloud Engagement now has its own MCP Server

Salesforce has made its first-party MCP Server for Marketing Cloud Engagement generally available.

This allows compatible AI clients to interact with core Marketing Cloud capabilities through MCP instead of requiring developers to manually construct every API interaction themselves.

An MCP-aware agent can potentially work with capabilities around:

Data Extensions
Journeys
Automations
Automation Studio activities
Campaigns
Content Builder folders
Data Extension queries
Bulk data operations
Contact deletion
Email tracking information

Salesforce is continuing to expand this toolset.

For an SFMC developer, that means tasks which traditionally involved navigating multiple screens, checking documentation, generating API payloads and executing scripts can increasingly become agent-assisted workflows.

Imagine an SFMC developer workflow

Consider a normal support requirement:

"Find the Data Extension used for the AU customer campaign, check its fields and identify whether MobilePhone exists."

Today, a developer might:

Open Marketing Cloud
Find the correct Business Unit
Search Contact Builder or Email Studio
Locate the Data Extension
Open its configuration
Review its fields

Another approach could involve REST APIs or custom scripts.

With MCP, the interaction could eventually look much closer to:

"Find the customer Data Extension used by this campaign and tell me whether it contains a mobile phone field."

The AI agent can determine which available capability it needs, invoke it and return the result.

Now take it further:

"Add a nullable MobilePhone field if it doesn't exist."

At that point the AI is no longer just helping the developer understand the system.

It is becoming an operational interface to the system.

Then comes Headless 360

Marketing Cloud MCP is only part of the bigger picture.

Salesforce's Headless 360 strategy is about making Salesforce capabilities available outside the traditional Salesforce user interface.

Instead of treating applications as places where users must log in and click through screens, Salesforce is increasingly exposing business capabilities so they can be consumed by:

AI agents
Developer tools
Custom applications
CLI workflows
Conversational interfaces
External enterprise systems

The Headless 360 MCP Server takes this further by giving MCP-aware agents a common way to discover Salesforce capabilities.

One particularly interesting design decision is that Salesforce does not simply expose thousands of Salesforce operations as thousands of individual tools.

That would overwhelm an AI model's context.

Instead, Headless 360 uses a much smaller tool surface that allows the agent to discover the appropriate underlying Salesforce capability dynamically.

This is extremely important for enterprise AI.

Why capability discovery matters

Suppose Salesforce exposed 4,000 different actions directly to an LLM.

The AI would first need to understand thousands of tool definitions before deciding which one to use.

That increases:

Context consumption
Tool-selection complexity
Potential hallucination
Maintenance effort
Integration overhead

Headless 360 instead moves toward capability discovery.

The AI can effectively ask:

"What capability exists for what I am trying to accomplish?"

It can then retrieve the appropriate operation and execute it.

This is much closer to how an intelligent enterprise agent should work.

API-first vs agent-first development

Traditional Salesforce integration is primarily API-first.

A developer determines:

1. Which API is required 2. Which endpoint must be called 3. Which authentication mechanism is needed 4. What payload must be generated 5. How the response should be interpreted 6. How errors should be handled

MCP introduces another abstraction layer.

The developer or business user describes the intent.

The agent identifies the capability.

The platform exposes the governed operation.

The agent executes it.

So instead of thinking only:

Endpoint → Payload → Response

we may increasingly think:

Intent → Capability → Execution

APIs are not disappearing.

MCP ultimately still relies on underlying platform capabilities and APIs.

But developers may interact with those APIs less directly for many routine operations.

What this means for SFMC developers

This does NOT mean SFMC developers are becoming unnecessary.

It means the valuable part of the developer role is moving upward.

Knowing where to click inside Marketing Cloud will gradually become less valuable.

Understanding the platform will become more valuable.

Future Marketing Cloud developers will need stronger knowledge of:

Data architecture
Data Extensions
Contact models
Journey architecture
SQL optimisation
API behaviour
Authentication
Permission models
Enterprise integration
Data Cloud / Data 360
Governance
Agent architecture
MCP
AI security

The question will increasingly change from:

"How do I manually perform this task?"

to:

"Should an agent be allowed to perform this task, under what conditions, using which capability and with what governance?"

That is an architecture problem rather than a button-clicking problem.

MCP + Data 360 could be even more interesting

The Headless strategy becomes even more powerful when combined with Data 360.

Salesforce has been expanding MCP access around Data 360 capabilities as well.

This creates an interesting future workflow.

Imagine asking:

"Identify customers who purchased during the last 90 days, have not engaged with email during the last 30 days, have high lifetime value and are eligible for marketing. Create an audience and prepare it for activation."

Traditionally, this could require coordination across:

Data ingestion
Data modelling
Calculated insights
Segmentation
Activation
Marketing Cloud configuration

An authorised AI agent could increasingly orchestrate several of those capabilities through natural language.

That does not remove complexity.

It hides execution complexity behind an intent-driven interface.

Security becomes more important, not less

Giving an AI agent access to enterprise systems creates obvious risks.

If an AI agent can create a Data Extension, it may also be able to modify one.

If it can query customer data, permissions must determine which customer data it can retrieve.

If it can execute an automation, organisations need control over which automations it can execute.

The real enterprise value of MCP therefore depends heavily on:

OAuth authentication
User identity
Permission sets
Least-privilege access
Auditability
Approval mechanisms
Environment separation
Data governance

The goal should never be:

Give AI access to everything.

The goal should be:

Give an authenticated agent exactly the capabilities required for the task.

This will probably become one of the most important principles of enterprise agent architecture.

Human-in-the-loop will still matter

There are many operations where autonomous execution makes sense.

For example:

Reading metadata
Finding Data Extensions
Checking field definitions
Retrieving tracking information
Generating SQL
Analysing automation failures

But destructive or high-impact actions may still need approvals.

Examples include:

Deleting contacts
Modifying production journeys
Changing send audiences
Publishing campaign configurations
Editing production automations

A mature AI architecture therefore needs multiple execution levels.

Read → Recommend → Prepare → Approve → Execute

Not every operation should immediately jump from prompt to execution.

Could VS Code become the new SFMC interface?

This is where things become particularly interesting for developers.

Imagine working entirely from an AI coding agent inside VS Code.

You could potentially say:

"Find all Data Extensions containing IndividualID."

Then:

"Compare their schemas."

Then:

"Generate a SQL query that identifies duplicates."

Then:

"Create a temporary Data Extension for the output."

Then:

"Create the query activity."

Then:

"Run it and summarise the results."

Historically this type of workflow required jumping between the IDE, Marketing Cloud UI, Postman, documentation and query tools.

MCP can potentially connect these environments.

The developer remains responsible for the solution.

But the AI handles more of the operational friction.

The future may be UI optional

Salesforce applications are not going away.

Business users will continue to need strong graphical interfaces.

But developers and AI agents may increasingly interact with Salesforce without opening those interfaces.

That is what makes the word "Headless" important.

Salesforce becomes less about:

Where do I click?

and more about:

What trusted capability do I want to invoke?

This allows Salesforce functionality to appear inside completely different environments.

For example:

VS Code
ChatGPT-style interfaces
Internal company assistants
Slack
Custom portals
Mobile applications
Automated AI agents

The Salesforce UI becomes one possible interface rather than the only interface.

My view

MCP may become one of the most important changes to Salesforce development since the broader adoption of APIs.

Not because MCP replaces APIs.

It doesn't.

Its importance comes from creating a standard interface between AI agents and enterprise capabilities.

For Marketing Cloud specifically, the combination of:

MCP + Headless 360 + Data 360 + Agentforce + Marketing Cloud

could eventually create an environment where developers spend significantly less time navigating interfaces and significantly more time designing data models, automation architecture, permissions and business logic.

That is a positive shift.

The best Salesforce developers of the next few years may not be the people who memorise the largest number of screens.

They will be the developers who understand how Salesforce capabilities, customer data, AI agents and enterprise governance fit together.

Final thought

We spent the last decade making enterprise software API-first.

The next phase may be making enterprise software agent-first.

And Salesforce's Headless 360 and MCP strategy gives us an early look at what that future could look like.

For SFMC developers, now is probably the right time to start learning MCP.

Not because traditional Marketing Cloud development is disappearing tomorrow.

But because the interface through which we develop and operate Marketing Cloud is beginning to change.

Salesforce Headless 360 & MCP: The Beginning of AI-Native Marketing Cloud Development