Last week I asked you to hold on to one idea: a remote MCP server that knows who you are can enforce your permissions. I told you something big was landing for Salesforce people. Here it is.
On April 29, 2026, Salesforce Hosted MCP Servers reached general availability. In one sentence: Salesforce now runs managed MCP endpoints for your org, exposing its data, flows, and custom Apex to any MCP client — Claude included — with your org’s own security model enforced on every single call.
I’ve been building against this in my Urla Shoes practice org, and I want to walk you through why this announcement is the pivot point of this whole series.
What was actually announced
Until now, if you wanted an AI assistant to reach into a Salesforce org over MCP, you had two realistic options: run your own MCP server that wraps the Salesforce APIs, or wait. Hosted MCP Servers remove the “run your own” part entirely.
Salesforce hosts the server. You don’t deploy anything to Heroku, you don’t stand up middleware, you don’t babysit an integration service. The MCP endpoint is a managed piece of the platform, run by Salesforce, in front of your org.
Your org is what it exposes. The tools the server publishes aren’t generic — they’re your org’s capabilities: reads against your data, your flows, and your custom Apex, surfaced as MCP tools that a client can discover and call.
Your security model comes with it. This is the sentence I’d underline twice. Every call runs as the authenticated user, through the org’s own sharing rules, object permissions, and field-level security — with audit trails. There’s no side door.
What “hosted” really means
The word “hosted” is doing a lot of quiet work here, so let me unpack it the way I would for a student.
When you host an integration layer, you own everything about it: the runtime, the patching, the scaling, the authentication code, the logging, the uptime. When Salesforce hosts the MCP server, all of that becomes their job — and, crucially, the security enforcement isn’t something you re-implement. It’s the same enforcement your org already applies everywhere else.
That last point deserves a moment. Hand-rolled middleware almost always authenticates as some integration user, then tries to simulate per-user security in application code. I’ve reviewed setups like that, and there’s always a gap — a field someone forgot to check, a sharing rule the middleware doesn’t know about. Hosted MCP doesn’t simulate your security model. It is your security model, because the call executes inside the org as the real user.
What you get out of the box
GA shipped with standard servers ready to activate, covering the ground most teams need first:
- Agentforce 360 — your Agentforce capabilities, reachable from an MCP client.
- Data 360 SQL — query your unified data with SQL, as a tool the assistant can call.
- Platform reads — the everyday “look this up in the org” operations against your records.
For a lot of teams, that trio alone justifies turning this on: an assistant that can check records, query data, and work with your agents, without a single line of integration code.
But the part that excites me as a developer is that the box is open. In my Urla Shoes org, I’ve taken custom Apex — plain @InvocableMethod actions, the same pattern you already use for flows and Agentforce — and exposed them as MCP tools through McpServerDefinition metadata. From Claude’s side, my hand-written business logic sits right alongside the standard tools, discovered the same way, called the same way. If you can write an invocable method, you can publish an MCP tool. I’ll dedicate a full article to that build later in this series.
The setup, at ten thousand feet
The whole configuration lives on two Setup pages, and I find the division genuinely elegant:
- External Client App — the OAuth bridge. This is where you define how clients authenticate: least-privilege scopes, PKCE, the modern connected-app pattern. It answers the question “who may connect, and with how much permission?”
- MCP Servers — where you activate a server and choose its tools. It answers the question “what may a connected client actually do?”
Identity on one page, capability on the other. Next week’s article walks through the External Client App step by step, because getting the OAuth bridge right is the foundation everything else stands on.
Why this beats hand-rolling middleware
Let me be concrete, because “managed is better” is easy to say and worth proving.
Security you don’t have to rebuild. The hardest part of any Salesforce integration layer is faithfully mirroring org security. Here, there’s nothing to mirror — enforcement happens in the org, per user, per call.
Audit trails by default. Every tool call is attributable to a real, named user. When your security team asks “who read that record through the AI assistant?”, you have an answer. With a shared integration user, you often don’t.
No infrastructure to own. No servers to patch, no OAuth code to write, no 2 a.m. pages when the middleware falls over. Your integration layer is now someone else’s SLA — and that someone is the vendor of the system itself.
A standard, not a bespoke API. Because the endpoint speaks MCP, any MCP client can connect — Claude via a custom connector today, and whatever clients emerge tomorrow. You configure the org side once.
Admin-shaped configuration. Activating a server and selecting tools is Setup work, not a development project. That moves the decision “what can the AI touch?” to the people who already govern org access.
What this means for you
If you’re an admin: this is closer to your world than you might expect. The levers are Setup pages, scopes, and tool selection — governance work, which is admin work. Start in a sandbox: activate a standard server, connect an MCP client, and watch it respect a restricted user’s permissions. That demo teaches more than any slide deck.
If you’re a developer: your @InvocableMethod skills just gained a new audience. The same well-described, well-scoped invocable actions you build for flows and Agentforce can become MCP tools. And everything I’ve written about action descriptions applies here verbatim — the client picks tools by reading their descriptions, so write them like you’re explaining to a careful colleague.
If you’re skeptical: good. Twenty years in classrooms taught me that healthy skepticism is just a request for evidence. The evidence to go check: calls run as the authenticated user, org security is enforced on every call, and there’s an audit trail. Verify those three in a sandbox and the skepticism does its job.
Where we go from here
This is the pivot point of “MCP, explained.” The first articles built the vocabulary — protocol, servers, clients, connectors. From now on, we build: next week we set up the External Client App, the OAuth bridge that makes all of this safe. Bring a sandbox.