Everyone’s showing you Salesforce inside Claude. Almost no one’s explaining what’s underneath it. Let’s fix that.
If you’ve been anywhere near LinkedIn this year, you’ve seen the demo. Someone opens Claude, asks for their pipeline by geography, and a dashboard just… appears. Nobody opened Salesforce. The room gasps. The post gets 4,000 likes.
Great. But if you’re the architect who has to actually build on this, “it just appears” is not an answer. So here’s the post I went looking for and couldn’t find: what MCP actually is for Salesforce — the real, shipped, generally-available version, minus the keynote gloss.
No hype. Just the plumbing, and why it changes how you think about your org.
First, what MCP even is
MCP — the Model Context Protocol — is a standard way for an AI client to call into a system through a stable set of tools.
That’s the whole idea. Instead of every AI product inventing its own bespoke integration with every app, MCP gives them a common contract: the system exposes a set of tools (read this, create that, run this query), and any compliant AI client — Claude, and others — can discover and call them.
If you’ve built integrations for a living, your instinct is right: this is an API surface, described in a way a model can reason about. The novelty isn’t the transport. It’s that the consumer is a language model, so the tools are self-describing and the model decides which one to call.
What Salesforce actually shipped
Here’s the part that matters, and the part I want you to be precise about: Salesforce Hosted MCP Servers went generally available in April 2026, for Enterprise Edition orgs and above. (It walked the usual path — pilot in spring 2025, beta in October, GA in April.)
“Hosted” is the key word. Salesforce runs the server for you, inside the platform. You don’t stand up middleware. You don’t host a Node process on some box that becomes a liability at your next security review. Your AI client connects to a Salesforce-hosted endpoint, and the tools are already there.
And before you assume this is a “call sales” feature: every Developer Edition org gets it free. So you can spin up a scratch org tonight and poke at the exact thing in this post — no procurement meeting required.
And you don’t get one server. You get a family of them.
The standard servers you already have
Salesforce ships a set of prebuilt standard servers, and the first family is organized around your data — the SObject servers. There are four of them, split by how much damage they can do:
sobject-reads— read and query only. No create, no update, no delete. Salesforce literally calls it the safest of the family. Under the hood it’s six tools: fetch an object’s schema, run a SOQL query, do a text search, get the current user, list recent records, and traverse relationships.sobject-mutations— create and update. Notably, no delete.sobject-deletes— the delete-focused one.sobject-all— full CRUD plus query, search, and relationship traversal. The whole toolbox, about eleven tools.
Stop and appreciate the design here, because it’s not an accident. The split by operation type is the governance model. You don’t hand an AI client sobject-all because it’s convenient. You hand it sobject-reads if all it needs to do is answer questions — and now “the AI wrote to the wrong record” is not a sentence anyone can say, because the read-only server has no write tool to call. Least privilege, expressed as which server you connect. We’ll come back to that idea hard later in the series.
Beyond data, there are product servers — the ones live and GA today include Data 360 (query your unified customer data) and Tableau Next (discover semantic models, query KPIs, run analytics). There’s also a Headless 360 server that reaches into the breadth of Salesforce Setup and platform capabilities — but that one is still Beta, so file it under “coming,” not “count on it.”
And then it gets interesting – custom servers
Standard servers are the floor. The ceiling is that you can build your own.
In Setup, an admin can compose a custom server — one URL that bundles tools from several standard servers plus your own tools. And your own tools can be backed by things you already know how to build: an autolaunched Flow, an Apex invocable action, an @AuraEnabled method, a custom REST endpoint, an API Catalog entry, a Prompt Builder template.
For a Flow or an invocable action, Salesforce reads your input and output variables and generates the tool schema for you. You describe what the Flow does; the model gets a callable tool.
Sit with that for a second, because it’s the whole game. It means the thing you expose to an AI doesn’t have to be raw “create a record.” It can be submit_expense or set_my_availability — a real business action, with your rules baked in. That’s a whole post on its own (it’s Post 3), so I’ll leave it as a promise for now.
The mental shift — this is the actual point
Here’s what I want you to take away, and it’s bigger than any single feature.
For twenty years, the way you got value out of Salesforce was to log into Salesforce. The UI was the product. The screen was the only door.
MCP quietly removes that assumption. Your org becomes a set of callable tools — and the UI becomes one way in, not the way in. The rep who wants a rich screen still gets it. The rep who’d rather never log in and just ask a question in the tool they already live in… now can. Same org underneath. Different door.
Which reframes the architect’s job, at least the way I see it: the interface is turning into a commodity, and the thing worth designing is what your org can actually do — and who’s allowed to do it. That’s not a Salesforce slogan; it’s just where I’ve landed after building on this. You’re welcome to disagree — that’s what the rest of the series is for.
What this post deliberately skipped
I didn’t touch security, permissions, or the licensing bill — and there is a licensing bill. I didn’t get into the difference between using this as a developer versus wiring it up for a business user, which turn out to be almost two different products. And I didn’t show you how to build a real persona server.
That’s the series:
- Post 2 — the dev/admin door.
- Post 3 — the business-user door: exposing intent, not raw CRUD.
- Post 4 — governance and the licensing conversation, including the one Apex keyword everybody’s about to forget.
But you can’t reason about any of that until you know what’s actually in the box. Now you do.
Until next time! 🙂
Pingback: Salesforce Builder's Door: Dev CLI vs Admin Chat (MCP)