Skip to main content

2. Setup - Salesforce MCP

Note: The video covers material not in the guide below — please watch in full.

Action Step

Complete this before moving on.

Follow along and set up a Salesforce MCP yourself using the Salesforce Ultimate Skill — make sure you actually use the skill, it does 80–90% of the work. Confirm the prerequisites first: an Enterprise-edition-or-higher org, system admin access, the Salesforce CLI installed and authed (Claude can handle that), and a paid Claude account (connectors aren't on the free tier). Copy the Ultimate Skill path and tell Claude to use it to connect via CLI and create/deploy an ECA, then activate the sObject Reads MCP server inside Salesforce setup and grab the server URL and consumer key. In Claude, add a custom connector (client ID = the consumer key, leave the client secret blank), connect, OAuth, then QA it by asking Claude to use the connector to read something. If you need a second Salesforce connector on the same machine, remember the workaround: add a ?org=name parameter to the end of the URL.

Comment in Slack

Post your answer in your onboarding channel.

What was your biggest takeaway(s) from this training?

Training Guide

To set up the Salesforce MCP, we've baked everything into the Salesforce Ultimate Skill. This guide walks the same flow the video does — get the skill, check the prerequisites, let Claude build the ECA, activate the server, and wire up the connector.

Start with the skill that runs the whole thing.

The Salesforce Ultimate Skill​

The Ultimate Skill lives in our Claude Marketplace. My preferred way to grab it: open the marketplace, make sure you have the latest version, then reveal it in Finder (or just copy the link).

It's called the ultimate skill because of its references folder. The main skill file is really a pointer to any of the other references — MCP Salesforce setup, general context on what the Salesforce MCP is, how to set up the ECA app, Salesforce-to-n8n, sandboxes, plus a number of scripts for Salesforce metadata and a README. The easiest workflow is to copy the link, go to VS Code, and say: "use this skill to connect via CLI to my Salesforce org." The skill also carries the info for connecting to the Salesforce CLI, assuming you have the Python, Node.js, and NPM prerequisites installed.

Before any of that runs, your org and account have to qualify.

Prerequisites​

A few things have to be true before this works:

  • The org must be Enterprise edition or higher — hosted MCP doesn't exist below Enterprise.
  • You must be the system admin, so you can log in, create an external app, and change the MCP settings.
  • The Salesforce CLI must be installed and authed on your machine (Claude can handle this for you).
  • The company you're installing for needs a paid Claude account (Pro / Team / Enterprise) — connectors aren't on the free tier.

With those in place, the skill does the heavy lifting.

What the Skill Does​

Once you launch it, Claude runs steps one through four via the Ultimate Skill: verify the org, create the external app with its metadata files, deploy it to the org, and extract the consumer key you'll need for the Claude connector.

When building fresh, it writes all the files using the template inside the skill, dry-runs everything, then deploys to production — which is fine here because ECAs aren't inherently destructive. One thing to manage: because Claude has to draft those files somewhere to deploy them, they land in a project folder on your machine. Create a clean, named folder (like SFDC-Academy-Demo) and have Claude move the files there — staying organized makes this much easier.

There's also a JWT gotcha worth knowing — a config flag (JWT set true/false) that caused a week of issues to track down. We fixed it and then, in the age of AI, just updated the skill so it never happens again.

The next piece can't be done from the CLI.

Activating the MCP Server​

Activating the MCP server cannot be done through the CLI — it's done in Salesforce setup. Go to MCP → MCP Servers → sObject Reads → View Details → Activate. By default, if the client hasn't activated it yet, it'll show as not active, so you flip it on there.

That screen also gives you the server URL (the MCP URL). If you ever need to pull the consumer key manually, it's under Settings → OAuth settings, alongside the consumer secret — never show those on a recording.

Now you connect it to Claude.

Wiring Up the Claude Connector​

In Claude, go to Customize → Connectors → add a custom connector. Give it a name, paste the MCP URL (the server URL), and set the client ID to your consumer key — they match. Leave the client secret blank. Click Add, then Connect, then Allow, and it bounces you back to Claude with the connector live.

You'll see it exposes read-only tools. Inside the Claude desktop app, my preference is to allow all the read tools so it has read permissions on everything by default.

One thing that took a while to figure out: running more than one of these.

Pro Tip: Multiple Connectors​

Every Salesforce instance uses the exact same MCP server URL — the only thing that makes each unique is the connector config. So if you try to add a second one, you'll hit "a server with this URL already exists."

The workaround: add a parameter to the end of the URL — ?org=name (the value doesn't matter; use the client's name). Now you can have two connectors side by side. As operators coming into client orgs, you'll commonly have multiple of these on one machine, so this matters.

There's also a setting that changes how reps get the connector at all.

The Org-Level Connector Allow-List​

Many teams we work with turn on a security setting that limits which desktop extensions the team can install. When it's on, users can only install connectors that have been added to an org-level list.

So there's enablement here: the org admin goes to Organization Settings → Connectors → Add, and adds the web custom connector (there's a web one and a desktop one — use web). Once they do, Salesforce shows up grayed out for everyone in the org, and reps just complete the OAuth — they never touch the custom-connector setup. With that setting on, reps won't even see "add a custom connector," so the admin step is required.

Last, the part that makes or breaks a client rollout.

QA Close to Reality​

After it's connected, test it: "use the Salesforce connector to..." (if you have multiple, specify which org). A heads-up — the auth can be finicky: the desktop side may look errored while it actually worked in Claude.

The bigger theme is QA-ing as close to the customer's reality as possible. Even though you can access a client's connector from your own account, the real confirmation comes from a Claude seat inside their instance, where you test exactly how a rep would. Case in point: Coactive's head of IT didn't even have a Salesforce account, so he could add the connector at the org level but couldn't verify it worked. A seat in their org lets you fully test — and later run demos of the plugins and skills you build for them, in their exact setup, before you deploy to the rest of the team.

Wrap-Up​

Setup comes down to: use the Salesforce Ultimate Skill, clear the prerequisites, let Claude build and deploy the ECA, activate the sObject Reads server, and wire the consumer key into a custom connector with the client secret blank. Keep the ?org= multi-connector trick and the org-level allow-list in your back pocket — and always QA from inside the client's instance. Next, we'll get into the client-specific issues we ran into doing this for real.