Every integration I’ve built on Salesforce over the last decade has followed the same shape: something outside the platform calls in, or Salesforce calls out, through an endpoint one of us designed and documented ahead of time. Hosted MCP servers break that assumption. They let an AI agent discover what a Salesforce org can do at runtime, without a developer having written a bespoke contract for that exact conversation.
That’s a bigger shift than the release notes make it sound. Worth working through carefully, because I think most Salesforce teams are going to meet this feature through an Agentforce demo rather than through an architecture review, and that’s the wrong entry point.
What MCP actually is
Model Context Protocol is an open standard for letting an AI model discover and call “tools”, actions with a name, a description, and a defined input schema, without the model’s creator having to hard-code anything about your system. A hosted MCP server is Salesforce exposing a set of its own capabilities (objects, Flows, Apex actions) as that same kind of tool, running on Salesforce’s infrastructure rather than something you stand up yourself.
Before this, if you wanted an AI assistant to touch Salesforce data, you built a custom action, wired it into Agentforce’s topic and action model, and that action worked inside Agentforce and nowhere else. A hosted MCP server is protocol-level instead. Any MCP-compatible client, Claude, a custom agent, another vendor’s assistant, can connect to it and get the same tool definitions. You describe the capability once. Where it gets consumed is no longer your problem to solve per client.
What’s actually exposed
In practice, a hosted MCP server surfaces three kinds of things: standard and custom object operations (query, create, update, following the same field-level security and sharing rules the calling user already has), invocable Apex actions you’ve built and marked for exposure, and Flows set up to run as autonomous or template actions. None of that is new capability. It’s existing automation and data access, described in a format an AI client can read and reason about without you writing a new client library for every consumer.
How this differs from what you’ve already built
If you’ve worked with External Services, this will feel familiar at the surface and different underneath. External Services imports an OpenAPI spec so Flow and Apex can call an external system through a predictable, versioned contract. A hosted MCP server runs the comparison the other way: Salesforce is the thing being described, and the consumer is an AI model deciding, at runtime, which tool to call and with what arguments, based on a natural-language request it’s trying to satisfy.
That runtime decision-making is the part integration architects need to sit with. A REST callout fails loudly and predictably when the contract changes. An MCP tool call can “succeed” technically while the model has picked the wrong tool, or the right tool with slightly wrong arguments, because it inferred intent from a prompt rather than executing a line of code you wrote. The failure mode moves from the network layer to the reasoning layer, and most of our existing monitoring doesn’t look there yet.
Authentication doesn’t get simpler
It’s tempting to assume MCP abstracts away auth the way it abstracts away the API shape. It doesn’t. Every call still runs as a specific authenticated user or connected app, with whatever permission set, sharing rules, and field-level security that identity carries. The protocol changes how the tool is discovered and invoked. It changes nothing about who’s allowed to see what. If anything, this is where I’d spend the most review time: a hosted MCP server that’s scoped too broadly hands an AI client the same blast radius a careless integration user would have, except now a model is deciding which actions to fire, not a developer who read the spec first.
Where this fits in your integration patterns
I’d place hosted MCP servers as a third pattern alongside request-reply and fire-and-forget, not a replacement for either. A contact-centre team I worked with recently had this exact conversation: should a new case-triage action be a Flow-triggered automation, an Apex REST endpoint for an external system, or an MCP tool for an AI agent to call directly? The answer came down to who initiates the call. If a known system triggers it on a schedule or an event, build the automation or the REST endpoint, because you want a fixed, testable contract. If the point of the feature is that a conversational agent decides when and whether to act, based on context it’s reasoning about in the moment, that’s the MCP shape, and forcing it into a traditional integration just reintroduces the rigidity you were trying to get away from.
Testing looks different too
Standard integration testing checks that a known input produces a known output. MCP tool testing has to check that an AI client, given a realistic range of phrasing, picks the right tool at all, and picks it with sane arguments. That’s closer to the evaluation work you’d do on a chatbot than to Apex test coverage. If your org’s current release process doesn’t have anyone doing that kind of testing, hosted MCP servers are the forcing function that makes it necessary, not optional.
What I’d actually do before turning one on
Scope the connected app or permission set behind the MCP server as narrowly as the use case allows, not as broadly as “it might be useful later”. Write tool descriptions as carefully as you’d write a public API’s documentation, because the model’s tool-selection accuracy depends entirely on how clearly you’ve described what each action does and when it should be used. And put someone on the hook for reviewing what the agent actually called in production, not just whether the calls succeeded. A hosted MCP server that silently lets an agent update the wrong records, with valid permissions and no error thrown, is a worse outcome than an integration that fails and pages someone.
None of this makes hosted MCP servers something to avoid. It makes them something to design the same way you’d design any integration that can change data: start from what should be allowed, not from what’s technically possible, and build the boring guardrails first.