How to Set Up a Salesforce MCP Server in Your DevOps Workflow

Short answer: setting up a Salesforce MCP server takes three decisions and about ten minutes of config. Pick the server (local Salesforce DX, a hosted Salesforce endpoint, or your DevOps platform's own), point your AI client at it with an explicit list of authorized orgs, then narrow the toolsets to the smallest set that does the job. The part that takes longer than ten minutes, and the part most guides skip, is deciding which actions the agent may run on its own and which stay behind a human.

What is a Salesforce MCP server?

The Model Context Protocol is an open standard for exposing tools to an AI client. An MCP server for Salesforce turns operations you would normally run from the CLI or a UI into tools an assistant can call: query an org, retrieve metadata, run Apex tests, open a pull request, plan a deployment. The client decides what to call, the server decides what exists and who is allowed to call it.

For DevOps that framing matters. The server is your policy boundary. Anything you expose, the model can eventually try.

Which Salesforce MCP server should you use?

• Salesforce DX MCP Server. Runs locally on your machine using credentials you already authorized with the Salesforce CLI. Best for developers doing metadata, data and test work. Package: @salesforce/mcp.
• Salesforce hosted MCP servers. Cloud endpoints reached over OAuth, for people who do not want the CLI installed. See Salesforce's MCP support announcement for the full stack, including Heroku and MuleSoft servers.
• Your DevOps platform's MCP server. This is the one that matters for release work, because deployment lives there, not in the org. Serpent's native MCP server exposes pipeline actions such as plan_deploy, create_pull_request, resolve_metadata_conflict and trigger_pipeline to Claude, Cursor, Windsurf, Codex, Cline, GitHub Copilot and Agentforce.

Most teams end up running two: one for org work, one for release work. They answer different questions.

How do you set up the Salesforce DX MCP server?

1. Authorize the orgs first. Run sf org login web for each org. The MCP server can only reach orgs the CLI already knows about, which is your first and cheapest control.
2. Add the server to your client's config. A minimal entry looks like this: {"mcpServers":{"Salesforce DX":{"command":"npx","args":["-y","@salesforce/mcp","--orgs","DEFAULT_TARGET_ORG","--toolsets","orgs,metadata,data"]}}}
3. Scope the orgs explicitly. The --orgs flag is required. It accepts DEFAULT_TARGET_ORG, DEFAULT_TARGET_DEV_HUB, explicit usernames or aliases, and ALLOW_ALL_ORGS. Salesforce's own documentation flags that last value as one to use with caution. Take the hint.
4. Narrow the toolsets. --toolsets selects functional groups rather than loading everything. There are more than fifteen, including orgs, metadata, data, users, testing, devops and code-analysis. Enabling all works and is discouraged, because every tool you load spends context the model could be using to think.
5. Leave non-GA tools off. Tools are marked GA or non-GA, and the non-GA ones need --allow-non-ga-tools. Do not turn that flag on in a repo anyone else clones.

How should authentication work?

Local servers inherit CLI credentials, which is convenient and means the agent's blast radius equals the developer's. Hosted servers use OAuth with PKCE through an External Client App, which is the right model when you want a separate identity with its own scopes.

The rule that survives both: the MCP identity should not be a shared admin. Give it its own user, its own permission set, and no more object access than the tools you enabled actually need. If your agent can call a data tool, assume one day it will.

Which actions should stay behind human approval?

This is the part worth arguing about in your team, not copying from a blog. A workable default:

• Safe to automate: read metadata, describe objects, run SOQL against sandboxes, run Apex tests, generate a deployment plan, open a pull request, post a summary.
• Always human-approved: deploying to production, releasing a package version, mass data operations, deleting or overwriting metadata, resolving a conflict in a way that discards someone else's change.
• Never exposed at all: credential management, user provisioning, anything touching a production org that has no rollback path.

The important design point is that approval must live in the server, not in the prompt. A model instructed to ask first will ask first almost always, and "almost always" is not a control. Serpent's MCP server runs preflight checks and requires human approval before a deployment executes, so the boundary is enforced by the platform rather than by good manners.

What does this look like in a real pipeline?

A typical loop: the developer asks the assistant to prepare a release. The agent reads the diff, calls the plan tool, and comes back with the components, the tests it will run and the risks it found. A human reads that plan and approves it. The agent triggers the pipeline, watches it, and reports the result. Every write is auditable, and the human spent two minutes instead of forty.

Start with one repo and one sandbox. Expand the toolsets only when an actual task fails for lack of one. More Salesforce DevOps guides cover the pipeline side of this in detail.

FAQ

Do I need the Salesforce CLI to use MCP?

For the local Salesforce DX MCP server, yes, because it uses CLI credentials. Hosted MCP servers use OAuth instead and do not require a local CLI install.

Can an MCP server deploy to production?

Technically yes, which is exactly why it should not do so unattended. Keep production deploys behind an approval step enforced by the server, not by instructions in a prompt.

Which toolsets should I enable first?

Start with orgs, metadata and data. Add testing when you want the agent running Apex tests, and add devops tooling once the read-only loop is trusted.

Is MCP safe for regulated environments?

It can be, if the agent has its own identity, least-privilege permissions, an audit trail and a human gate on writes. Treat it like any other integration user, because that is what it is.