Model Context Protocol (MCP) is the open standard that finally gives large language models a stable way to call tools, read data, and trigger actions across different systems. Think of it as the “USB-C port” for AI assistants — one plug, many devices.
Salesforce has been leaning into MCP hard. As of April 2026, there are three different MCP surfaces shipping across the platform, and they all do different things. If you’ve been confused by the marketing, you’re not alone — I had to draw this map for myself before I understood the boundaries.
Here’s the one I wish I’d had a month ago.
The Three MCP Surfaces in Salesforce
The short version: who is doing the calling decides which surface you use.
- A human engineer in an IDE talking to their org → DX MCP Server
- A backend service, partner system, or analyst tool that needs a stable, hosted endpoint → Hosted MCP Servers
- An autonomous Agentforce agent that needs to reach out to registered tools → Agentforce MCP Client
Let me unpack each.
1. Salesforce DX MCP Server
This is the one most developers meet first. It’s a Node-based MCP server you install locally — npx -y @salesforce/mcp — that exposes around 60 Salesforce tools through any MCP-aware client.
It is currently marked as pilot / beta under Salesforce’s Beta Services Terms, and it talks to orgs you’ve already authorized with sf org login web.
If you spend your day in Claude Code, Cursor, VS Code, or Cline and you want your AI assistant to deploy metadata, run SOQL, execute anonymous Apex, run tests, and spin up scratch orgs on your behalf — this is the one.
The 14 toolsets bundle tools by intent — orgs, metadata, data, users, testing, code-analysis, lwc-experts, aura-experts, devops, and more. You opt in to only the ones you need via the --toolsets flag, which is both a security practice (fewer tools = smaller blast radius) and a context-window practice (fewer tools = less prompt bloat for the model).
{
"mcpServers": {
"Salesforce DX": {
"command": "npx",
"args": [
"-y", "@salesforce/mcp",
"--orgs", "DEFAULT_TARGET_ORG",
"--toolsets", "orgs,metadata,data,users"
]
}
}
}I walk through the full setup — including the pitfalls around ALLOW_ALL_ORGS and --allow-non-ga-tools — in the DX MCP setup guide.
2. Salesforce Hosted MCP Servers (Beta)
This is the one that will matter most to business teams over the next 12 months.
Hosted MCP Servers run on Salesforce’s own infrastructure. You don’t install anything locally — you point an MCP client at a URL, go through OAuth, and the client gets a curated set of MCP tools that wrap Salesforce APIs. They entered Beta in late 2025 and are targeted for GA in 2026.
What the beta currently exposes:
- Core Platform — sObject CRUD, SOQL / SOSL, schema discovery, basic developer tooling
- Tableau / Tableau Next — semantic models, dashboards, natural-language data analysis
- Data Cloud — query Data Cloud entities with SQL
- Revenue Lifecycle Management — quoting, ordering, configuration, pricing engine
Hosted MCP Servers let any MCP-speaking tool — Claude.ai, ChatGPT desktop, an internal assistant, a partner agent — hit real Salesforce data and workflows without you writing a single line of integration code. OAuth, rate limits, and audit are Salesforce’s problem, not yours.
I cover the business side of this in Hosted MCP Servers for business teams.
3. Agentforce as an MCP Client
The third surface is the one people get most confused about: Agentforce itself is an MCP client.
In other words, your Agentforce agents — the ones you’re building on Atlas Reasoning Engine with topics, actions, and guardrails — can be pointed at any MCP-compliant server (Salesforce’s own Hosted servers, Heroku, MuleSoft, AWS, Box, Google Cloud, IBM, Notion, PayPal, Stripe, and a growing list of partners). The agent gets new tools without you writing invocable Apex.
Agentforce 360 layers a trusted gateway, MCP server registry, and allowlist on top of the raw MCP protocol. This is deliberately zero-trust — admins decide which servers are reachable and which tools are callable. If you turn this off or open it up, you’ve just signed up for tool-poisoning attacks. Don’t.
When to Use Which
A real-world architecture I’m seeing take shape at clients looks like this:
- Engineers use DX MCP Server locally to move faster on day-to-day dev
- An Agentforce service agent talks to internal Salesforce data via the Hosted MCP Server and to a partner system (say, Stripe) via the Agentforce MCP Client
- The MCP server registry inside Agentforce keeps the whole thing auditable
No one layer is doing everything. That’s the point.
What About Security?
The three things to check before you roll any of this out
1. Allowlist, not open internet. For Agentforce, keep the registry tight. Only servers that have been reviewed by your security team should be reachable. Salesforce’s default posture here is zero-trust — don’t weaken it.
2. Least-privileged toolsets. For the DX server, use --toolsets aggressively. Don’t ship developers a config that enables all 14 toolsets “just in case”. More tools mean more prompt-injection surface.
3. OAuth scopes. For Hosted MCP Servers, the connected app scopes are the real control. Treat them like you’d treat an integration user — the agent is an integration user.
Problem: A team wired their Claude Code setup to the DX MCP Server with --orgs ALLOW_ALL_ORGS and shared the config across the team. A developer accidentally ran “deploy this” against production because Claude picked the first matching alias.
Fix: Always scope to a specific alias or DEFAULT_TARGET_ORG in dev environments, and keep production orgs out of the MCP surface entirely — or at minimum, behind a second explicit alias that can’t be confused with a sandbox.
What’s Coming Next
The roadmap that has been publicly signalled:
- Hosted MCP Servers — GA targeted in 2026, with custom MCP server configurations for specific business needs
- Agentforce MCP Client — broader GA coverage across regions, deeper registry integration
- Partner ecosystem — 30+ launch partners committed to listing MCP servers, including AWS, Box, Cisco, Google Cloud, IBM, Notion, PayPal, Stripe, Teradata, and WRITER
If you’re planning your AI integration strategy for the next 12 months, assume MCP is the integration protocol, the same way REST became the integration protocol a decade ago.
If you’re currently evaluating MCP for your org, which of the three surfaces do you think you’ll reach for first — and is there a part of the picture you’re still unsure about?
How did this article make you feel?
Comments
Salesforce Tip