Connecting Claude to Your Salesforce Org, Step by Step

In Part 2 we activated a hosted MCP server and chose its tools deliberately. Today we connect the other end of the wire: Claude itself.

By the end of this article, you’ll be able to type a plain-language request into Claude and watch it call real tools in your real org, as you, with your permissions. The first time it works is a small “oh” moment. I’ll walk you through every step, and then we’ll make that first request together — carefully.

The shape of the connection

Before the clicks, hold this picture in your head:

1. Your org’s hosted MCP server (GA since April 29, 2026) sits at a URL, exposing the tools you chose.
2. Claude supports custom connectors — you give it an MCP server URL, and it knows how to speak the protocol.
3. The bridge between them is OAuth: you sign in to Salesforce as yourself, and from then on every tool call Claude makes runs as you.

That third point is the one to internalize. Claude never holds a password, never gets an integration user, never becomes some anonymous system actor. It borrows your identity, with your consent, within your permissions — and everything it does is audited under your name.

Step 1: Get your server URL

From the MCP Servers page in Setup — the same page where you activated the server in Part 2 — grab the server’s URL. This URL is your org’s MCP endpoint, the address Claude will connect to.

Copy it somewhere handy. That’s the only artifact you need from the Salesforce side.

Step 2: Add a custom connector in Claude

In Claude, go to your connector settings and add a custom connector. Claude asks for one thing: the server URL. Paste in the URL from Step 1.

That’s genuinely it for configuration. No client secrets to paste, no API keys to generate and store, no consumer key ceremony. If you’ve done classic Salesforce integrations, your instincts are bracing for a Connected App checklist — it doesn’t come. The connector just needs to know where the server lives; identity is handled next, interactively.

Step 3: Sign in — the OAuth moment

When the connector is added, Claude initiates an OAuth sign-in. A familiar Salesforce login screen appears. You sign in as yourself — your real username, your real credentials, the same user you are every morning.

Two things worth understanding about this handshake:

It uses PKCE (Proof Key for Code Exchange, said “pixie”). Without turning this into a security lecture: PKCE is the modern OAuth extension that protects the authorization flow from interception, so the sign-in can complete safely even without a pre-shared client secret. It’s the current best practice for exactly this kind of connection. You don’t configure it — it’s simply how the flow works — but it’s why the setup could be this simple without being sloppy.

Consent is explicit. Conceptually, what Salesforce shows you at this point is a consent prompt: this external application is asking to act on your behalf — do you allow it? You are the user, you see what’s being requested, and you say yes or no. Nothing is silently granted behind your back. If you’ve ever authorized a third-party app against your Google account, the ritual will feel familiar. Read it — I say that as the teacher in me, because clicking through consent screens unread is a habit worth breaking — then approve it.

Once you approve, the handshake completes and Claude holds a token that says: this session acts as this user.

Step 4: Watch the tools appear

Here’s the part of MCP I find quietly elegant. You don’t tell Claude what tools exist. It asks.

Once connected, Claude discovers the tools your server exposes — the exact list you curated in Part 2, each with its name, description, and input schema. This is why we spent a whole article on tool selection and why Part 4 will obsess over descriptions: what Claude discovers here is all it knows about what your org can do. The tool list is the vocabulary; your descriptions are the dictionary.

Take a moment to look at the discovered list in Claude and confirm it matches what you chose. If a tool you expected is missing, the fix is back on the MCP Servers page in Setup — adjust the exposed tools there, and Claude picks up the change.

Step 5: The first careful request

Now the fun part — done deliberately.

Start with a read. Don’t open with your most powerful tool. Ask something small and verifiable:

“Look up the lead Anna Weber from Munich and summarize where she stands.”

Watch what happens. Claude decides a tool is needed, picks one from the discovered list, and calls it. Every call runs as you, the authenticated user — so if your profile can’t see a field, Claude can’t see it either. The response comes back and Claude turns it into an answer.

Verify against the org. Open the same record in Salesforce and check the summary. Boring? Yes. Skip it anyway at your peril — this is the step that builds calibrated trust instead of blind trust.

Then try something that writes. In my Urla Shoes org, this is where I ask:

“Qualify this lead — she’s from Munich, works at a 200-person retailer, and asked about bulk pricing.”

Claude calls my LeadQualificationService tool. The Apex scores the lead — Hot, as it happens, with the DACH bonus for a German address — and auto-creates a follow-up call task. One sentence in, one scored lead and one task out. When we onboard a reseller, the OnboardReseller tool goes further: it derives the tier and commission and creates the Account, Contact, Opportunity, and Quote in a single request.

The first time I did this, I went straight to the org to check. The lead was scored, the task existed, and both were stamped with my name — created by me, because as far as Salesforce is concerned, it was me. That’s the model working exactly as designed.

What to check when something’s off

A short field guide from my own stumbles:

• Connector won’t connect: re-check the server URL, and confirm the server is actually activated in Setup — a deactivated server is just a dead address.
• Sign-in loops or fails: you may be signing in to the wrong org (production vs. sandbox is the classic). The URL determines which org you’re talking to; your credentials must belong to it.
• Tools don’t appear: confirm they’re on the server’s exposed-tools list in Setup. Claude can only discover what the server offers.
• A tool call fails with an access error: that’s usually not a bug — that’s WITH USER_MODE and your permissions doing their job. Claude hit something your user can’t touch. Fix the permission question first; the tool will follow.

Where we are

You now have the full loop: a curated server, an OAuth-connected Claude, discovered tools, and a verified first request — every call running as a real, audited user.

Everything so far has used tools as given. In the next article we build our own: a small, bulk-safe Apex @InvocableMethod, exposed as an MCP tool through McpServerDefinition metadata. That’s where your org’s specific business logic — the things only your company does — becomes something you can ask for in a sentence.