There are three different things called a Salesforce MCP server, they solve different problems, and picking the wrong one costs you a week. The Salesforce DX MCP Server runs locally and gives your coding assistant control of your org's metadata and code. Salesforce Hosted MCP Servers run inside the platform and give AI agents governed access to org data at runtime. Third-party and self-built servers cover everything neither of those does.
This page separates the three, shows how each authenticates, and covers what changes if you are an ISV distributing an app rather than a customer connecting your own org.
The three options at a glance
| Salesforce DX MCP Server | Salesforce Hosted MCP Servers | Build or buy your own | |
|---|---|---|---|
| Where it runs | Your laptop, via npx | Inside your Salesforce org | Your infrastructure |
| What it is for | Writing and deploying Salesforce code | Letting agents read and act on org data | Anything the first two do not cover |
| Who uses it | Developers in an AI-assisted IDE | AI agents and end users at runtime | Depends on the build |
| Authentication | Salesforce CLI org auth | The org's own permission model | Yours to design |
| Availability | Generally available | Generally available, Enterprise Edition and above | Not applicable |
| Setup effort | One command | Enable in Setup | Weeks |
The short version: if a human developer is the one asking, you want DX. If an agent is the one asking, you want hosted.
Option 1: the Salesforce DX MCP Server
This is a local server you run on your own machine that gives an AI coding assistant a structured way to talk to your org. Rather than letting the model guess at CLI syntax, it exposes more than 60 tools covering metadata, data, DevOps, testing, code analysis, Lightning Web Components and org management.
Starting it is a single command:
npx -y @salesforce/mcp --orgs DEFAULT_TARGET_ORG --toolsets orgs,metadata,data,usersTools are grouped into toolsets you enable explicitly, including orgs, metadata, data, devops, testing, users, code-analysis, lwc-experts and mobile. A core toolset is always on. Enabling only what you need keeps the tool list short, which matters more than it sounds: a model choosing between 12 relevant tools makes better choices than one choosing between 60.
Individual tools that have not reached general availability are gated behind an --allow-non-ga-tools flag, so you opt into them deliberately rather than discovering them by accident.
How it authenticates
It does not hold credentials of its own. It reuses the orgs you have already authorized through the Salesforce CLI with org login web, or through the Authorize an Org command in VS Code. The --orgs flag then controls which of those the server may touch, accepting DEFAULT_TARGET_ORG, DEFAULT_TARGET_DEV_HUB, a specific username or alias, or ALLOW_ALL_ORGS.
Treat ALLOW_ALL_ORGS as the setting you justify rather than the one you default to. It hands every authorized org on the machine, production included, to whatever the model decides to do next. Naming the single org you are working in costs you one flag and removes an entire category of accident.
Org tokens resolve per tool call rather than at startup, so re-authenticating does not mean restarting the server.
Which clients it works with
Claude Code, Cursor, VS Code with Copilot, Cline, Windsurf, Zed and Trae. Any MCP-capable client can connect, since the protocol is the point.
Option 2: Salesforce Hosted MCP Servers
These solve a different problem. Instead of helping a developer write code, they let an AI agent read and act on live org data, with Salesforce hosting the server.
They followed the usual path: pilot in spring 2025, beta in October 2025, generally available from April 2026 for Enterprise Edition orgs and above. There is nothing to provision or keep running. You enable a server in Setup and it is live.
Standard servers cover the Agentforce 360 Platform, Tableau Next and Data 360 SQL. Custom servers let you expose your own Flows, Apex actions and Named Query APIs as MCP tools, which is the part worth planning for: it means the surface an agent sees is something you design, not a generic dump of your schema.
The permission model is the reason to use it
Your existing permissions apply automatically. Object permissions, field-level security and sharing rules all carry over, because the server runs inside the platform rather than beside it.
That is the difference that matters when you compare hosted servers against wiring an agent to the REST API yourself. In the do-it-yourself version, every access decision is code you wrote, and every one of them is a place to get sharing wrong. Here the org enforces what it already enforces, and an agent acting as a user sees exactly what that user sees.
Option 3: building or buying your own
Neither official option covers every case. You might need an MCP server that spans Salesforce and three other systems, or one your customers install rather than one you run, or one exposing product logic that has no equivalent in Flows or Apex actions.
Before building, price the parts nobody scopes: OAuth setup and token refresh, multi-tenant credential storage, per-tenant rate limiting, and an upgrade path for when the tool surface changes. Roughly the same list that makes any integration a project rather than a task.
What changes if you are an ISV
If you are distributing an app rather than connecting your own org, two things are different.
Your customers' agents will look for you. MCP servers are discoverable through AgentExchange alongside apps and Agentforce components. Being absent from that catalogue is the agent-era version of not having an AppExchange listing.
You still need your own OAuth app. An agent connecting to a customer's org needs a client ID and secret that belongs to you, which on Salesforce means an external client app. Connected app creation through the UI was turned off by default on new orgs in Winter '26, and from Spring '26 re-enabling it requires Salesforce Support, so new work starts with an external client app.
| Question | Customer connecting their own org | ISV shipping to customers |
|---|---|---|
| Whose OAuth app | The org's own | Yours, an external client app |
| Where it is discovered | Setup | AgentExchange |
| Who handles install | Admin toggles it on | You ship a managed package |
| Who owns upgrades | Salesforce | You, for the life of the listing |
Appnigma builds the Salesforce side of that: the external client app, the managed package, and the AppExchange listing, as a done-for-you engineering service.
Choosing between them
Three questions settle it.
Is a person or an agent asking? A developer in an IDE wants DX. An agent at runtime wants hosted.
Does it need to respect sharing rules? If yes, hosted, because it does that for free and a custom build does not.
Is it only Salesforce? If the workflow spans several systems, neither official server covers it on its own, and you are looking at a custom build or a vendor.
Frequently Asked Questions
What is a Salesforce MCP server?
An MCP server that exposes Salesforce capabilities as structured tools an AI model can call. Salesforce publishes two: the Salesforce DX MCP Server, which runs locally and is aimed at development work, and Salesforce Hosted MCP Servers, which run inside the org and give agents governed access to data at runtime.
Is the Salesforce MCP server free?
The Salesforce DX MCP Server is open source and distributed through npm, so there is no separate charge for it. Salesforce Hosted MCP Servers are a platform capability for Enterprise Edition orgs and above. In both cases the work they do still consumes the org's normal API and platform allocations.
How do I connect Claude to Salesforce?
Authorize the org with the Salesforce CLI using org login web, then add the Salesforce DX MCP Server to your client's MCP configuration with npx -y @salesforce/mcp --orgs DEFAULT_TARGET_ORG plus the toolsets you want. Claude Code, Cursor, VS Code with Copilot, Cline, Windsurf, Zed and Trae all connect this way.
Is the Salesforce DX MCP Server generally available?
Yes. Individual tools that have not yet reached general availability are gated behind the --allow-non-ga-tools flag, so you enable them deliberately.
What is the difference between Agentforce and MCP?
Agentforce is Salesforce's agent platform. MCP is an open protocol for exposing tools to models. They are complementary: MCP is how an Agentforce agent reaches capabilities outside itself, and how outside agents reach into Salesforce.
Do MCP servers respect Salesforce sharing rules?
Salesforce Hosted MCP Servers do, because they run inside the platform and inherit object permissions, field-level security and sharing rules automatically. A server you build yourself enforces only what your code enforces, which is why access control is the part of a custom build most worth reviewing.
Can I list an MCP server on AgentExchange?
Yes. AgentExchange carries MCP servers alongside apps, agents, actions and topics. For ISVs that makes it the discovery surface for agentic capabilities, the same role AppExchange plays for installed apps.
What authentication does an ISV need for MCP?
Your own OAuth client ID and secret, which on Salesforce means an external client app. Connected app creation in the UI was disabled by default on new orgs in Winter '26, and re-enabling it has needed Salesforce Support since Spring '26, so new integrations start with an external client app.
Related Articles
- What is an external client app in Salesforce
- What is Salesforce AgentExchange
- Building Agentforce components for AgentExchange
- Connected app vs external client app compared
Sources
- Salesforce DX Developer Guide and the salesforcecli/mcp repository: toolsets, org authorization flags, supported clients, GA status. 2/ Salesforce Developers Blog, Salesforce Hosted MCP Servers Are Now Generally Available, April 2026. 3/ Salesforce Developers Blog, Salesforce Hosted MCP Servers Are in Beta Today, October 2025. 4/ Salesforce Help, External Client Apps and connected app creation changes in Winter '26 and Spring '26. Verified 2 September 2026.
