Salesforce DX MCP Server
How Salesforce's local DX MCP Server supports metadata retrieval, testing and DevOps workflows, and the controls we put around it.
Developers already use AI coding assistants; the Salesforce DX MCP Server lets those assistants retrieve metadata, run tests and work with DevOps Center through tools rather than guesswork. It runs on the developer's machine with the developer's authorised orgs, which is powerful and needs firm limits. This page explains what Salesforce provides and how we would set it up.
The business use case
- Metadata retrieval: pull the components a change touches so the assistant works from the real org, not from memory.
- Documentation and code analysis: explain existing Apex, LWC or Flow metadata and flag issues.
- Testing: run Apex and agent tests while iterating.
- DevOps workflows: prepare commits and promotions with a person approving each step.
What Salesforce offers
- Publisher: Salesforce (salesforcecli organisation), open source under Apache-2.0, npm package
@salesforce/mcp. - Runs locally: launched with
npxas a local process; it uses orgs already authorised with the Salesforce CLI (org login web). - The
--orgsflag is required:DEFAULT_TARGET_ORG,DEFAULT_TARGET_DEV_HUB,ALLOW_ALL_ORGSor a specific alias. - Toolsets: core (always on), orgs, metadata, data, testing, users, code-analysis, lwc-experts, aura-experts, mobile, mobile-core, devops, experts-validation, enrichment, scale-products, and all (60+ tools).
- Non-GA tools such as
create_scratch_organddelete_orgneed--allow-non-ga-tools.
Status
Salesforce called it a Developer Preview on 23 June 2025, and the Spring '26 (API 66.0) Developer Guide labels it "Salesforce DX MCP Server and Tools (Beta)". The current 264.0 page shows no Beta, Pilot or Developer Preview label and tracks maturity per tool (GA or NON-GA). We found no GA announcement for the whole server, so whole-server GA is status not confirmed.
Vendor server first
The server is Salesforce's, and we use it as published. We would only propose a GeekMidst wrapper for gaps, such as a pipeline step that requires a recorded approval before a deploy, and none exists today. The settings below are a proposed design; we validate the APIs, edition and permissions for each implementation.
Proposed tool policy
| Tool or toolset | Purpose | Read/write | Approval needed |
|---|---|---|---|
| retrieve_metadata | Pull components from a sandbox into the local project | Reads the org, writes local files | No |
| run_soql_query | Query sandbox data while debugging | Read | No; sandbox only |
| code-analysis toolset | Analyse code for issues | Read | No |
| run_apex_test, run_agent_test | Run tests in a sandbox | Executes in the org | No in a sandbox; never against production |
| deploy_metadata | Deploy to an org | Write | Yes, a named reviewer, and never to production from the AI client |
| assign_permission_set | Change user access | Write | Yes, admin approval |
| DevOps Center commit and promote | Move work through the pipeline | Write | Yes, release manager |
| create_scratch_org (non-GA) | Create a scratch org | Write | Developer's choice; non-GA flag off by default |
| delete_org (non-GA) | Delete an org | Write, destructive | Not enabled |
Authentication and access control
The server uses the developer's Salesforce CLI authorisations, so whatever orgs that CLI can reach, the AI client can potentially reach. Our rules:
- Name one org. Pass
--orgswith a specific sandbox or scratch org alias; do not useALLOW_ALL_ORGS. - No production credentials in an AI client without controls. Do not authorise production in the CLI profile the assistant uses; production changes go through your pipeline and its approvals.
- Enable only needed toolsets, for example metadata, testing and code-analysis, rather than all.
- Leave
--allow-non-ga-toolsoff except in a throwaway scratch environment. - Secrets: Salesforce notes that the CLI no longer prints secrets, and the
SF_TEMP_SHOW_SECRETSworkaround ends on 28 October 2026. Do not work around it.
The server runs as a local process (its repository does not name the transport), and the MCP specification says local stdio servers take credentials from the environment rather than an OAuth flow, so the developer machine itself is the trust boundary.
Approvals for write actions
Deploys, permission changes and DevOps Center promotions need a named person's approval. Simplest: the AI prepares the change locally, and the deploy runs from your pipeline after review. See Salesforce deployment strategies.
Privacy, limits and auditability
Sandboxes can hold copies of production data; use masked or seeded data where you can, and check with your legal adviser on the rules that apply to you. API limits of the target org still apply; check Salesforce's limits. Org-side activity is attributed to the authorised user; keep pipeline logs for every deploy.
Errors, environments and testing
A failed deploy or test returns an error to the assistant. Treat it as information, not permission to retry with broader settings. Pilot with two or three developers on scratch orgs, review what the assistant attempted, then widen. Release patterns are in CI/CD and release management.
Licensing and dependencies
The server is open source under Apache-2.0; the orgs, DevOps Center and any Agentforce testing features follow your Salesforce licences. Winter '27 materials refer to DevOps Center as "Lifecycle Center (formerly DevOps Center)".
Available today vs proposed
| Item | Status |
|---|---|
| Salesforce DX MCP Server | Per-tool GA or NON-GA; whole-server GA not confirmed |
| GeekMidst toolset and approval policy | Proposed design |
Related
Salesforce DevOps and release management
Pipelines, environments and approvals
→Salesforce development services
Apex, LWC and Flow development
→CI/CD and release management
The reference architecture
→Salesforce MCP integration
Hosted MCP for Sales and Service
→MCP integration overview
All vendor servers and their status
→Questions we hear
Is the Salesforce DX MCP Server generally available?
Can it deploy to production?
What does --allow-non-ga-tools do?
Do we need the Salesforce CLI?
Sources
Set up AI-assisted Salesforce development safely
Tell us how your team builds and releases today. We can configure toolsets, org access and approvals for a pilot.
