Andrew Hanna
Back to Articles
Andrew Hanna
Deploying Salesforce from Claude, Cursor and Agentforce: what a native MCP server changes
Short answer: a native MCP server lets an AI client such as Claude, Cursor or Agentforce call your DevOps platform's real release actions: plan a deployment, open a pull request, resolve a metadata conflict, trigger a pipeline. That is a different category from an AI that writes Apex into a file. Serpent runs the only native MCP server in Salesforce DevOps, and every agent-initiated deployment still passes a preflight check and a human approval before it reaches production.
What is a native MCP server in Salesforce DevOps?
Model Context Protocol is an open standard for connecting AI applications to tools and data sources. Salesforce announced MCP support across its stack in June 2025, starting with the Salesforce DX MCP Server, the Heroku Platform MCP Server and the MuleSoft MCP Server.
Native is the load-bearing word. A native MCP server is one the platform builds and operates over its own API, exposing the actions it already performs every day. A wrapper script that shells out to the CLI is not the same thing: it knows nothing about your projects, your environments, your approval rules or your audit trail.
How is deploying with an agent different from coding with one?
Most of the AI conversation in the Salesforce ecosystem is about generation. An assistant drafts a trigger, an LWC or a test class, and a human reads it before it goes anywhere. If the model is wrong, code review catches it.
Release work has no such buffer. A deployment is a state change in a live org, and the blast radius is business processes, not a pull request comment. So the question that matters is not whether a model can write good Apex. It is whether the tools the agent is handed are safe to call, and what stands between the agent's intent and production.
That is a tooling question, not a model question, and it is exactly where a DevOps platform belongs in the loop.
What can Claude, Cursor or Agentforce actually do?
Serpent exposes its release actions as MCP tools. The core four:
-
plan_deploy: work out what would ship, from which branch to which org, and show the delta before anything runs. -
create_pull_request: open the PR against the right branch, with the change attached to a work item. -
resolve_metadata_conflict: handle the profile, permission set and flow collisions that make Salesforce merges painful. trigger_pipeline: run the pipeline once a human has approved it.
The same server answers Claude, Cursor, Windsurf, Agentforce, Codex, Cline and GitHub Copilot, because MCP is client-agnostic. You are not buying an assistant. You are giving the assistant your team already uses a set of release tools it is allowed to call.
Where does Salesforce's own MCP support stop?
Salesforce has moved fast here, and the platform servers are genuinely useful. Salesforce Hosted MCP Servers let a client read and write sObjects, run invocable actions and start flows with no local install, and Agentforce has its own MCP client.
What those servers describe is an org. What a release needs is the layer above it:
- Which branch this change lives on, and which environments it has already cleared.
- Whether the target org has drifted since the last deployment.
- Who approved it, and against which work item.
- How to put it back if it goes wrong.
No org-level server carries that context, because it does not live in the org. It lives in the pipeline.
What stops an agent from deploying something it should not?
Four things, and they are deliberately boring:
- Preflight first. A deploy is planned and validated before it is run, so the agent proposes a concrete change set rather than a sentence.
- Mandatory human approval. No MCP call promotes to production on its own. The approval gate is not a setting the agent can talk its way past.
- Zero org footprint. Serpent installs nothing in your Salesforce org and connects over standard APIs only.
- A full audit trail. Every action is attributed and logged, encrypted at rest and in transit with AES-256. An agent-initiated deploy is as reviewable as a human one.
How do you get it running?
- Connect your orgs and your repository to a Serpent workspace.
- Add the Serpent MCP server to your client's MCP configuration, the same way you would add any other server.
- Authenticate with a personal access token, which is what ties every agent action back to a named user.
- Ask in plain language: plan the deploy from UAT to production for this work item.
- Read the plan, approve it, and let the pipeline run.
The MCP server is on every plan, including the free Essentials tier, so there is no add-on to buy before you find out whether agent-driven releases suit your team. See what Serpent does.
FAQ
Does the AI deploy to production on its own?
No. Every promotion to production requires a human approval step, whichever MCP client requested it.
Do I need to know Git to use it?
No. Serpent runs Git in the background, and the MCP tools speak in work items, environments and deployments rather than branches and rebases.
Which AI clients are supported?
Claude, Cursor, Windsurf, Agentforce, Codex, Cline and GitHub Copilot. Any MCP-compliant client can connect, because the protocol is client-agnostic.
Is this the same as the Salesforce DX MCP Server?
No, and the two are complementary. The Salesforce servers act on an org: records, metadata, flows. Serpent acts on the release: plans, pull requests, conflicts and pipelines.
Does it install anything in my org?
No. Serpent connects through standard Salesforce APIs and installs no package, so it adds nothing to your own security review scope.
