Salesforce now hosts MCP servers that expose your org’s records, SOQL, Flows, Apex, Named Queries, Data 360, and Tableau as callable tools for any MCP client. No middleware, no connector code, no infrastructure. Authentication is per-user OAuth 2.0 with PKCE, and every call respects field-level security and sharing rules. The architecture question is no longer “how do we integrate with Salesforce.” It is “which of our capabilities do we expose, to whom, and how do we govern it.”
In This Article
Think about every Salesforce integration you have ever built. A middleware layer in the middle. MuleSoft, or a Heroku app, or a stack of Apex REST endpoints, all doing the same fundamental job: taking some external system and teaching it how to talk to your org. Your org sat at the end of the pipe. Things flowed toward it.
Summer ’26 inverts that. With Salesforce-hosted MCP servers now generally available, your org becomes a set of tools that an external AI agent calls directly. The agent does the reasoning. Your org provides the capability. No connector code sits in between.
Here is the part that changes how you think. An analyst opens Claude or ChatGPT, asks a question in plain language, and the model decides on its own that it needs to query your Salesforce data, runs a SOQL statement through the hosted MCP server, gets governed results back, and reasons over them. Nobody built a custom integration for that question. The capability was just there, exposed and waiting.
You used to integrate with Salesforce. Now external agents integrate by calling Salesforce. The org stops being a place data goes and starts being a service other systems consume.
MCP, the Model Context Protocol, is the open standard underneath this. It gives AI clients a consistent way to discover and call tools. Salesforce did not invent it. What Salesforce did was host the servers itself, so there is no infrastructure for you to stand up, patch, or scale. You turn the feature on, define what is exposed, and the org answers.
That sounds small. It is not. It removes the single most expensive and brittle layer in most integration projects: the custom glue.
Salesforce ships two kinds of hosted MCP server. Standard servers are pre-built and generally available. You enable them, and a defined set of org capabilities becomes callable. Custom servers let you define your own, exposing exactly the actions you choose. Most teams will start with standard and graduate to custom as they learn what their agents actually need.
The standard catalog covers the operations you would expect an agent to want, and a few you might not have considered.
Read, create, update, and delete records on any object. Every operation respects field-level security and sharing rules, so the agent sees exactly what the authenticated user can see.
Run SOQL queries and SOSL search directly. This is the tool that lets a model answer “how many open opportunities over 50k in EMEA” without a pre-built report.
Expose Apex Invocable Actions, @AuraEnabled methods, Apex REST, and Flows as MCP tools. Your existing business logic becomes agent-callable with no rewrite.
The Named Query API hit GA in Summer ’26. It lets you expose curated, parameterized SOQL as a scalable action, which is far safer than handing agents raw query access.
Query Data 360 and pull Tableau analytics through MCP. Agents can ground their answers in your unified data and your real metrics, not just CRM records.
Use Prompt Builder templates from your MCP client. The prompt engineering you already did inside Salesforce becomes reusable from any connected agent.
Notice what is happening with Invocable Actions and Flows. You spent years building business logic inside the platform. That logic does not get thrown away or reimplemented in some external orchestration layer. It gets exposed, as is, and an agent calls it like any other tool. The investment carries forward.
There is also a developer-facing layer worth knowing about. The Data 360 MCP Server arrived in developer preview, and rather than exposing roughly 200 REST operations one at a time, it fronts them with three facade tools: search to find a capability by intent, payload_examples to fetch a working request body, and execute to run it. That facade pattern is a smart bit of API design, and you will probably want to copy it when you build custom servers of your own.
The magic feels like nothing happens, which is the point. But as an architect you need to know exactly where the security boundaries sit. Here is the path a single call takes.
The critical detail is in step four. Authentication is per-user OAuth 2.0 with PKCE, not a single shared integration account. When the agent runs a query, it runs as the person who authenticated. If that person cannot see a field, the agent cannot see it either. Your field-level security and sharing model becomes the access policy for AI, with no extra configuration.
This matters because the lazy alternative, a fat integration user with broad access, is exactly how data leaks happen at machine speed. Per-user auth means your existing permission design is doing the work. If your sharing model is sound, your agent access is sound. If it is not, this is a very good reason to fix it.
Per-user OAuth with PKCE is the single most important design decision in this feature. It means you do not need a separate “AI permission model.” You need your existing FLS and sharing to be correct, because that is precisely what now governs every agent call.
A Concrete Example
Say you expose a Named Query that returns open pipeline by region, parameterized on region and minimum deal size. An analyst in Claude asks about EMEA deals over 50k. The model finds the Named Query tool, supplies the two parameters, and the org executes it under the analyst’s permissions. The analyst gets numbers they were already allowed to see, surfaced through a model they were already using. You wrote one Named Query. You did not write an integration.
The temptation with a feature this powerful is to enable everything and see what sticks. Resist it. The orgs that adopt hosted MCP well treat it as an access-design exercise first and a capability rollout second.
Hosted MCP is a strong feature, and it still has sharp edges. Here is what to watch.
- An over-permissive profile that nobody noticed becomes an agent that can read more than it should
- Field-level security you assumed was tight gets tested by a model that asks for everything
- Broad “View All” permissions are now AI access grants, not just human convenience
- Fix: Treat the FLS and sharing audit as a security review, not a checkbox
- A model that retries a failed query can generate call volume a human never would
- Raw SOQL access invites expensive, unselective queries that strain the org
- API consumption adds up when multiple users connect multiple clients
- Fix: Named Queries and tight scopes cap the damage a runaway agent can do
The API Version 67.0 Gotcha
Summer ’26 ships on API v67.0, and it removes the WITH SECURITY_ENFORCED SOQL clause. You replace it with WITH USER_MODE, which supports polymorphic fields and returns the full set of access errors. Apex triggers now always run in system mode, and sharing declarations on triggers are no longer permitted. If you have custom code in the path of your exposed tools, validate it against v67.0 before you rely on it for agent traffic.
There is a second timing detail. Multi-agent orchestration and several Summer ’26 features rolled out in waves from June 13 to 15. If you are reading release notes, confirm your org’s exact wave date rather than assuming everything is live the moment the announcement drops.
The hardest part of hosted MCP is not technical. It is organizational. Once analysts realize they can query the org from Claude, demand explodes, and your governance has to be ready before that wave hits. Set up Named Queries, scope your client apps, and define ownership now, while adoption is still small and you can shape it.
Hosted MCP servers are one piece of a larger Salesforce theme called Headless 360, the idea that every major platform capability should be available as an API, an MCP tool, or a CLI command. The org you administer is becoming a set of services that humans, apps, and autonomous agents all consume through the same governed surface.
You can see where the roadmap points. Marketing Cloud is adding its own MCP server. MuleSoft shipped an API Catalog to centralize API and MCP server management across MuleSoft, Heroku, and Apex sources. The Data 360 MCP Server is in preview. The pattern is consistent: more of the platform, exposed as callable tools, governed by the same trust layer.
SObject operations, SOQL, Search, Invocable Actions, Flows, Named Queries, Data 360, Tableau, and Prompt Templates are callable now through Salesforce-hosted servers.
As teams learn what agents actually need, custom hosted servers with facade-style tool design become the norm for production AI workflows.
Every capability available as API, MCP tool, or CLI. The org becomes a service consumed by humans, apps, and agents through one governed surface.
For architects, the strategic question shifts. It is no longer “how do we connect system A to Salesforce.” It becomes “which capabilities do we expose, to which clients, under whose identity, and how do we observe it.” That is a governance and access-design problem, which is exactly the kind of problem architects are supposed to own.
So here is the question worth sitting with. If you turned on hosted MCP tomorrow and let your team’s agents call your org under their current permissions, would you trust what they could reach? If the answer is yes, you are ready. If it is no, you just found your next project.