Salesforce MCP Server: Options and Safe Setup

Salesforce has two MCP servers of its own, and they answer different needs. The Salesforce DX MCP Server is an open-source npm package that runs on a developer’s machine, uses the orgs you have already authorized with the Salesforce CLI, and brings tools for SOQL queries, metadata deploys, Apex tests, Lightning Web Components and more. Salesforce hosted MCP servers run inside Salesforce itself, are generally available for Enterprise Edition orgs and above, and let any MCP client work with records as the signed-in user. Whichever you choose, the safe setup is the same: a sandbox before production, the fewest tools that do the job, and a user whose permissions you would be comfortable handing to an assistant.

The two options at a glance

• Salesforce DX MCP Server: @salesforce/mcp on npm, run with npx, over stdio. For developers in an editor or a terminal agent. Its tools work against orgs authorized on your computer, and many of them work on your local DX project files.
• Salesforce hosted MCP servers: remote endpoints under https://api.salesforce.com/platform/mcp/v1/, turned on per server by an admin, with sign-in through an External Client App. For people in Claude, ChatGPT, Cursor or another client who want to read and update CRM records.

Community servers for Salesforce also exist. Judge them the same way as any other: who maintains them, which login they use, and whether they can write.

The Salesforce DX MCP Server

The Salesforce DX MCP Server repository↗ (opens in a new tab) lists more than 60 tools, grouped into toolsets that you switch on with --toolsets. The ones most teams start with:

• data: run_soql_query, which runs a SOQL query against an org. Read-only.
• metadata: deploy_metadata and retrieve_metadata, which move metadata between your DX project and an org. Deploy writes.
• testing: run_apex_test and run_agent_test.
• orgs: list_all_orgs, plus tools marked NON-GA that create scratch orgs and snapshots, open an org and delete a scratch org or sandbox.
• users: assign_permission_set, which grants a permission set to you or another user.
• Specialist toolsets: lwc-experts, aura-experts, code-analysis, devops, mobile, enrichment and more. Many of these are guidance tools that return advice rather than touching the org.
• core is always on and holds helpers such as get_username.

Two flags need care. --allow-non-ga-tools loads tools Salesforce has not yet made generally available; leave it off unless you need a specific one. --toolsets all loads everything, and Salesforce itself recommends against it because the full list can overwhelm the model’s context. Telemetry is on by default; --no-telemetry turns it off.

Choose the org by name, not by default

--orgs is required and decides which orgs the tools may reach. The examples use DEFAULT_TARGET_ORG, but the README notes that this value is resolved again on every tool call, so switching your default org in the CLI, or working in a folder with a different default, changes which org the assistant touches. ALLOW_ALL_ORGS reaches every org you have authorized, production included. Name one sandbox by its alias instead.

Setup in Claude Code

First authorize a sandbox with the Salesforce CLI and give it an alias. The reference for sf org login web, in the Salesforce CLI auth plugin↗ (opens in a new tab), shows the sandbox form of the instance URL. Then add the server; --scope project writes the entry to a shared .mcp.json, and everything after -- is the command that starts it.

sf org login web \
  --instance-url https://MyDomainName--dev1.sandbox.my.salesforce.com \
  --alias dev1-sandbox

claude mcp add --scope project salesforce-dx -- \
  npx -y @salesforce/mcp --orgs dev1-sandbox --toolsets data --no-telemetry

# then, inside Claude Code
/mcp

That gives the assistant SOQL and the core helpers against one sandbox, and nothing that writes. Add metadata or testing when a task needs them, not before. The same arguments work in VS Code’s .vscode/mcp.json, Cursor and Cline, as the repository shows.

Salesforce hosted MCP servers

Salesforce’s hosted MCP servers repository↗ (opens in a new tab) says they are now generally available, and points to Setup for administration and the Salesforce Developers site for the server reference. The model is different from the DX server: nothing is installed, and Salesforce runs the server.

• Standard servers are off by default. An admin turns each one on in Setup, under API Catalog, then MCP Servers.
• platform/sobject-reads is read-only. platform/sobject-all can read, create, update and delete records. Admins can also build custom servers that expose only chosen tools, such as Flows, Apex actions and named queries.
• Clients sign in through an External Client App with the mcp_api and refresh_token scopes. Connected Apps are not supported for this.
• Production and sandbox use different addresses: .../mcp/v1/platform/sobject-reads for production and Developer Edition, .../mcp/v1/sandbox/platform/sobject-reads for sandboxes. A form with your My Domain name is recommended, and required for orgs that block the standard login page.

If you set this up during the beta, it has changed. According to the hosted servers FAQ↗ (opens in a new tab), the URL version moved from v1-beta.2 to v1, four beta scopes became mcp_api and refresh_token, and one org-wide toggle became per-server activation. The same FAQ says the mcp-remote bridge is not supported, so use a client with native remote MCP and OAuth support.

Salesforce documents setup for Postman, Claude, ChatGPT, Cursor and Microsoft Copilot Studio, and suggests testing in Postman first because it shows the raw tool calls with no model involved. In Claude Code, the pre-configured OAuth flags described in Claude Code’s MCP documentation↗ (opens in a new tab) fit this sign-in: pass the External Client App’s consumer key as --client-id, let --client-secret prompt for the secret, and register http://localhost:8080/callback as the app’s callback URL to match --callback-port 8080.

Org permissions: the assistant is you

Neither server gives the assistant its own identity inside Salesforce. The DX server acts as the user you authorized in the CLI. A hosted server acts as the user who signed in, with that user’s object permissions, field-level security and sharing rules, and when the assistant updates a record, that user’s name is on the change. If you are a System Administrator, so is your assistant.

• Use a separate integration or test user with a narrow profile and permission sets, not your admin login, for anything beyond your own exploration.
• Restrict the External Client App by profile and permission set, so only the people you intend can connect through it.
• Prefer sobject-reads, or a custom server with a short tool list, over sobject-all. Choosing a narrower server is the simplest control Salesforce offers.
• Treat assign_permission_set, deploy_metadata and any delete tool as changes to review, never as something to allow for the whole session.

Sandbox first

Point every new connection at a sandbox or a scratch org until you have watched it work. Run a week of real questions, check what the assistant queried and changed, and only then decide whether production access is needed at all. Most reporting questions are answered just as well from a recently refreshed sandbox. When you do move, keep the production connection read-only, on its own server entry with its own name, so there is never a doubt about which org a prompt is going to.

Safe prompts

Prompts are not a security control, but a clear one keeps an honest assistant from guessing. Say which org, which tools, and where to stop:

• “Using the dev1-sandbox org only, run a SOQL query for Opportunities closed last quarter with Amount over 50000. Show me the query before you run it. Do not change any records.”
• “Retrieve the Account page layout metadata into this project. Do not deploy anything.”
• “Run the Apex tests in the AccountService test class and summarize the failures. Do not edit code or metadata.”
• “Draft the field changes for these 12 Contacts as a table. I will approve before anything is updated.”

Text inside records is the other risk. A case description or an email body can carry instructions aimed at the assistant, and with write tools connected, a record becomes a command. Keep write tools off in sessions that read customer-written text, and keep approval prompts on. The wider checklist is in MCP security best practices, and the attack itself in indirect prompt injection.

Keeping the work on a board

A sandbox session finds things worth fixing: a validation rule that blocks a valid record, a failing Apex test, a field nobody fills in. fenbs is a task board an assistant can write to over MCP at https://fenbs.ai/api/mcp, so each finding becomes a bug or an enhancement with a note, a plan and a test status, and every change is recorded in History under the assistant’s name. Put the standing rule, such as “no production writes through an assistant”, on the Decisions and rules page, which every connected assistant reads before it starts. fenbs does not connect to Salesforce or see its data; Salesforce’s setup audit trail, and field history tracking where you have turned it on, record what changed in the org.