In April 2025, Tealium did something that did not make most marketing headlines. It shipped an MCP server. Within a year, Amperity, Salesforce, Hightouch and a long list of others had done the same or announced they would. If you do not work in data engineering, that sentence may read as noise. It is not. It is one of the more consequential changes to how a customer data platform fits into a stack, and it deserves a plain explanation.
This post is about what it means that CDP and customer-data vendors have started shipping MCP servers. The short version: your CDP is becoming something an AI agent can call directly, the way it might call a weather API. That changes how the stack is designed, and it raises a real governance question, because the thing now holding a key to your customer profile is software that acts on its own.
What an MCP server actually is
MCP stands for Model Context Protocol. Anthropic introduced it in November 2024 as an open standard, and the idea behind it is unglamorous and useful.
Think about the problem it solves. You have AI assistants and agents on one side. You have systems full of data and capability on the other: a CRM, a warehouse, a ticketing tool, a CDP. Before MCP, connecting any agent to any system meant a custom integration, written once and maintained forever. Ten agents and a hundred systems is, in the worst case, a thousand bespoke connectors. Engineers called this the M times N problem, and it was a genuine drag on building anything with agents.
MCP collapses that. A system exposes its data and actions through one MCP server, built to a shared specification. Any agent that speaks MCP can then use it, with no integration written for that specific pairing. Build the server once, build the client once, and they interoperate. The protocol was successful enough that OpenAI adopted it in March 2025 and Google DeepMind followed in April. In December 2025, Anthropic donated MCP to a new Linux Foundation body, the Agentic AI Foundation, so it is now neutral, open infrastructure rather than one company's project.
An MCP server is not magic and not large. It is a small adapter that advertises three kinds of thing to an agent. Tools are actions the agent can take. Resources are data the agent can read. Prompts are reusable instructions. An agent connects, asks the server what it offers, and then reads and acts through it. That is the whole mechanism. Keep that picture, because the interesting part is what happens when the system on the other end is your customer data.
What a CDP's MCP server exposes
A CDP exists to hold a unified customer profile: identity stitched across devices, behavioural history, segment membership, predictive scores. For fifteen years the way to get at that was a human logging into a dashboard or an engineer wiring up the CDP's API. An MCP server adds a third door, and the one built for agents.
Look at what the early ones actually expose, because the specifics matter more than the marketing. Tealium's MCP integration, announced in April 2025, connects through its Moments API to deliver real-time, consented visitor data to AI models and agents. Tealium later added a fully managed MCP server so customers do not have to stand up the infrastructure themselves. Amperity's MCP server, in private preview as of its May 2026 release, gives AI applications live access to identity-resolved profiles, segment membership and behavioural signals, queried in place rather than exported. Salesforce went furthest in scope. Its Data 360 MCP server, released in developer preview in May 2026, wraps roughly 200 API operations and lets an agent run SQL queries, query profiles and calculated insights, build and publish audience segments, work with the semantic model, and trigger activation to external platforms.
Read those together and a pattern appears. A CDP's MCP server typically exposes three layers, each a step more powerful than the last.
First, profiles and lookups. The agent can ask for a specific customer's unified record: who they are, what they have done, what segments they sit in, what their churn or value score is. This is read access to the thing the CDP exists to assemble.
Second, queries and segments. The agent can ask questions across the whole customer base, build a segment from a description, and read back the population. This is the analyst's job, available to software.
Third, and not always present, actions. The agent can publish a segment, trigger an activation, push an audience to an ad platform or an email tool. This is where the server stops being a window and becomes a hand.
The distance between layer one and layer three is the entire governance story, and we will come back to it. A read-only server is a careful first step. A server that exposes actions is handing an agent the ability to do things to real customers.
Why CDP vendors built them
Vendors did not ship MCP servers out of fashion, though fashion played a part. There are two solid reasons.
The first is that the CDP's own customers are building agents and want the customer profile inside them. A support agent answering a ticket is far more useful if it can see purchase history, loyalty status and recent campaign exposure without a human switching tabs. A marketing agent investigating a soft segment needs to query the CDP to do its job. Before MCP, every one of those agents needed a custom connector to the CDP. The MCP server means the vendor builds that bridge once and every customer's agents can cross it. It is a way to stay relevant inside a workflow that increasingly runs through an AI assistant rather than the vendor's own screen.
The second reason is defensive, and Salesforce was unusually candid about it. When it introduced MCP support across its platform in 2025, the framing was clear: if Salesforce did not provide a sanctioned MCP server, customers would build their own homegrown ones to reach the data anyway, with less oversight and less consistency. Shipping an official server is partly about meeting demand and partly about controlling how that demand gets met. Better an audited front door than a dozen side windows.
There is also a market signal underneath all this. Forrester predicted that 30 percent of enterprise application vendors would launch their own MCP servers during 2026. The public registry of MCP servers grew from roughly 1,200 in early 2025 to over 9,400 by April 2026. A CDP without an MCP server is starting to look like a CDP without an API looked a decade ago: technically fine, strategically behind.
What this changes for stack design
Here is the part worth slowing down on, because it is the real shift.
For most of its history the CDP has been a destination. You designed the stack as a set of tools, each with its own interface, and the CDP was one of them: the place marketers went to build segments and journeys. The mental model was a tower of applications, each doing a job, wired together by data pipelines.
An MCP server reframes the CDP as a service. It is no longer primarily a thing you log into. It is a capability that other software calls when it needs customer context or needs to act on a customer. The CDP becomes, in effect, the customer-data function of an agent layer rather than a standalone product with a front end.
This connects to a debate already running in the CDP market about whether the platform's value is shifting from being a system of record to being a system of context: less a vault you store data in, more a service that hands decision-ready context to whatever needs it. The MCP server is the concrete plumbing that makes the system-of-context idea real. It is the socket the agent plugs into.
For anyone designing a stack, the practical consequences are specific. The CDP's interface is no longer mainly its UI; it is its MCP server, and the quality of that server, what it exposes, how fast it responds, how well it is documented, becomes a real selection criterion. The CDP also stops being the only thing an agent talks to. An agent might hold MCP connections to the CDP for customer context, the warehouse for deeper history, the ESP for sending, and a product catalogue, and stitch them together itself. That is powerful, and it quietly moves orchestration logic out of any single platform and into the agent. The tower flattens. Fewer screens, more services, with an agent in the middle deciding which to call.
The governance question nobody should skip
An MCP server over a customer data platform is, stated bluntly, a standardised way to give an AI agent a key to your customer profile. That is the benefit and the hazard in one sentence.
Start with the protocol's own weak spots. Security researchers spent 2025 documenting them. The original MCP specification shipped without a mandatory authentication framework and assumed servers were benign. Known attack classes include prompt injection, where hidden instructions in data the agent reads cause it to act against intent; tool poisoning, where a malicious tool description manipulates the agent; and lookalike tools that quietly impersonate trusted ones. These are not theoretical. CVE-2025-6514, a critical command-injection flaw in mcp-remote, a widely used MCP proxy with hundreds of thousands of downloads, showed the supply-chain dimension, and one scan found hundreds of publicly exposed servers lacking basic authentication. The protocol is maturing fast, but it is young, and customer data is the wrong place to be an early casualty.
Now layer on what is specific to customer data. Three questions matter.
Who is the agent acting as? The strongest pattern here is that every request through the MCP server is tied to a real, permissioned human identity, not a shared service account or a static API key. Amperity, for example, authenticates through the user's existing identity, so an agent can only reach what that person could reach in the application itself, with the same role-based controls and consent rules. That is the right default. A server that uses one all-powerful key for every agent has thrown away your access model.
Does consent travel with the data? A customer who opted out of marketing has not opted into being processed by an autonomous agent. Consent and preference state has to be enforced at the point the agent reads the profile, not assumed. This gap is real enough that a market is forming around it: in January 2026 the privacy firm Usercentrics acquired a startup called MCP Manager specifically to build a consent and policy enforcement layer for MCP traffic, on the logic that an agent reaching CRM data without a consent check is exactly the failure regulators will ask about.
Can you audit what the agent did? A human pulling a report leaves a thin trail and acts at human speed. An agent can query thousands of profiles and trigger activations in seconds. If your CDP's MCP server does not log every action against an identity in a form you can review, you cannot answer a regulator, and you cannot debug the agent when it does something wrong, which it will.
The hardest case is the action layer. A read-only MCP server, badly secured, leaks data, which is serious. A server exposing activation, badly secured or simply driven by a confused agent, sends real messages to real customers, suppresses the wrong audience, or pushes the wrong segment to an ad platform. The convenience of letting an agent act is genuine. So is the blast radius. The sober approach is to treat read access and action access as separate decisions, gate the action layer hard, keep a human approving anything consumer-facing until trust is earned, and never assume the agent will be as cautious as a person. An agent does exactly what it infers it was asked to do, at full speed, with no instinct that something feels off.
Hype versus substance
So is this real, or is it 2026's badge that vendors pin on to look current? Honestly, both, and it is worth separating them.
The hype is loud. MCP raced through its hype cycle, and for a stretch every vendor wanted an MCP announcement whether or not it changed anything. Plenty of "MCP servers" are thin wrappers around an existing API that an agent could already have called, dressed up as a strategic capability. A CDP press release with MCP in the headline tells you almost nothing on its own.
The substance is also real, and it is this. A genuine, well-built MCP server over a CDP does change the architecture. It makes the customer profile callable by agents through a shared standard instead of a bespoke integration, which lowers the cost of building agentic workflows from significant to near zero. That is not nothing. It is the difference between agents being a project and agents being a default. The vendors moving carefully, tying access to real identities, preserving consent, logging actions, gating the action layer, are doing real work, not theatre.
The honest read: the protocol is sound and the direction is correct, but the value is entirely in the execution. An MCP server is a door. A door is useful. A door is also a door, and the questions that matter are who you let through it, what is on the other side, and whether you can see who came and went. Judge a CDP's MCP server on those answers, not on the fact that it exists. By next year, existing will be table stakes. Doing it safely will not.
Council summary
This post argues that when a CDP ships an MCP server it stops being a dashboard people log into and becomes a service agents call directly, which reframes the platform from a destination into a system of context. The council verified the named launches against primary sources: Tealium's Moments API integration on April 8, 2025, Amperity's MCP server in private preview in its Spring 2026 release, and Salesforce's Data 360 MCP server in developer preview in May 2026. It also confirmed the Usercentrics acquisition of MCP Manager announced in January 2026, the December 2025 donation of MCP to the Linux Foundation's Agentic AI Foundation, and Forrester's prediction that 30 percent of enterprise app vendors will launch MCP servers. The one figure we softened was the CVE-2025-6514 download count, since published reports vary. The takeaway for a stack owner is plain: an MCP server is a door to your customer profile, so judge it on identity-scoped access, consent enforcement, and auditable logging, and gate the action layer hard.
Comments