Connect Claude to Your Salesforce Org with MCP

Most "AI in Salesforce" content stops at the demo. Someone types a question, an agent answers, everyone claps. Nobody shows you the wiring — or the part where you decide whether to point a language model at your production org.

The wiring is the easy part. It takes about ten minutes. The judgment is the part that separates a toy from something you'd actually run on a client org.

Here's how to connect Claude to Salesforce through MCP, which of the two options to use, and how to do it without handing an LLM the keys to your entire instance.

‍

What MCP actually is

Model Context Protocol is the standard that lets an AI client — Claude Code, Claude Desktop, Cursor — talk to an external system through a defined set of tools. No screen scraping, no brittle browser automation. The model calls a tool, the tool runs against your org, structured data comes back.

For Salesforce there are now two ways to do this, and they solve different problems. Pick the wrong one and you'll either over-engineer a dev task or under-secure a production one.

The local DX MCP server (@salesforce/mcp) runs on your machine and is built for development. It exposes 60+ tools across more than a dozen toolsets — SOQL queries, metadata retrieve/deploy, Apex test runs, code analysis, and DevOps Center pipelines. It authenticates through the Salesforce CLI you already have, so there's no connected app to stand up.

The Salesforce Hosted MCP Servers run in the platform and are built for runtime. They let an agent execute business logic and query data across the Agentforce 360 Platform, Data 360 SQL, and Tableau Next without ever logging into Lightning. This is the path for agent operations and custom tools built from your Flows, Apex Actions, and Named Query APIs — and it requires real OAuth.

Short version: building and shipping, use the local server. Running an agent or assistant against live business processes — under per-user OAuth and platform governance — use hosted.

‍

The setup that gets you working in ten minutes

Start with the local DX server. You need Node.js and the Salesforce CLI installed.

First, authorize the org. The CLI ships with its own registered connected app, so this is one command — no setup-menu detour:

sf org login web --alias my-dev-org

Then add the server to your project. Drop a .mcp.json in the project root:

{
  "mcpServers": {
    "Salesforce DX": {
      "command": "npx",
      "args": ["-y", "@salesforce/mcp",
        "--orgs", "DEFAULT_TARGET_ORG",
        "--toolsets", "orgs,metadata,data,users",
        "--tools", "run_apex_test",
        "--allow-non-ga-tools"]
    }
  }
}

Restart Claude Code, and it can now query, deploy, and test against that org. That's the whole tutorial. Everything past this point is judgment, not steps.

‍

The two flags that matter most

Notice what's in that config — and what isn't.

--orgs takes a specific org, not every org you've ever authorized. There is an ALLOW_ALL_ORGS value. Don't use it. The moment you do, one careless prompt can run against the wrong instance, and "the wrong instance" is sometimes production. Scope the server to exactly the org you're working in, and if you juggle multiple clients, run a separate config per project. Isolation isn't paranoia — it's the difference between a controlled tool and an incident.

--toolsets is your blast radius. The default config above grants data, metadata, users, and orgs. Hand out only what the task needs. If you're reviewing code, you don't need write access to user records. If you're running SOQL, you don't need the deploy toolset live. Narrow the surface and you narrow what can go wrong — the same principle you'd apply to a permission set, applied to an AI client.

This is the part the demos skip. Connecting Claude is trivial. Connecting it with the right org scoped and the right toolsets enabled is the part that holds up on a real engagement.

‍

When you graduate to hosted

The hosted servers — generally available since April 2026 — are a bigger commitment, and worth it when you've moved from "help me build" to "let an agent operate."

Setup runs three steps. In Setup, search MCP Servers, open the Salesforce Servers tab, activate the servers you want, and note each API name and server URL. Next, create an External Client App — enable PKCE and JWT-based access tokens, set the callback URL for your client (http://localhost:38000/callback for Claude Code, https://claude.ai/api/mcp/auth_callback for Claude Desktop), and grab the consumer key and secret. Finally, register the server with Claude using that URL and key, and authenticate.

The payoff is custom servers: expose your own Flows, Apex Actions, and Named Query APIs as tools, so the agent operates through governed business logic instead of raw record access. That's how you give an agent real capability without giving it raw write access to every object — the controls live in the platform, where they belong.

‍

The point most people miss

Connecting an LLM to Salesforce is no longer the hard problem. Salesforce solved it. The hard problem is the same one it has always been: scope, governance, and knowing which tool fits which job.

A dev who scopes the server to one org and the minimum toolsets gets a genuinely faster build loop. A team that flips on ALLOW_ALL_ORGS and points it at production "to see what happens" gets a cautionary tale. Same protocol, opposite outcomes — and the difference is architecture, not the AI.

That's the part we think about before we wire anything up. If you want help connecting Claude to your org the right way — scoped, governed, and actually safe to run — 👉 Let's Chat.