TL;DR bullets
- A Salesforce MCP server exposes Salesforce capabilities — records, metadata, flows, deploys — to AI agents like Claude, Cursor, and Agentforce through Anthropic's open Model Context Protocol, replacing bespoke API integrations with one standard handshake.
- There are five flavors in active use: the Salesforce DX MCP Server (for IDE developers), Hosted MCP Servers (for remote production agents), ecosystem servers (Heroku, MuleSoft, Mobile), Agentforce-as-MCP-client, and community-built servers — each solving a different problem.
- The protocol is the easy part. What the keynotes skip: an agent only knows what the MCP tools return, and Salesforce tools return fields and flows without the institutional context to make sense of them — which is where most "confidently wrong" AI mistakes come from.
******
If you've watched an AI demo in the last six months (and of course, you have) perhaps you’ve seen someone tell Claude to "update the opportunity stage on the Acme deal," and Claude actually does it.
That's MCP doing the work.
A Salesforce MCP server is a piece of software that exposes Salesforce capabilities (records, metadata, flows, Apex, deploys) to AI agents through the Model Context Protocol. The agent — Claude, Cursor, Agentforce, ChatGPT, whatever — sends a structured request. The server translates it into a Salesforce API call. Salesforce responds. The agent gets back something it can reason over.
That's the magic trick. Everything else is implementation detail razzle-dazzle.
But the implementation details are where most teams get tripped up, because "a Salesforce MCP server" is now a category, not a product. There are at least five flavors in active use, each solving a different problem. Here's how to think about it.
First, what MCP actually is
Model Context Protocol is an open standard, originally released by Anthropic, that defines how AI applications talk to external tools and data sources. Salesforce, in its own docs, calls it "USB-C for AI" — a single, well-defined handshake that any compatible client (host) can use to discover and call capabilities (tools), pull in data (resources), and follow templates (prompts) from any compatible server.
The architecture is actually in three parts:
- Host — the AI app you're using (Claude Desktop, Cursor, Agentforce, ChatGPT in developer mode)
- Client — the bit inside the host that handles the MCP connection
- Server — the thing that actually does the work against the external system
Before MCP, hooking an AI assistant up to Salesforce meant writing a custom wrapper around the REST API, managing auth yourself, and praying the model knew what to do with the response. MCP collapses all of that into a standard protocol. Build the server once. Any MCP-aware AI client can use it.
That standardization is why "Salesforce MCP server" is suddenly something every architect is being asked about.
The five flavors of Salesforce MCP server
When someone says "Salesforce MCP server," they could mean any of the following. And unfortunately for brevity, the differences do matter.
1. The Salesforce DX MCP Server
This is the official server for developers built by the Salesforce CLI team. It runs locally (or in your IDE) and ships with 60+ tools across toolsets like orgs, metadata, data, users, and code-analyzer. You authorize it against specific orgs, pick the toolsets you need, and now Claude Code or Cursor can deploy components, run Apex tests, create scratch orgs, and query records — by prompt.
Use case: a Salesforce developer who wants to vibe-code in their IDE without alt-tabbing into Workbench. Currently in beta/developer preview.
2. Salesforce Hosted MCP Servers (Platform)
Hosted directly by Salesforce, these expose targeted APIs without making you install anything locally. There are 11+ endpoints currently in pilot — sobject-all, sobject-reads, invocable-actions, flows, data-360, prompt-builder, tableau-next, and a few more. Auth runs through OAuth with PKCE on an External Client App.
Use case: production AI workflows that need to hit Salesforce from a remote client like Claude (web), ChatGPT, or a custom agent — no CLI required.
3. The wider Salesforce-ecosystem MCPs
Salesforce has shipped MCP servers for a chunk of its portfolio:
- Heroku MCP (GA) — manage apps, dynos, add-ons
- MuleSoft MCP (GA) — design and deploy integrations
- Mobile MCP (Developer Preview, January 2026) — generate native mobile code with Mobile SDK
These aren't what you’d call "Salesforce CRM" MCPs in the strict sense, but if you live in the Salesforce universe, they show up in the same conversation with relative frequency.
4. Agentforce as an MCP client (and the registry)
This one trips people up. Agentforce isn't just a thing that gets connected to via MCP — Agentforce is also a host that can consume external MCP servers. As of the July 2025 release, Agentforce includes a native MCP client, and Salesforce runs an enterprise-grade MCP server registry through AgentExchange for governing which servers are trusted, what tools they expose, and how they're rate-limited.
Translation: your Agentforce agents can call out to any MCP-compliant server — yours, a partner's, an open-source one — without bespoke integration code. The registry is the policy layer on top.
5. Community and partner servers
Then there's the long tail. Open-source projects like mcp-salesforce-connector (SOQL/SOSL/Tooling API/Apex REST), Uday's salesforce-mcp (lightweight CRUD via jsforce), and a growing list of vendor-built servers that expose specific platform capabilities. Some are great. Some are abandoned. Read the source before you point a production agent at one.
Why this matters now (Headless 360, etc.)
At TrailblazerDX 2026, Salesforce announced Headless 360 — a suite of tools designed to let agents do everything in Salesforce without ever opening a browser. The headline number was 60+ new hosted MCP tools and 30+ new skills.
Parker Harris's quote was the tell: "Why should you ever log into Salesforce again?"
A real strategic posture, it would seem. Salesforce is betting that a meaningful portion of admin and developer work — and eventually end-user work — will happen through AI agents calling MCP tools, not through clicks in Setup. Whether the bet plays out on their timeline or not, the direction is set and time will tell, as it always does.
For anyone responsible for a Salesforce org, this means MCP is no longer a "cool thing to play with on a weekend." It's a config surface you'll be governing, and you’ll certainly need to understand it.
What you can actually do with one
A few patterns that are working in the wild today:
- Natural-language SOQL. "Show me every Closed Won opp from EMEA last quarter with no associated case." The agent translates intent into SOQL, hits the server, brings back the answer.
- Moment-in-time metadata exploration. "What fields on Account drive routing in our flows?" — the agent walks dependencies through the metadata tools.
- Deploys and tests from the IDE. Cursor or Claude Code can deploy components, run Apex tests, and surface failures inline.
- Cross-system reasoning. Hook up a Salesforce MCP alongside a Snowflake MCP and a Jira MCP, and an agent can answer "are any of our top-50 accounts blocked on engineering tickets?" — a question that today requires three tabs and a human.
- Agentforce orchestration. Internal Agentforce agents calling external MCP servers (your data warehouse, your CPQ vendor, your support tool) without custom apex integrations.
That last one is the real McCoy. MCP can (and likely will) be how agents stop being demos and start being load-bearing.
The catch nobody mentions in the keynote
Here is the thing every "What Is a Salesforce MCP Server" post will tell you: install the server, point your client at it, and now you have an AI that knows your Salesforce. Badabing.
Here is what they leave out: the AI does not know your Salesforce. It knows what the MCP tool returns about your Salesforce.
And what those tools return is the same thing they've always returned — fields, relationships, flows, Apex, validation rules — without any of the institutional context that explains why a field exists, who depends on the flow it feeds, or which of your three lead-routing automations is the live one. A Salesforce org accumulates a decade of decisions, deprecations, half-deprecations, and "we'll clean that up next quarter." MCP exposes that surface. It doesn't make sense of it.
This is the same problem that's plagued every prior generation of Salesforce tooling: the 80% of work that happens before any change ships — the discovery, the dependency mapping, the "wait, what does this field actually do" archaeology — has never had a real home. Agents inherit that gap. They just hit it faster, and with more confidence.
So when you stand up a Salesforce MCP server, the question isn't "can my agent query records." Of course it can. The question is whether your agent has the metadata context to know what it's looking at — and whether you have the governance layer to keep it from confidently breaking things.
Getting started
For most teams, the rational sequence is:
- Pick the right server for the job. Developer experimenting in an IDE → DX MCP Server. Production agent hitting Salesforce remotely → Hosted MCP Server. Agentforce-driven workflow → use Agentforce's MCP client and pull from AgentExchange.
- Set up auth properly. OAuth with PKCE on an External Client App, scoped to the minimum your use case needs. "Access MCP servers" and "Perform requests at any time" are the named scopes for the hosted servers.
- Start with read-only. Most damage from AI agents comes from confident writes. Let the model query for a while before you give it tools that mutate state.
- Layer in metadata context. Whatever org-specific understanding your agent needs to not make confident mistakes — dependencies, ownership, flow logic, the difference between active and orphaned automation — has to come from somewhere. A second MCP server that exposes that context to the same client is one path. (This is the part Sweep handles, if you're curious.)
- Govern it. Use Salesforce's MCP registry — or your own — to control which servers are trusted, which tools agents can call, and what gets rate-limited.
The short version
A Salesforce MCP server is an interface. It lets AI agents talk to Salesforce through a standard protocol instead of bespoke integration code. There are several flavors — DX, Hosted, Heroku, MuleSoft, Mobile, Agentforce-as-client, community — and the right one depends on what you're trying to build.
The protocol is the easy part.
Giving the agent enough context to use it well — that's the part nobody handed you in the keynote.
