MCP Server in SFMC vs QAiry: Why a Metadata-Only Architecture Is Safer

With the Summer '26 release, Salesforce Marketing Cloud Engagement (SFMC Engagement) opens access to MCP Servers — the Model Context Protocol standard from Anthropic that lets AI assistants like Claude or Gemini drive SFMC through natural language. A strategic step forward for automation and data exploration, but one that raises concrete questions on the security and compliance side. In this article, we compare the MCP Server architecture with QAiry, the AppExchange-listed AI assistant built natively for SFMC Engagement, to explain why a metadata-only approach materially reduces the exposure surface for marketing teams operating under GDPR or stricter enterprise governance.

What MCP Server really changes in SFMC Engagement

A few steps in SFMC (create an Installed Package, set up an API Integration of type Public App, capture a Client ID and a Tenant ID) and a client like Gemini CLI or Claude Code can connect to the Salesforce mai-mce-mcp-cdp1 endpoint (US or EU) and call MCP tools — create Data Extensions, identify journeys, inspect emails, manipulate automations.

The flow looks like this:

User ──prompt──> Claude / Gemini ──MCP──> Salesforce MCP Server │ ▼ SFMC Engagement APIs │ ▼ Data Extensions, Journeys,Subscribers, Activities, etc.‍

The upside is immediate: an SFMC operator drives the platform in natural language and automates repetitive work. But that productivity gain comes with a structural shift in the exposure surface that deserves a careful read.

Three blind spots worth confronting

1. Where does your data actually travel?

With the MCP Server, the external AI (Claude, Gemini) receives responses from the SFMC APIs so it can act on them. Depending on the tools called — for example retrieveSubscribers or queryDataExtension — those responses may include personal data: email addresses, identifiers, profile attributes, campaign content. That data leaves the Marketing Cloud environment and is processed by a third-party LLM provider — typically in the United States (Anthropic, Google) — which immediately reopens the Schrems II conversation and the risk of personal data transfers outside the EU.

QAiry, in contrast, runs on a principle clearly stated on its security and privacy page: the AI only sees metadata — Data Extension names, field names, field types. No subscriber record is exported. The SQL it generates runs inside SFMC via Query Activities. Customer data never leaves the Salesforce environment.

The difference is architectural, not philosophical: with MCP Server, the AI sits downstream of the data; with QAiry, the AI stays upstream. That inversion changes everything for compliance teams.

2. Who did what, and how do you prove it?

Auditing an action triggered through MCP Server means correlating at least three logs: the prompt log on the Claude or Gemini side (often not retained), the OAuth log of the Installed Package, and the API call log on the SFMC side. The link between the natural-language intent and the executed action is not native — you have to reconstruct it.

QAiry retains user prompts inside its own perimeter for explicit traceability purposes. Authentication is handled via SFMC SSO, with no separate credentials to provision or revoke. The chain "SFMC user → prompt → SQL → execution inside SFMC" stays linear and auditable end-to-end.

3. What does the AI actually have permission to do?

The tutorial wisely flags: "Do not grant more permissions to AI than necessary." That is the right reflex — but it depends entirely on the discipline of whoever configures the Installed Package. SFMC OAuth scopes remain fairly broad: Data Extensions Read/Write, Automations Read/Write, and so on. Once write permission is granted, the AI can technically create or change any object in that category.

QAiry exposes a more granular permission model: scopes can be tailored per deployment — for instance allowing Query Activity creation while disabling Automation creation. For a governance team, that is the difference between one master key and a use-case-specific keyring.

Independent validation: AppExchange or nothing

The Salesforce MCP Server is a native SFMC capability; its server-side security is owned by Salesforce. But the weak link is rarely the server — it is the client-side ecosystem. Claude Code, Gemini CLI, third-party MCP plugins, the user's environment (personal device, BYOD, screen sharing) are not covered by any Salesforce security review.

QAiry is listed on the AppExchange. That means it has passed the Salesforce Security Review: OWASP-based automated scans, manual penetration testing (SQL injection, XSS, authentication weaknesses), and periodic re-checks required to remain listed. That is not a marketing badge — it is a continuous obligation, controlled by an independent third party. For a procurement or IT security team, it is a concrete maturity signal.

Hosting and data residency

The MCP Server endpoint exists in two variants (US sfdc-yfeipo and EU sfdc-yzvdd4), but the residency of the data ultimately processed by the AI depends on the LLM vendor. If you call Claude via the Anthropic API from the EU, your prompts and tool outputs transit through Anthropic infrastructure in the United States. Same story with Gemini.

QAiry is hosted by default on AWS Paris (eu-west-3), with encryption in transit and at rest, and region-specific deployments available on request. Subscriber data, for its part, never leaves SFMC — so even the cross-border transit question is moot for customer records. The GDPR documentation effort drops significantly.

Operational risk: when the AI hallucinates in production

LLMs make mistakes. The tutorial actually surfaces one inadvertently: when creating a Data Extension via Gemini, the EmailAddress field became required even though the user did not ask for it. On a sandbox, that is a footnote. In production, the same class of error on a transactional routing Automation could block critical sends.

MCP Server adds no business-level guardrail: if the AI calls a write tool, the write happens. QAiry reduces that risk structurally — the AI does not propose destructive operations on customer data, it generates SQL that runs inside the usual SFMC sandbox with the same guardrails you already apply to Query Activities today.

How to pick depending on your context

MCP Server for SFMC is not "dangerous"; it is a powerful capability that fits certain contexts well — advanced technical teams, sandbox environments, exploring AI use cases. QAiry targets a different need: making AI usable in production by marketing teams, while meeting enterprise governance constraints.

A quick decision frame: if you handle personal data under GDPR, if your DPO requires a complete map of out-of-EU transfers, or if your internal audits demand evidence of independent security review, QAiry's metadata-only architecture will give you a compliance file that is significantly easier to defend than the "MCP Server + external LLM" combination.

Key takeaways

1. MCP Server exposes subscriber data to a third-party LLM. SFMC API responses flow through Claude or Gemini, reopening the Schrems II question.

2. QAiry is metadata-only. The AI sees only field names and types; SQL runs inside SFMC, customer data stays put.

3. AppExchange means independent validation. QAiry has passed the Salesforce Security Review and must maintain it. MCP Server does not cover the client-side chain.

4. Granular vs broad scopes. QAiry tailors permissions per deployment; OAuth scopes on an Installed Package tend to stay global.

5. EU hosting by default. AWS Paris for QAiry vs LLM-vendor-dependent residency on the MCP Server side.

Evaluating MCP Server for SFMC and want to position QAiry in your AI roadmap with a solid compliance file? Let's talk through your context. CGC-Agency supports marketing operations teams on the evaluation, deployment and governance of AI assistants for Salesforce Marketing Cloud.