Setting up Salesforce DX MCP Server

What the Salesforce DX MCP Server is

According to Salesforce, the Salesforce DX MCP Server is a specialized Model Context Protocol server that lets large language models interact securely with Salesforce orgs. A Salesforce org is a company's concrete Salesforce environment, for example a development, test, or production instance containing metadata, data, users, permissions, and Apex code. Salesforce DX, or SFDX, is Salesforce's modern development approach for source control, automation, and CLI-based work. The MCP server connects that world to an AI client: instead of an assistant producing only generic Salesforce answers, it can use defined tools to list orgs, query metadata, perform data operations, or run Apex tests, provided those toolsets are enabled. For development teams, this matters because many Salesforce tasks are highly context-dependent, and an agent can only be meaningfully helpful once it knows the specific org and the tools it is allowed to use.

Prerequisites

The official Salesforce implementation is in the salesforcecli/mcp GitHub repository and is started through the npm package @salesforce/mcp. A working environment therefore needs Node.js and npx, as well as an MCP-capable client such as VS Code with Copilot, Claude Code, Cursor, Cline, or another client that supports an MCP JSON configuration. The user must also be authenticated with Salesforce, typically through the Salesforce CLI, so that the server can access the specified org. The examples often use DEFAULT_TARGET_ORG, meaning the default org configured in the local Salesforce CLI setup. Actual capabilities are restricted through startup arguments: --orgs defines which orgs may be used, --toolsets activates groups of tools such as orgs, metadata, data, or users, and --tools can add or limit individual tools such as run_apex_test.

Step-by-step setup

Setup happens in the MCP configuration file of the chosen client. For Claude Code, the README shows adding an entry under mcpServers in the project's .mcp.json file. The command is npx, and the arguments include -y and @salesforce/mcp so that npx installs or runs the package without prompting. The desired flags follow, such as --orgs DEFAULT_TARGET_ORG, --toolsets orgs,metadata,data,users, --tools run_apex_test, and optionally --allow-non-ga-tools if tools that are not generally available should be usable from the enabled toolsets. VS Code with Copilot uses a similar configuration in .vscode/mcp.json; Cursor, Cline, and other clients use their own locations but the same basic structure for command and args. After saving, the client should be reloaded or the MCP connection restarted. A safe first test is a harmless read operation or an Apex test run in a development org, not a data or metadata operation against production.

Security and best practices

Salesforce emphasizes in its documentation that the DX MCP Server provides tools that can read, manage, and operate Salesforce resources. Permission design is therefore critical. The server should not be started broadly with every org and every toolset if only a small part is needed. A safer approach is to name allowed orgs explicitly, initially enable only read-oriented or low-risk toolsets, and allow individual tools deliberately. For production orgs, separate approvals, clear roles, and, where possible, read-only users should be used. The --allow-non-ga-tools flag should be used deliberately because it can enable tools that are not yet generally available and whose behavior may change. Debug logs can be useful, but they must not expose credentials or sensitive data and may not be visible in every client.

Who should use it and what makes it different

The Salesforce DX MCP Server is mainly useful for Salesforce developers, platform teams, and admins who want AI assistance directly inside their development environment. It differs from generic Salesforce chatbots because it is connected to the concrete Salesforce CLI and org configuration and exposes structured, documented tools. Compared with custom integrations, it saves a lot of foundation work because Salesforce itself provides the MCP interface, sample configurations, and toolsets. Still, it does not replace Salesforce governance: a model can run an Apex test or inspect metadata, but it does not automatically understand every business consequence of a change. In professional environments, changes should still go through branches, pull requests, automated tests, deployment pipelines, and approval processes. The server is especially useful when restricted to development or scratch orgs where it can speed up routine work without unnecessarily exposing production data to an AI workflow.