Salesforce’s Agentforce MCP support changes how agents discover resources, tools, and prompts. For enterprise deployments, the material shift is governance: a registered server can expand an agent’s capability surface beyond a fixed set of locally defined Actions.
The Model Context Protocol is an open standard for connecting AI agents to tools and data sources. Salesforce says its MCP support lets agents obtain resources, tools, and prompts from internal and external sources through a defined handshake. Treat those capabilities alongside existing configured Actions when designing the boundary, while verifying registration and runtime behaviour in the target release.
What MCP Actually Changes in the Agent Architecture
Before MCP, teams commonly extended an Agentforce agent with a Flow action, an External Services callout, or an Apex invocable. Those paths expose a fixed action that the Salesforce configuration references explicitly. MCP adds discovery through a server manifest, so the review unit becomes the server and its advertised capabilities, not only one action.
An MCP server advertises capabilities through the protocol. Once a server is registered and made available to an agent, the usable capability surface can be broader than one hand-wrapped action. Confirm how the target release discovers, caches, refreshes, and scopes that server before describing the set as dynamic at every reasoning turn.
In practice, one server can expose several capabilities, and its advertised set can change when the provider changes the server. Governance therefore needs a reviewed server version or snapshot, negative tests for unavailable capabilities, and a defined response to manifest drift.
The architectural question enterprise teams need to answer immediately: who controls what MCP servers are registered, and under what conditions can the reasoning engine invoke them? Without a clear answer, you’ve handed the Atlas Reasoning Engine a capability surface you don’t fully control.
AgentExchange and the Partner MCP Ecosystem
AgentExchange is one distribution path for partner-built agent capabilities, including MCP integrations. Availability, installation model, and hosting boundary must be checked for the specific listing.
Do not assume an AppExchange-style installation boundary. An MCP endpoint may be hosted by the enterprise, Salesforce, or a partner. Trace the actual endpoint, authentication path, request fields, response fields, logs, retention, subprocessors, and regions. Only then can the team state whether data leaves a particular trust boundary.
If the server processes regulated or personal data, registration becomes a security, privacy, and contracting decision as well as a technical one. A DPA may be required when the provider acts as a processor; an internally hosted server may require a different control path.
A useful operating pattern is a tiered registry: internally hosted servers, approved managed servers, and blocked categories. For each entry, record owner, endpoint, authentication, allowed data classes, approved agents or actions, evidence expiry, and revocation procedure. Use the access controls supported by the target Agentforce and gateway configuration, then prove least privilege with negative tests; do not assume a per-Topic MCP allowlist exists without verifying it in the org.
Hosted LLM Flexibility and What It Actually Unlocks
The Agentforce 3 announcement also describes expanded hosted-model choice. This matters architecturally because different reasoning tasks can have different quality, cost, and latency profiles.
If the target org supports more than one hosted model, route only after testing task quality, latency, cost, and safety on each candidate. A smaller model can suit bounded classification while a larger one can suit multi-step reasoning, but that is a test hypothesis rather than a product guarantee.
Prompt behaviour can differ across model families even with identical inputs. Before committing to multi-model routing, run the critical Prompt Builder templates, tool-selection cases, refusals, and fallback paths across every candidate model under the same evaluation set.
(The Prompt Builder template controls article maps the template-type dependency model; Flex, Field Generation, and Sales Email templates have different sensitivities to model substitution.)
Keep Native Retrieval Inside the Same Performance Test
An MCP-enabled turn can combine external tool calls with native Salesforce retrieval. If the use case uses Data 360, measure that retrieval inside the same turn rather than treating MCP latency in isolation.
Data Graphs materialize joins across Data Model Objects. They can reduce the amount of retrieval work needed when an agent requires customer context, but Salesforce’s MCP material does not publish a general latency benchmark for Data Graph or DMO queries. Performance depends on the graph, query path, data volume, cache state, concurrency, region, and surrounding Actions.
Set an end-to-end acceptance criterion for each agent turn. Capture native retrieval time, server discovery, authentication, each MCP call, retries, model reasoning, and response generation. Test under representative concurrency and failure conditions. Publish a number only when its environment and method are recorded.
Before expanding MCP-sourced capabilities, identify every native and external dependency in the tested path. If a Data Graph is used, compare it with direct retrieval and record freshness as well as speed. If Data 360 is not part of the use case, do not add it merely to fit this pattern.
For teams still evaluating whether Data Cloud investment is justified for their Agentforce use cases, the Data Cloud implementation guide lays out the dependency chain between Identity Resolution, Calculated Insights, and agent grounding.
Governance Architecture for MCP-Enabled Agents
The governance model for Agentforce deployments without MCP was already non-trivial. With MCP, it requires explicit design.
Three layers need to be addressed before you register a single external MCP server in production.
Tool manifest auditing: MCP servers self-describe their capabilities. That manifest needs to be reviewed before registration, not after. Build a review gate into your AgentExchange onboarding process that requires security and legal sign-off on the tool manifest, the data the server requests in its context payload, and the server’s data retention policy.
Invocation evidence: Define the evidence required for each external invocation: agent and configuration version, selected server and capability, authorization result, payload classification, outcome, latency, retry, and fallback. Use the tracing and logging available in the target release, while applying minimization, access, and retention rules to the logs themselves.
Scope containment: Topics describe intent boundaries, but the enforceable MCP boundary depends on the controls exposed by the agent, gateway, server, identity, and underlying data source. Define the allowed capability set for each use case, configure it at the supported enforcement points, and test that an unrelated request cannot reach a prohibited server or dataset.
Orgs that skip this governance layer and deploy MCP-enabled agents at scale will encounter the same class of problem that plagued early RPA deployments: capable automation operating outside any meaningful control boundary. The Salesforce governance framework for enterprise covers the broader control model, and the MCP layer slots directly into the same framework.
For teams building out the full Agentforce architecture, the Agentforce architecture guide covers how to structure the Topics, Actions, and MCP registry design for enterprise-grade deployments.
Key Takeaways
- Agentforce 3 MCP support lets a registered server advertise multiple capabilities; govern server approval, capability drift, scope, and revocation together.
- A partner MCP server may change the processor, hosting, or data path. Establish those facts before selecting the legal and security gate.
- Multi-model LLM routing requires a Prompt Builder regression suite across all target models before production deployment; template behavior is not model-agnostic.
- Data Graph coverage can reduce native retrieval work, but its value must be proven with an end-to-end load test rather than an unsourced latency threshold.
- Contain MCP scope at the enforcement points the target release actually supports, then prove denied paths with negative tests.
