MCP is a wire protocol that lets an AI client call tools on a server, the way a browser calls an HTTP API. Salesforce now hosts MCP servers, which means an outside agent can reach your org over a standard interface instead of a bespoke integration. For an architect the important part is not the protocol — it is that the server runs each call as the authenticated user, so MCP is a new door into the access model you already built, not a new access model.
The protocol, in the only detail you need
The Model Context Protocol standardises three things a model-facing client needs from a server: tools it can call, resources it can read, and prompts it can reuse. The transport is JSON-RPC, over a local pipe or over HTTP, and the HTTP form uses OAuth 2.0 for authorisation.
That is the whole idea. It is deliberately unremarkable, and being unremarkable is the point: before it, every AI tool integration was bespoke, and the integration cost was paid once per pairing of client and system.
The Salesforce-relevant consequence: your org stops needing a custom connector per AI product. One server, many clients.
Salesforce’s servers, and the surface they expose
Salesforce hosts its own MCP servers rather than expecting you to run one. The Headless 360 server has been in beta since July 2026, and its design decision is worth studying even if you never use it.
It exposes four tools, not thousands:
- Discover — a semantic search across a vector index of available operations, taking the agent’s interpretation of the request.
- Describe — returns the technical contract for a chosen operation: APIs, parameters, dependencies, ordered steps.
- Dispatch — invokes the operation and routes it to the right endpoint.
- Dispatch Read Only — the same, restricted to reads.
The alternative design would have been one tool per Salesforce operation, which would put thousands of tool definitions in front of the model. Four tools over a growing library keeps the agent’s tool surface small and stable while the set of possible actions grows independently.
The architectural consequence people miss: you cannot judge what an agent can do by counting its tools. Four tools is not a small blast radius. The blast radius is whatever the library behind Dispatch can reach, filtered by the running user’s permissions.
Authentication is the part that should reassure you
Every hosted MCP transaction runs as the authenticated user, scoped through an External Client App holding the mcp_api scope. Salesforce states plainly that object permissions, field-level security, sharing rules, profile permissions and permission sets all apply: if you cannot perform an action in Salesforce, your agent cannot perform it through MCP.
Read that as an architect rather than as reassurance. It means the protocol adds no new authorisation layer, which is good, because a second authorisation model is a second thing to get wrong. It also means your existing model is now doing work it was never stress-tested for. Every over-broad permission set becomes an agent capability.
Access can be narrowed with an app policy, pre-authorising only users holding named profiles or permission sets. That is the control worth insisting on before anyone connects anything.
Where this fits against the integration patterns you already use
MCP is not a replacement for REST, Bulk or Platform Events, and reading it as one leads to bad designs. Compare by who initiates and why:
- REST and SOAP — a program decides what to call, at a time it chooses, with a contract fixed at build time.
- Bulk — volume, asynchronous, nobody watching.
- Platform Events and CDC — Salesforce tells the outside world something changed.
- MCP — a model decides what to call, at a time a person’s question dictates, choosing from a library it discovers at runtime.
That last one is genuinely new, and it is the source of both the value and the discomfort. The call pattern is not knowable in advance, which breaks the assumption behind most integration monitoring: you cannot alert on “unexpected endpoint” when discovery is the design.
We wrote about choosing among the classical patterns in pick the integration pattern before you pick the tool. MCP is a fifth option on that list, and it belongs there only when the caller is a model.
What I would put in an architecture review
- Identity: which user does each connection run as, and can you attribute an action to a person? For hosted MCP the answer is documented. For anything self-hosted, it is your design and your problem.
- Scope: which External Client App, holding which scopes, restricted by which app policy.
- Blast radius: not the tool count. The permissions of the eligible users, on the objects the library can reach.
- Observability: is a Dispatch recorded anywhere you can query, and would a spike be noticed?
- Failure mode: what happens when the server is unavailable — a person asks again, which is a nicer answer than most integrations get.
The honest summary
MCP is a good protocol and a small idea. It will not change your data model, your sharing rules or your integration strategy. What it changes is who can initiate a call (from programs you deployed to models acting for people), and the readiness work that implies is an access review, not an integration project.
Frequently asked
Do we have to run a server ourselves? Not for Salesforce data — the servers are hosted. Self-hosting matters when you want to expose your own systems to an agent, which is a separate decision with separate security work.
Is MCP Salesforce-specific? No, it is an open protocol with implementations across many systems. That is the reason Salesforce adopting it matters more than another proprietary connector would.
Does MCP bypass the Einstein Trust Layer? Different layer of the stack. Trust Layer governs model interactions inside Salesforce’s own AI products. MCP governs how an outside client reaches your data. Do not assume one covers the other.
Can we block it entirely? Yes: connected app and external client app policies control who may authorise anything, and that stays true regardless of protocol.
