1. Salesforce MCP Fundamentals
Note: The video covers material not in the guide below — please watch in full.
Action Step
Complete this before moving on.
Before the setup training, make sure you can explain the mental model in your own words. Lock in the three pieces and the door analogy — the MCP server is the door into the data, the ECA controls the lock, and the Claude connector is the key. Then be able to say when you'd reach for the CLI (the builder's tool — God mode, operators only, lives in Claude Code) versus the hosted MCP (the consumer's tool — per-user OAuth, nothing installed, what you hand the team). Ask Claude to quiz you on the difference, or write it up in a few sentences so it sticks.
Training Guide
There are two ways to access Salesforce data: through the CLI or through the MCP. Before we set the MCP up in the next training, you need the mental model for what it is and why it exists.
Start with the tool you already know.
Two Ways In
The CLI — command line interface — accesses Salesforce through the terminal, or the way we teach it at LeanScale: through VS Code, since Claude Code in VS Code is effectively the same as running it in the terminal. (If you're not familiar with connecting via the CLI, we have other trainings on that.)
The CLI is incredibly powerful — you can do pretty much anything through it that you can do logged into the Salesforce UI. The cons: you don't have much control over the permission set, there aren't many safeguards, and it's not something you can hand to the rest of the team.
That last point matters because most of our clients use AI inside Cowork, and Cowork isn't terminal-based — it's a mini virtual machine with a whole backend. You're not going to have a sales rep or a GTM leader running the Salesforce CLI.
So how do you get Salesforce to the whole team? The MCP.
Why the MCP Is the Team's Tool
The MCP is a completely different architecture from the CLI (the CLI actually interacts with the API). And Salesforce's MCP is Salesforce-hosted — they run the MCP server on their end, so Claude can talk directly to your Salesforce instance without installing anything locally. That alone rules the CLI out for the average user, since the CLI needs a number of packages installed and running locally.
The MCP also gives you per-user OAuth: each rep only sees what they can already see in Salesforce when they log in. If a change is made, the audit trail shows the rep's name — not a generic integration user, which is what you'd sometimes get with the API. This is exactly why InfoSec, IT, and security are all in favor of the MCP, and why it's becoming the standard way the rest of the org interacts with the CRM.
To set it up, you need to understand its three pieces.
The Mental Model: Three Pieces
There are three primary pieces to this infrastructure: the ECA (external client app), the MCP server, and Claude itself (where you wire up the connector).
Here's the analogy that ties them together: the MCP server is the door into the data, the ECA controls the lock on that door, and the Claude connector is the key you use to get through the lock. And because MCPs have become the industry standard — Claude, OpenAI, Gemini are all adopting them — once you set up Salesforce's MCP, it works with whatever model the client uses.
Let's open up each piece, starting with the lock.
The External Client App (ECA)
The ECA lives inside Salesforce: go to Setup, search Apps, and you'll find the External Client App Manager. It's the OAuth app — the thing that handles who can actually log in.
There's a Salesforce Ultimate Skill that does 80–90% of this setup for you (Claude builds and deploys the ECA using it), but you want the judgment to step in if something breaks — which is why the mental model matters. The ECA gives you a consumer key. In Claude, you go to Connectors → add a custom connector → advanced settings, and it asks for the name, the MCP URL, and the client ID. Note you don't use a client secret here. There's no official Salesforce connector yet because Salesforce's architecture works on a per-instance basis — hence the custom connector setup.
Next, the door itself.
The MCP Server
The MCP server is also set up inside Salesforce: Setup → MCP → MCP Servers → Salesforce Servers. That last step is an easy one to miss — if you stop at plain "MCP Servers," you'll wonder where yours are. You have to go to Salesforce Servers.
Just like standard vs. custom objects, there are standard MCPs and custom MCPs. We won't cover custom ones here, but that's where it gets really powerful. Nine times out of ten — as of mid-June '26 — we use the object reads standard MCP, because we haven't settled on the safest architecture for letting reps edit the CRM. Even with a human in the loop, someone gets lazy, says "yeah, do this," and the CRM blows up. Reads are plenty: they unlock reports, morning briefs, and pipeline hygiene once AI can treat the CRM as the single source of truth. The server is pre-built — you just click Activate, which gives you the server URL (the MCP URL from the connector step). There are different permission levels here, too — object deletes, API context, and so on.
With both pieces clear, here's the clean side-by-side.
CLI vs. MCP, Side by Side
The CLI is the builder's tool — how we, the operators, go in and build and configure the org. It logs in as you (usually the admin) with full God-mode access: data, metadata, SOQL queries, record edits, custom fields, Apex, even creating the ECA itself. It lives in Claude Code (terminal or VS Code), not Cowork or the browser. It needs installs and auth on every machine — fine for us on a single machine, no bueno for a whole sales team downloading NPM packages and Node.js.
The MCP is the consumer's tool — nothing installed, Salesforce-hosted, works on claude.ai, desktop, Cowork, and Claude Code. It's data only, no metadata: you can query and (if the edit MCP is on) edit records, but you can't deploy a custom field or change org config. It's scoped by whichever server you activate, with per-user auth limiting each rep to their own Salesforce permissions.
So: we use the CLI to build the MCP, then hand the go-to-market team the MCP connectors to use wherever they work.
Wrap-Up
The Salesforce MCP is how you get the CRM safely into the hands of the whole team — Salesforce-hosted, per-user OAuth, reads by default. Hold onto the door/lock/key model and the builder-vs-consumer split, because in the next training we'll actually build it, connect it to Claude, and deploy it properly.
Comment in Slack
Post your answer in your onboarding channel.
What was your biggest takeaway(s) from this training?