Platform
Claude Code for Salesforce: the official plugin, the MCP servers, and the skills library
Salesforce now ships an official plugin for Claude Code. It detects your DX project, loads a set of Salesforce skills, wires in the CLI and Salesforce-hosted MCP servers, and puts safety gates on deploy. This is what it contains, how the three-tier resolution works, what the open skills library is, and the guardrails I would set before letting it near an org.
Until this summer, using Claude Code on a Salesforce project meant teaching it Salesforce yourself. You pasted in conventions, pointed it at the CLI, and hoped it remembered that a trigger runs in bulk. Every developer did this separately and every one of them did it differently.
Salesforce’s answer is an official plugin, published on Anthropic’s plugin directory as Salesforce Development and announced under the Claudeforce partnership in August. Open Claude Code in a Salesforce DX project and it detects the environment, injects your org’s context, and works through a set of validated skills, the Salesforce CLI, and Salesforce-hosted MCP servers. The plugin page’s own summary of what it covers: metadata authoring, Apex, deploy and retrieve with safety gates, security review, reporting, and discovery of what is installed versus available in the org.
Part of the plugin is a piece of the wider Agent Skills story I wrote about in August, part is the DX MCP server from July, and part is new. This post is the practical version: what it contains, how it decides which tool to use, what to set up, and where I would stop it.
What the plugin contains
The plugin page lists three things it works through and one thing it needs.
Skills. A curated subset of the Salesforce skills library, which is the open-source forcedotcom/sf-skills repository on GitHub. Each skill is a folder with a SKILL.md file carrying instructions and YAML front matter, plus optional scripts, references and assets, in the open Agent Skills format that Claude Code, Cursor, Codex and OpenCode all read. The repository’s examples give the flavour: platform-apex-generate, platform-custom-object-generate, automation-flow-generate. The README does not state a total, and coverage has quoted anything from sixty to more than a hundred, so I will say dozens and growing.
The Salesforce CLI. The plugin drives sf for the things the CLI already does well: authentication, deploy, retrieve, running tests, querying an org. Nothing new is invented where a CLI command exists.
Salesforce-hosted MCP servers. For live org context and operations the CLI does not cover, the plugin uses the hosted MCP servers Salesforce made available in May, the same family that underlies Headless 360. Salesforce Ben’s Winter ‘27 developer coverage describes the plugin as grounding itself through those servers.
The prerequisites listed are the Salesforce CLI, Node.js LTS, Python 3.8 or later, and an org authorised with sf org login web. The page is marked as made by Salesforce and verified by Anthropic. It does not list a price, and the plugin itself is free to install; what you pay for is the Claude Code seat and the org.
How it decides which tool to use
The one line on the plugin page worth memorising: capabilities resolve in three tiers, skills first, then the Salesforce CLI, then Salesforce MCP.
That order is the design. A skill is a written instruction set, so it is the cheapest and most predictable way to answer “how do I write a bulk-safe trigger” or “what does a custom object need”. If the skill cannot complete the task, the plugin drops to the CLI, which is deterministic and logged. Only when neither can do the job does it go to an MCP server, which is a live call into the org.
For anyone who has watched a coding agent call a live API to answer a question it could have looked up, the ordering is the point. It keeps the model’s org access as the last resort, and it means most of what the plugin does is reproducible by reading the skill it used.
It also tells you where to invest. If your team has conventions the library does not cover, an object-naming standard, a logging framework, a rule about when Flow beats Apex, the right place to put them is a skill in your own repository, because the plugin will reach for a skill before anything else. The decision guide on Flow versus Apex is the kind of thing that becomes a skill.
The library is the durable part
The plugin will change. The skills library is the piece that outlives it, because it is a plain-text format under an Apache 2.0 licence that every agent tool reads.
Salesforce’s own framing is that the library is optimised for Agentforce Vibes, where skills auto-install and auto-update, and usable in any tool that supports skills. The install for everything else is one command, npx skills add forcedotcom/sf-skills, and the repository carries a .claude-plugin directory alongside the skills, which is how the Claude Code packaging is built.
Two consequences follow. A skill your team writes for Claude Code works unchanged in Vibes, Cursor or Codex. And the reverse: a developer who prefers a different tool is not locked out of the standards, because the standards are files in a repository, not a feature of one product.
The thing to watch is drift between your fork and upstream. Salesforce updates the library, and a skill you customised in March may conflict with the version it ships in September. Treat the library as a dependency with a version, not as a folder you edited once.
What to set up before the first session
Four things, in the order I would do them.
Authorise a sandbox, never production. The plugin detects the org from the DX project’s default target. If that default is production, every retrieve and every deploy the agent proposes is aimed at production. Make the default a developer sandbox or a scratch org and keep it that way. Your sandbox strategy should already say which one.
Read the safety gates. The page says deploy and retrieve carry safety gates but does not describe them. Run a deliberately bad deploy in a scratch org and see what the plugin does with it before you trust the gate with anything that matters.
Decide which skills are on. A subset of the library ships with the plugin, and you can add more or add your own. Review the list the way you would review a linting config, because every skill is an instruction the agent will follow.
Wire it to your tests. The plugin can run Apex tests through the CLI. Make that a habit, and if you have adopted integration tests that hit real callouts, decide whether the agent may run those, since they touch real endpoints.
Where I would stop it
The plugin can deploy. I would not let it deploy anywhere a person has not looked, and the arrangement I would want is the one Slack describes for Slack Code: the agent packages the change, a person runs the release.
The reason is not that the code will be bad. The code from a skill-guided agent is often better than the average human commit, because the skill encodes the standard every time. The reason is that a deploy is the moment a mistake becomes a production incident, and the agent has no way to know that the field it just added is the one an integration reads. That knowledge lives in your release process, so keep the deploy there.
The other thing to keep away from it is security review as a substitute for your own. The plugin includes a security-review capability, and it is useful for catching the obvious: SOQL built from user input, missing sharing declarations, hard-coded IDs. Run it. Then run your own scanner, because one review that the same agent wrote and reviewed is not two reviews.
Understanding the basics
What is the Salesforce Development plugin for Claude Code?
An official plugin, published by Salesforce on Anthropic’s plugin directory, that detects a Salesforce DX project, injects org context, and works through validated skills, the Salesforce CLI and Salesforce-hosted MCP servers. It covers metadata authoring, Apex, deploy and retrieve with safety gates, security review, reporting and discovery of what is installed in an org.
What is the Salesforce skills library?
An open-source repository, forcedotcom/sf-skills, of Salesforce development skills in the Agent Skills format. Each skill is a folder with a SKILL.md file and optional scripts and references. It installs into any tool that supports skills with one command and is pre-installed in Agentforce Vibes.
Does the plugin need access to my production org?
No, and it should not have it. The plugin uses whichever org your DX project targets. Point the default at a sandbox or scratch org, and keep production deploys in your normal release process with a person running them.
How does the plugin decide between a skill, the CLI and an MCP server?
In that order. Capabilities resolve skills first, then the Salesforce CLI, then Salesforce MCP. A skill answers from written instructions, the CLI runs deterministic commands, and MCP is used only when the task needs live org context neither of the others can give.
Standards you can read
The best thing about the plugin is not the model. It is that the standards it follows are files you can open. When a developer asks why the agent wrote a trigger a particular way, the answer is a SKILL.md in a repository, with a version, that your team can change.
Point it at a sandbox, keep the deploy with a person, and put your own conventions in skills where the plugin will find them first.
If you want the plugin, the skills library and a sandbox-only release path set up for your Salesforce team, talk to us, or run the Apex security scanner on what your agents have already written.
