I Connected My Salesforce Org to Claude

The scenario

For years, "Salesforce integration" meant getting other systems into Salesforce. Headless 360 points the other way: it exposes platform capability as an API, an MCP tool, or a CLI command, so an assistant can reach your data without anyone opening a browser.

I put that to the test. I connected my org to Claude and asked it questions about my Accounts in plain English. It answered from live org data, through OAuth, with my permissions enforced on every call. Here's exactly how.

For beginners: MCP (Model Context Protocol) is an open standard that lets an AI assistant discover and call tools. A Hosted MCP Server is one that Salesforce runs for you: your org itself becomes the endpoint, so there is nothing to install and nothing to host.

First: two different things are both called "Salesforce MCP"

This tripped me up, so let me save you the confusion.

Salesforce DX MCP Server (@salesforce/mcp) runs locally on your machine. It's for developers — deploy metadata, run Apex tests, analyse LWC. Your AI coding assistant launches it as a child process, and it needs Node.js and the Salesforce CLI.
Salesforce Hosted MCP Servers run on Salesforce infrastructure. Your org is the endpoint. No local server, no Node, no CLI — just OAuth. This is for reaching Salesforce data and business logic from any MCP-aware client.

Rule of thumb: if the AI is helping you build Salesforce, that's DX MCP — covered in our DX MCP Server build. If the AI is helping someone use Salesforce, that's Hosted MCP. This walkthrough is the second one.

Step 1 — Enable MCP and activate a server

Setup → Quick Find → User Interface — confirm Enable Salesforce MCP is checked. In many orgs it already is.
Setup → Quick Find → MCP Servers → Salesforce Servers tab.
The standard servers are inactive by default. Click into the one you want and hit Activate. Give it up to two minutes.
Copy two things: the server's API Name (without the platform. prefix) and the Server URL.

The standard servers are deliberately graduated, so the server you pick is the first control you set:

Server	What it allows	Good for
SObject Reads	Query and read only — no writes of any kind	Your first connection. Start here.
SObject Mutations	Create and update, plus read and query; no delete	Assisted data entry and cleanup
SObject Deletes	Deletion operations only	Narrow, deliberate cleanup work
SObject All	Full CRUD plus query and search	Only once you trust the workflow
Data 360	Querying unified customer data in Data 360	Cross-source customer questions
Headless 360	Broad Setup and platform access via Discover / Describe / Dispatch tools	Admin and platform automation
Tableau Next	Semantic model discovery, KPI queries, analytics execution	Analytics questions in natural language

I started with SObject Reads, and I'd repeat that. It's read-only, risk-free, and immediately useful. There's no reason to hand an assistant write access before you've confirmed the pipe works.

Step 2 — Create an External Client App

This is the trust relationship between the client and your org. Note that classic Connected Apps do not work for this flow — it has to be an External Client App.

Setup → External Client App Manager → New External Client App.

Name it something obvious (Claude MCP Client App), add a contact email, distribution state Local.
Expand API (Enable OAuth Settings) → check Enable OAuth.
Callback URL: the redirect URI your client publishes. For the claude.ai web app that's https://claude.ai/api/mcp/auth_callback; a desktop or CLI client uses a localhost callback instead. Different surface, different URL — take it from the client's own connector screen rather than guessing.
Scopes: mcp_api, plus refresh_token and offline_access. Use mcp_api — not the standard Salesforce api scope. Hosted MCP expects the former, and the difference isn't obvious from the connector side.
Check these three: Require secret for Refresh Token Flow, Require PKCE extension for Supported Authorization Flows, Issue JWT-based access tokens for named users. PKCE is mandatory.
Deselect the other options — changing them later needs Salesforce support.

Click Create. Then:

Policies → OAuth Policies: Permitted Users → All users may self-authorize; IP Relaxation → Relax IP restrictions.
Settings → OAuth Settings → Consumer Key and Secret → complete the verification dialog → copy both.

Give the app time before you connect. An External Client App can take up to 30 minutes to become fully operational — much like a DNS propagation delay. Finish the configuration, then come back to it.

Step 3 — Add the connector in the client

In claude.ai: left sidebar → Customize → Connectors → + → Add custom connector.

Name: a convention that scales is salesforce- + the server's API name, e.g. salesforce-sobject-reads.
Server URL: the one you copied from Setup. Production and Developer Edition orgs use a /platform/ path; sandbox and scratch orgs use a /sandbox/ variant. Copy it rather than typing it from memory.
Advanced settings: paste the Consumer Key into OAuth Client ID, and the Consumer Secret alongside it.
Add, then Connect.

You're redirected to Salesforce to log in. If you're already logged into that org, it may skip the challenge entirely — that's the OAuth session doing its job, not a step being missed.

Step 4 — Verify it properly

Two prompts, and the second one matters more than the first.

Prompt 1 — does the pipe work?

List the first 10 Account records you can access in Salesforce.
Show the name, type, industry, and annual revenue when available.

I got my ten Accounts back with a tool call visible in the response. Three had no Annual Revenue populated, and the assistant said so rather than filling in a number — which is itself a good sign.

Prompt 2 — is the answer actually grounded?

Which two accounts look most important based on the fields available?
Explain your reasoning from Salesforce data only.

This is the real test. If the model reasons from the numbers that came back, you're grounded. If it starts describing those companies from general knowledge, it isn't using your data at all. If it answers without calling the connector, tell it to use the connector explicitly.

Common mistake: declaring victory after prompt 1. A plausible-looking answer proves nothing on its own — a model can produce one about well-known sample accounts with no org access whatsoever. Prompt 2 is what separates a working connection from a convincing guess.

The part I'd actually demo to a security team

Here's what makes this different from bolting an API key onto a chatbot.

The assistant never connects to your data directly. It calls the Hosted MCP server, and the request carries the authenticated user's OAuth token. Salesforce validates identity, then checks object permissions, field-level security, and sharing rules on every single tool call. The assistant only ever receives what that user could already see in Lightning.

The permissions and compliance controls your security team already approved don't get rebuilt — the guardrails your org relies on are the same guardrails the assistant operates within.

The five-minute demo: connect as a user whose profile hides a field, ask the same question, and watch the column disappear. Not because the model was told to hide it — because Salesforce never sent it.

Worth knowing before you scale this up

Choosing a scoped server is the control. The permission model is a safety net underneath it, not a substitute for picking the right server in the first place.
Don't collect all of them. Every connected server's tools load on every request. Overlapping tools make selection ambiguous and burn context. Add what you need.
Treat Salesforce records as untrusted input. Record content can carry indirect prompt-injection attempts aimed at influencing the assistant. Negligible with read-only access on seed data; very real once you enable write tools against records other people can edit.
Deletes go to the Recycle Bin — recoverable for 15 days — but there is no undelete tool exposed through MCP.
Give it its own identity when you go beyond a demo. A dedicated integration user with a least-privilege permission set makes the blast radius something you designed rather than something you inherited.

What this actually changes

The technical achievement here is modest. It's OAuth and a protocol.

What's interesting is the shift in where the work happens. My flows, my data model, my sharing rules, my validation — all of it stays exactly where it is. It just became reachable from somewhere else. Configure once, use anywhere.

The standard servers are only the first half. The next step is publishing your own logic as tools — an autolaunched Flow on a custom MCP server, then invocable Apex with real guardrails.

Sources: Hosted MCP Servers: Get Started · Create an External Client App · Connect MCP Clients · Standard Servers Reference · Salesforce Hosted MCP Servers Are Now Generally Available