Marketing Cloud MCP
What the Marketing Cloud Engagement MCP Server does, and proposed controlled helpers for docs, AMPscript and SQL explanation, validation and checklists.
Marketing Cloud teams spend much of their time explaining, checking and documenting: why an AMPscript block fails, what a SQL query activity does, how a journey routes people. MCP can help, but only with clear limits. Salesforce's own server for Marketing Cloud Engagement is live, so this page starts there and then describes proposed helpers for the work it does not cover.
The official server: Marketing Cloud Engagement MCP Server
Salesforce announced on 2 June 2026 that "The MCP Server for Marketing Cloud Engagement is Now GA". It is a first-party hosted server. Salesforce's Winter '27 materials list it with 40 tools. According to Salesforce's sources:
- It reads and writes, covering data extensions, journeys (created in Draft), automations and query activities, and transactional sends.
- Destructive tools are annotated, and a Salesforce marketing blog (29 May 2026) mentions dry-run modes and flagging of destructive operations.
- Setup uses an Installed Package with an API Integration (Public App) component and user OAuth. Effective rights equal the package scopes intersected with the user's permissions.
- US and EU endpoints are tenant- and client-specific.
Marketing Cloud Next: no official MCP server specific to Marketing Cloud Next was found. Salesforce's 29 May blog describes pushing work to Next only as a future bridge.
What we would add, and why
We evaluate the vendor server first. It acts on the objects the user's package scopes and permissions allow, so it is the right path for reading journey metadata or saving a draft. It does not hold your team's standards, and nobody should treat it as a way to run untested code. For those gaps we propose a small read-only helper server. This is a proposed design; we validate the APIs, edition and permissions for each implementation. It does not exist as a product, and it never implies access to every asset: it sees only what the user passes in or what the vendor server returns under that user's rights.
Marketing Cloud MCP with controlled helpers: proposed design
Proposed design: to be validated for each implementation
Select a component to see what it is responsible for and how data moves to and from it.
Components and data flows (text version)
| Component | Type | Responsibility |
|---|---|---|
| Marketer or developerworks in an AI client | People | Asks for explanations, validation and drafts, and decides what is saved. |
| Reviewerapproves saved changes | People | Approves any change saved to Marketing Cloud, such as a draft journey or an edited data extension. |
| MCP hostAI client | AI and agents | Connects to both servers with separate clients and holds write calls until a reviewer confirms them. |
| Engagement MCP Servervendor-run, GA 2 Jun 2026 | Salesforce product | Salesforce's first-party hosted server, GA 2 Jun 2026. Rights equal the package scopes intersected with the user's permissions. |
| Marketing helper serverproposed, read-only | Integration layer | Proposed GeekMidst server for docs search, explanation, validation and checklists. It holds no Marketing Cloud credentials. |
| Engagement tenantyour business units | Salesforce product | Data extensions, journeys, automations, query activities and transactional sends, reached only through the vendor server. |
| Approved documentationcurated index | Data and analytics | Your standards, naming rules and selected vendor references, chosen and versioned by your team. |
| Safe parserparse only, no execution | Identity, policy and governance | Parses AMPscript and SQL text and reports structure and issues. It never executes code or runs queries. |
Data flows
- Marketer or developer → MCP host: requests. Explanations and validation run directly; anything that saves to Marketing Cloud waits for review.
- Reviewer → MCP host: approve change. The reviewer sees the exact object and change before the call is sent.
- MCP host → Engagement MCP Server: user OAuth tool calls. Installed Package with an API Integration (Public App) component; US and EU endpoints are tenant-specific.
- MCP host → Marketing helper server: read-only tool calls. Script text and questions go in; explanations and findings come out.
- Engagement MCP Server → Engagement tenant: scoped API access. Journeys are created in Draft. Destructive tools are annotated so the host can warn or block.
- Marketing helper server → Approved documentation: search. Returns cited passages from the approved index only.
- Marketing helper server → Safe parser: validate text. Parse errors come back as findings; a parser failure returns a tool error, not a pass.
Proposed controlled capabilities
| Capability | Data source | Permission model | Prerequisites | Execution boundary |
|---|---|---|---|---|
| Search approved docs | A curated index of your standards and chosen vendor references | Anyone in the pilot group | Docs selected and owned by your team | Returns cited passages only |
| Explain AMPscript or SQL | Code text the user pastes or opens | User's own access to that code | None beyond the helper | Explains; never executes |
| Validate scripts | Code text sent to a safe parser | Same as above | Parser rules agreed for your dialect use | Parses only; no send, no query run |
| Generate drafts for review | User's brief plus approved docs | Draft returned to the user | Brand and naming rules in the index | Saving is a separate, approved vendor-server call |
| Explain journey designs | Journey metadata the vendor server returns | User OAuth: package scopes intersected with user permissions | Engagement MCP Server enabled | Read only; no activation |
| Deployment checklists | Approved docs plus the change described | Pilot group | A checklist template you agree | Produces a checklist; deploys nothing |
Proposed tool catalogue
| Tool | Purpose | Read/write | Approval needed |
|---|---|---|---|
| search_docs (helper) | Find cited passages in approved documentation | Read | No |
| explain_code (helper) | Explain an AMPscript block or SQL query in plain words | Read | No |
| validate_code (helper) | Report syntax issues and risky patterns from a parse | Read | No |
| draft_content (helper) | Return a draft AMPscript block or query for review | Read (returns a draft) | Person reviews |
| explain_journey (vendor read tools) | Describe entry, splits and exits from journey metadata | Read | No |
| deployment_checklist (helper) | List checks for a planned change | Read | No |
| Save a draft journey or edit a data extension (vendor write tools) | Persist an agreed change | Write | Yes, named reviewer |
| Transactional send (vendor tool) | Send a message | Write | Not enabled in this design |
Authentication and access control
The vendor server uses user OAuth through your Installed Package, so scope the package narrowly and use a business unit with test data for the pilot. The helper server holds no Marketing Cloud credentials and needs none; if it is hosted on your infrastructure, it is protected as an OAuth 2.1 resource server under the MCP authorization spec, with tokens issued for it alone.
Read and write operations, and approvals
The helper is read-only, and its tools are annotated readOnlyHint: true. Vendor write tools need a named reviewer, and destructive tools are blocked in the host where possible. Journeys created through the server start in Draft; activation stays a human step in Journey Builder, as covered in testing journeys before activation.
Privacy, limits and auditability
Prefer metadata and code over subscriber rows; if a query result must be shown, use test data. Check with your legal adviser on the data protection rules that apply to you. API limits for the vendor server are not stated in our sources, so check Salesforce's limits. Platform limits still apply to what the AI drafts: a SQL query activity times out after 30 minutes and is deactivated after 24 consecutive failures, so checklists include runtime checks. Log every helper call with tool, outcome and time, but not script contents.
Errors, environments and testing
Parser failures return isError: true with a reason, never a silent pass. Use a sandbox or test business unit first, test with the MCP Inspector CLI, and include scripts known to be broken so validation is proven to fail when it should. For script patterns, see AMPscript development and Marketing Cloud SQL development.
Licensing and dependencies
The vendor server needs Marketing Cloud Engagement and an Installed Package; confirm any further entitlements with Salesforce.
Available today vs proposed
| Item | Status |
|---|---|
| Marketing Cloud Engagement MCP Server | GA 2 Jun 2026 (Salesforce) |
| Marketing Cloud Next MCP server | None found |
| GeekMidst Marketing helper server | Proposed design |
Related
Marketing Cloud architecture
How Engagement components fit together
→Marketing Cloud consulting
Strategy, build and optimisation
→AMPscript Studio MCP proposal
How our AMPscript workspace could connect to AI clients
→MCP integration overview
All vendor servers and their status
→MCP server development
Building servers for real gaps
→Questions we hear
Is there an official Marketing Cloud MCP server?
Can an AI activate a journey through MCP?
Does the helper run our AMPscript?
Can the AI see every data extension?
Sources
Review your Marketing Cloud MCP plan
Tell us what your team spends time explaining and checking. We can scope the vendor server set-up and a read-only helper with you.
