Salesforce MCP: the official servers, the community ones, and what an agent can do with your CRM

"Salesforce MCP" is the most searched CRM-plus-MCP term, and it means three different things depending on who is asking. Developers want to manage orgs from Claude Code. Sales ops want an assistant that can read pipeline. Architects want Agentforce agents to talk to external ones. This guide separates them. Client setup steps are in Claude Code, Cursor and Claude Desktop.

The three kinds

Salesforce DX MCP server (official, developers). Published by Salesforce as an npm package. It wraps the Salesforce CLI: list and authorise orgs, query with SOQL, retrieve and deploy metadata, run Apex tests, work with Data Cloud. The audience is developers using Claude Code, Cursor or Copilot against a scratch org or sandbox. It authenticates through the CLI's stored org logins.

Hosted MCP servers in Agentforce (official, platform). Salesforce's agent platform can expose MCP servers so that agents outside Salesforce can call Salesforce actions and data, and Agentforce agents can call external MCP servers. This is the enterprise integration route, governed inside Salesforce with its own permissions and monitoring.

Community servers (REST and SOQL). Servers that authenticate as a user through a connected app and expose tools such as query, describe_object, create_record, update_record. These are what most "connect Claude to Salesforce" setups use, and the ones that need the most review, because tool quality and write safety vary.

Setting up the DX server

For developers with the Salesforce CLI installed and an org authorised:

claude mcp add --transport stdio salesforce -- npx -y @salesforce/mcp --orgs DEFAULT_TARGET_ORG --toolsets all

The --orgs flag controls which authorised orgs the agent may touch; --toolsets selects tool groups so you can leave out deployment tools in a session that should only read. Start with the smallest set that does the job.

Setting up a CRM server

For business users, or for an agent that should read pipeline:

1. Create a connected app in Salesforce Setup with OAuth enabled and the API scopes the server needs.
2. Create an integration user with a profile that grants only the objects and fields the agent needs, read-only if reads are all you want. Do not use a person's admin login.
3. Configure the server with the instance URL and OAuth credentials, add it to your client, and authenticate.
4. Test with a describe and a small query before letting it near writes.

What to ask

Where a CRM server earns its place:

• "Open opportunities over 100k with no activity in 21 days, by owner."
• "Which accounts from the last webinar list already exist, and which are net new?"
• "Summarise every case for this account in the last quarter."
• "Draft a renewal email for each opportunity closing next month, using the last three activities as context."

Joined with a marketing server, the questions get better: "which Google Ads campaigns produced the leads that became closed-won this quarter" needs Google Ads and Salesforce in the same session.

The safety part

Salesforce is where an agent can do the most damage per call: mass-update a field, delete records, email a list. The controls are the standard ones from MCP security best practices, applied strictly:

• Integration user with a minimal profile. The agent cannot exceed it no matter what it is told.
• Read-only by default; write tools enabled per session, per purpose.
• Approval on every create, update, delete and send.
• Tool results are untrusted: a case description or an email body can contain instructions. Sessions that read customer-authored content should not have write tools.
• One log of every call.

In a team, that policy lives in a gateway rather than in each person's client. Walma AI Hub runs Salesforce and the other approved servers behind one policy inside the customer's own EU region, with central credentials, approvals and a log. Book a walkthrough if you are connecting agents to your CRM.