What Is MCP (Model Context Protocol), and Why Martech and CRM Vendors Ship MCP Servers

An MCP server is a program that exposes tools, data and prompt templates to AI applications through the Model Context Protocol (MCP), an open standard Anthropic released in November 2024 and donated to the Linux Foundation's Agentic AI Foundation in December 2025. Martech and CRM vendors ship MCP servers so one integration works with many AI clients, including for a customer data platform (CDP).

Who this is for: architects, security leads and marketing-operations owners who are being asked whether to connect an AI assistant to Salesforce, HubSpot or a customer data platform. You will get the protocol model, a vendor table checked against official documentation on 17 October 2026, the security risks with mitigations, and an evaluation checklist. Part of the AI hub.

Model Context Protocol explained

The MCP documentation describes the protocol as an open-source standard for connecting AI applications to external systems such as files, databases, tools and specialized prompts, and compares it to a USB-C port for AI applications 3. Before it, each assistant needed its own connector for each system. With MCP a vendor builds one server and any compliant client can use it.

• Origin. Anthropic open-sourced MCP on 25 November 2024 with a specification, SDKs and reference servers for systems such as Google Drive, Slack, GitHub and Postgres 1.
• Governance. On 9 December 2025 Anthropic donated MCP to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI, with Google, Microsoft, AWS, Cloudflare and Bloomberg as supporters. Anthropic said the governance model would remain unchanged and cited more than 10,000 active public servers 2. The project's governance page describes it as a series of LF Projects, LLC, with maintainers, core maintainers and lead maintainers deciding through public proposals 4.
• Adoption. The project lists Claude, ChatGPT, Visual Studio Code and Cursor among the clients that support it 3.

How MCP works: hosts, clients, servers, tools

The specification uses JSON-RPC 2.0 messages between three roles: hosts (the AI application that starts connections), clients (connectors inside the host) and servers (services that provide context and capabilities) 5.

Sampling, roots and logging remain in the specification but are deprecated for new implementations 8.

The July 2026 revision changed the wire protocol

The current specification revision is dated 2026-07-28. Compared with 2025-11-25 it removes protocol-level sessions and the initialize handshake. Every request now carries its protocol version and client capabilities, servers must implement a server/discover call, and server-initiated requests are replaced by a multi round-trip pattern 8. A client that speaks only the new revision fails against a legacy server, while a dual-era client works with both 9. Servers built in 2025 therefore target earlier revisions. When you evaluate a vendor server, ask which revisions it supports and whether your client needs a fallback.

Transports and authorization

Authorization is optional in the specification, but HTTP-based implementations that support it should follow it. The rules that matter most for buyers 7:

• The MCP server acts as an OAuth 2.1 resource server (the specification cites an IETF draft of OAuth 2.1).
• Servers must publish OAuth 2.0 Protected Resource Metadata (RFC 9728) and clients must use it to find the authorization server.
• Clients must send a resource parameter (RFC 8707) naming the MCP server in both authorization and token requests, and use PKCE.
• Servers must validate that tokens were issued for them as the audience, and must not accept or pass on other tokens.
• Client registration prefers Client ID Metadata Documents; Dynamic Client Registration is deprecated but still allowed for compatibility 78.
• When a token lacks scope, servers should answer 403 with insufficient_scope, and clients can request a step-up.

Why martech and CRM vendors ship MCP servers

Three reasons are visible in vendor documentation. One integration serves many clients instead of a plug-in per assistant 3. Users already work inside AI assistants, so vendors want CRM and marketing data reachable there; Salesforce points to its customers' users working in Slack, Claude, ChatGPT and other clients 12. And a server lets the vendor define exactly which operations an agent may call, which is easier to govern than open API access 12. A fourth reason is our reading rather than a vendor statement: a platform that agents cannot call risks being bypassed by one they can.

Vendor servers checked on 17 October 2026

What a customer data platform MCP server exposes

A server for a customer data platform (CDP) is useful when it exposes decisions-grade context without exposing the whole warehouse. Vendors describe the range: Amperity lists databases, queries, identity resolution and campaigns 24; Salesforce's Data 360 server queries unified customer data 13; Tealium's Context API serves profile state, audiences and consent 22. A defensible default set looks like this.

PrivyCDP positions its AI operational layer as MCP-ready, with human oversight and every AI-assisted action logged in an append-only audit ledger. The architecture is covered in running AI agents on customer data without leaving your boundary. For the underlying components see customer data platform architecture.

MCP security risks and mitigations

The specification says tools should be treated as arbitrary code execution, and that tool annotations are untrusted unless they come from a trusted server 5. It also says servers must validate inputs, enforce access controls, rate-limit and sanitize outputs, while clients should ask for confirmation on sensitive operations, show tool inputs before calling, validate results, set timeouts and log tool usage 10.

A vendor-evaluation checklist

1. Protocol: which specification revisions and transports are supported, and is there a fallback for older clients?
2. Authentication: OAuth with protected-resource metadata and audience-bound tokens, not shared static keys?
3. Identity: do calls run as the individual user, under the vendor's own permission model?
4. Granularity: separate read, write and delete tools, with a read-only mode and the ability to disable groups?
5. Default state: disabled until an admin enables it, with an organization-wide switch?
6. Sensitive tools: which tools return personal or user-generated data, and can you turn them off?
7. Writes: draft versus publish, confirmation for destructive actions, a dry run?
8. Audit: are calls logged with user, tool and parameters, and can you export them to your SIEM?
9. Data handling: where does returned data go next (that is your client's behaviour), and does the vendor retain or train on it?
10. Maturity: generally available or beta, a deprecation policy, and notice before tool descriptions change?
11. Evidence: penetration tests, tenant-isolation tests, a disclosure process, incident history?
12. Regulatory fit: does your BAA or DPA cover the MCP service, and can you pin its data region (Amplitude offers an EU endpoint 20)?

---

If you want to see how an MCP-ready AI layer, scoped tools and an append-only audit ledger fit together on a single-tenant deployment, the PrivyCDP team can walk you through it technically on /cdp. More guides are in the AI hub, and security details are on the security page.

Test the consent boundary with synthetic data

Download the iAge consent-aware MCP reference source and example event schema. It runs against two synthetic fixtures, requires process-owned permission and purpose consent, and exposes no production customer-data endpoint. The included SDK stub requires a reviewed release-specific adapter; it does not invent a PrivyCDP API contract.