Salesforce MCP Server vs. an AI That Can Build

People keep asking whether Claude has a Salesforce connector. The answer is yes, and it is better than the word “connector” suggests: Salesforce ships its own hosted MCP servers, they went generally available this year, and connecting an AI to your org is now a documented three-step setup rather than a weekend project. If your goal is to let an AI read, query, and act inside your org under your own permissions, the Salesforce MCP server is the right answer and you should turn it on.

This post is about the other goal. Because the question I get next, usually within a week, is some version of: it can see everything — so why can’t it build the thing I actually needed?

That is not a complaint about the MCP server. It is a category line, and it is worth drawing precisely.

What the hosted MCP server actually gives you

Salesforce’s own framing is the clearest one. The hosted servers expose “your org’s logic and assets — data, flows, Apex actions, queries, and more” to an AI client, with “OAuth and PKCE” controlling access and transactions running “as the authenticated user.” Your existing permission model comes along for free: “CRUD, FLS, sharing rules, and all the other controls you’ve already mastered.”

That last part deserves more credit than it usually gets. A large share of the anxiety about pointing an AI at a CRM evaporates the moment the AI is subject to the same profile, the same field-level security, and the same sharing rules as the human who authorized it. Salesforce did not bolt a new permission system onto this. It reused the one you already run.

The standard servers cover the platform, Data 360, Tableau, and MuleSoft, with a Slack server alongside them. Connecting Claude means activating the servers, creating an external client app, and pointing the client at it — with PKCE and JWT-based access tokens required, and “standard Salesforce user access permissions apply in addition to the app-level access checks.”

Where this is genuinely the right answer

Be honest about the wins, or the rest of this post is just marketing.

If what you want is an AI that answers questions about your pipeline, drafts follow-ups off real record data, runs a Flow you already trust, or pulls a number you would otherwise have exported to a spreadsheet — the hosted MCP server is the whole solution. No infrastructure. No third party holding credentials. Vendor-maintained. Governed by the permission model your admins already tuned.

There is no version of this argument where I tell you to build that yourself. Turn on the servers, connect your AI, and go. Our own walkthrough of connecting Claude to a Salesforce org exists precisely because this step is worth doing carefully and worth doing first.

The line shows up later.

Every tool is something somebody already built

Here is the structural fact about any MCP server, Salesforce’s included: it is a catalog of tools, and each tool is an operation that already exists.

A Flow you can invoke is a Flow somebody built. An Apex action the AI can call is Apex somebody wrote. A query it can run is a query against fields that already exist on objects that already exist. The catalog is a very good remote control for your org’s current capabilities. It is not a mechanism for adding new ones.

So when your AI reports back that it can’t roll up child records onto the parent because the field isn’t there, it is not being unhelpful. It is telling you the truth about the surface it was handed. Somebody has to create the field, write the logic, test it, and deploy it. That work is development, and development happens through a different door.

Custom servers move the line — but not past it

This is where Salesforce goes meaningfully further than most platforms, and the distinction is worth being precise about.

You are not stuck with the standard catalog. Salesforce lets you build custom servers that expose your own Apex Actions, Lightning Flows, Apex REST endpoints, and AuraEnabled methods as MCP tools, plus custom prompts from Flex prompt templates. That is a real extension point, and it is more open than a fixed vendor tool list.

But read the requirement inside it. Every one of those is something you write first and expose second. Custom servers let you decide what your AI can reach. They do not change who writes the thing it reaches. If the answer to that is still “a developer, when one is free,” you have improved the interface to your backlog without touching the backlog.

And the flip side is worth saying plainly, because it cuts against the lazy version of this argument: a custom server can absolutely expose something powerful and destructive. If you write an Apex method that bulk-updates records and expose it as a tool, an AI can call it. The catalog is exactly as sharp as what you put in it. “Read-only and safe” is a property of the tools you chose, not of MCP.

The comparison, plainly

	Salesforce hosted MCP server	An AI that can develop the org
Core job	Let an AI use your org	Let an AI change what your org does
What it reaches	Existing data, flows, Apex actions, queries	The metadata layer — new fields, objects, logic
Auth model	OAuth + PKCE, runs as the authenticated user, CRUD/FLS/sharing apply	Org auth for deploys, sandbox-first with tests required
Ceiling	The tools that exist, standard or custom	What you can describe and validate
Who writes the new thing	A developer, before it can be exposed	The AI, with the deploy reviewed and recorded

The two are not competitors. They are different layers, and most orgs eventually want both: MCP as the connective tissue for using the org, and a build path for changing it.

What building needs that access doesn’t

Once an AI is deploying rather than querying, four requirements appear that a connection alone never has to answer.

Somewhere to run that isn’t a laptop. A deploy that matters shouldn’t depend on whose machine was awake. That’s the case for a dedicated server for CRM development work, not a convenience preference.

A deploy surface with a rehearsal. For Salesforce that means the Metadata API and sandbox-first deploys with tests required — the difference between building a custom object properly and improvising in production.

A record of who asked. Running as the authenticated user is excellent for permissions, and it is not the same as knowing which teammate’s session initiated which change. Both facts matter; they answer different questions.

A way back. Snapshots before deploys, so a change that succeeds and turns out to be wrong is recoverable rather than archaeological.

That is the actual shape of the gap. Not intelligence. Not model quality. Infrastructure around the act of changing something.

The honest trade

Sentinel gives your AI the hands to build in the org — its own server, MCP connections with unlimited read keys and one write key at a time, sandbox-first Salesforce deploys, an audit log of what happened, and a snapshot before each deploy so there’s a way back.

What it does not do is prevent your AI from making a change you’ll regret. Nothing that is genuinely useful can promise that and stay useful. The trade is deliberate: everything is visible and everything is recoverable, rather than restricted into safety. If you want a system that blocks its own AI from doing anything consequential, you want the hosted MCP server with read-only scopes, and that is a legitimate choice — it’s just a different product than one that ships work.

Pricing, so it’s not a mystery: $2,500 one-time onboarding on your first Sentinel, then $500/month per Sentinel.

Which one you actually need

Ask what the last thing you wanted from your CRM would have required.

If it was an answer, a lookup, a draft, or a run of something that already exists, the Salesforce MCP server covers it, and you can be connected today. If it was a field that isn’t there, an object your process needs, logic the standard model doesn’t cover, or an integration nobody sells — then the constraint was never access. It was that the smallest unit of Salesforce development you can buy has always been much larger than the job, which is why so much of this work never gets done at all.

Connecting your AI to the org is the easy half, and Salesforce has made it genuinely easy. Deciding what should happen when the thing you need doesn’t exist yet is the half worth having a plan for.

Give your AI a place to build from — set up your Sentinel, onboarding included.