Salesforce MCP in Summer '26: Agentforce Connects Both Ways
Part 1 of 2 in the Salesforce MCP in Summer ‘26 pair: architecture and adoption. Continue to Part 2: setup and release.
Agents become truly useful when they can leave the conversation and do real work. That is also where implementations become difficult. Every new external capability can bring another authentication flow, integration contract, agent action, permission decision, monitoring requirement, and failure mode.
Model Context Protocol (MCP) is an open standard that gives AI applications a consistent way to discover and invoke tools exposed by other systems. In Summer ‘26, Salesforce made two important moves around that standard: Agentforce gained a native MCP client for consuming external tools, and Salesforce Hosted MCP Servers became a generally available way for external MCP clients to consume selected Salesforce capabilities.
That second pattern is easy to miss. Salesforce is not only connecting Agentforce to other systems. It can now act as the governed capability provider for clients such as Claude, ChatGPT, Cursor, and custom agent applications. Together, these changes move Salesforce from isolated agent actions towards two complementary, reusable agent integration patterns.
This article explains what Salesforce shipped, how MCP works in practical Salesforce terms, and how the two connection directions differ. It also examines when a simpler integration is the better answer, where MCP creates real value, and which security and platform boundaries still matter. If MCP fits, the companion Salesforce MCP setup guide provides the implementation walkthroughs. The discussion builds on the integration choices covered in the Salesforce integrations guide and the broader agent model introduced in AI and the Salesforce developer journey.
⚡ TL;DR
Section titled “⚡ TL;DR”- Salesforce now supports MCP in both directions. Agentforce can consume external MCP tools, while compatible external clients can consume selected Salesforce capabilities through Hosted MCP Servers.
- Choose the direction before the setup. The two patterns use different identities, onboarding paths, permissions, and governance controls. They are not opposite ends of one connection.
- Use MCP only when it adds something. It suits reusable, discoverable capabilities for compatible AI clients. Keep the existing integration when the consumer and execution path are fixed.
- Start with a bounded release. Pilot one low-risk, read-oriented capability. Limit its tools and data. Check the identity and processing locations, then test selection, monitoring and recovery before expanding.
📰 What Salesforce Actually Shipped
Section titled “📰 What Salesforce Actually Shipped”The MCP story is a collection of connected capabilities rather than one checkbox. Seeing the sequence matters because it separates generally available foundations from newer features that arrived later in the release window.
The dates below are historical release markers from the documentation available on 26 July 2026, not a guarantee that every org received each feature on that day. Salesforce releases Agentforce capabilities on a rolling basis, so check whether the feature is available in the target org.
| Capability | Documented rollout, as of 26 July 2026 | What it changes |
|---|---|---|
| Native MCP client in Agentforce | Rolling from mid-May 2026; full availability was planned by the end of May | Agentforce can consume allowlisted tools from third-party, MuleSoft, and Salesforce-hosted MCP servers. |
| Agentforce Gateway policies | Rolled out alongside the client in May 2026 | Admins can restrict tool access and apply quotas instead of treating server registration as blanket approval. |
| Salesforce Hosted MCP Servers | Generally available in the Summer ‘26 API release | External MCP clients can use selected Salesforce data, APIs, automation, prompts, and agent capabilities. |
| MuleSoft MCP servers in API Catalog | Generally available from May 2026 | MCP servers published through Anypoint Platform can be discovered and connected from Salesforce. |
| Agentforce agents as MCP tools | Generally available in June 2026 | A custom Salesforce Hosted MCP Server can expose an Agentforce agent to an external MCP client. |
| Prompt Builder through Hosted MCP | Available with Salesforce Hosted MCP Servers | Compatible clients can receive published Flex templates as MCP prompts. Custom servers can also expose prompt templates as callable tools for server-side execution. |
| Tool behaviour annotations | Generally available in June 2026 | Custom tools can advertise read-only, destructive, idempotent, and open-world behaviour. |
| Third-party MCP risk scores | Rolling from mid-July 2026 | Agentforce Registry scores servers and individual tools for potential tool-poisoning instructions. |
💳 Check edition and entitlements first
Section titled “💳 Check edition and entitlements first”Availability has several layers. Validate the platform edition, the Agentforce entitlement, and every product behind the tools before designing around MCP.
| Capability | Documented baseline | Additional checks |
|---|---|---|
| MCP for Agentforce | Enterprise, Performance, Unlimited, and Developer Editions; the Summer ‘26 release note also identifies Foundations or Agentforce 1 Editions | Required add-on licences vary by agent type, and agent actions carry their normal usage charges. |
| Salesforce Hosted MCP Servers | Developer, Enterprise, Performance, and Unlimited Editions | API access, user permissions, and the entitlement for every published Salesforce capability still apply. |
| Product-backed tools | Depends on the selected server or tool | Check MuleSoft, Data 360, Tableau Next, Agentforce, Prompt Builder, API limit, and credit requirements separately. |
🧩 MCP in Plain English
Section titled “🧩 MCP in Plain English”Traditional integrations assume that the calling application already knows the target system’s endpoints, operations, and payloads. An AI application also needs a reliable way to discover which capabilities are available now, understand what they do, and supply valid inputs. Model Context Protocol (MCP) standardises that AI-facing contract: connect to a server, discover what it offers, send a structured request, and receive a structured result.
The MCP project compares this to a USB-C connection for AI applications. The value is not that every connected system does the same thing. It is that one compatible connection pattern can lead to many kinds of capability: context from files or databases, executable tools that read or change another system, and reusable prompt-driven workflows.
For example, suppose Agentforce needs to check stock in a warehouse platform. Without MCP, your team must give the agent a provider-specific action that already knows the warehouse API contract. With MCP, the warehouse provider can publish a check_stock tool with a description and input schema. The Agentforce client can discover that definition, the host can make it available to the reasoning engine, and an approved call can pass the product and location as structured arguments. Another compatible AI application could reuse the same server contract without the warehouse provider designing a separate discovery and invocation format for that application.
The USB-C analogy has limits. MCP does not make the warehouse API or integration logic disappear. Nor does compatibility imply trust. The server still has to implement the capability. The host and connected system still own authentication, authorisation and user consent. They also own policy enforcement, validation, monitoring and failure handling.
MCP is the integration layer, not the intelligence or security model. It does not choose the language model or decide how an agent should reason. It also does not grant access to Salesforce or replace OAuth and platform permissions.
Those responsibilities are divided among three participants:
| Participant | Plain-English job | Connection rule | Salesforce example |
|---|---|---|---|
| MCP host | The user-facing AI application. It coordinates the model, conversation context, user consent, and its MCP clients. | One host can manage several clients and combine capabilities from several servers. | Agentforce when it consumes MCP capabilities, or an external AI application when Salesforce provides them. |
| MCP client | The protocol component inside the host. It discovers capabilities and exchanges versioned MCP messages. | Each client is configured for one server, although current MCP requests do not depend on a shared protocol session. | The native MCP client inside Agentforce, or the client embedded in an external AI application. |
| MCP server | The capability provider. It describes what it offers, handles permitted requests, and returns results. | A server can be local or remote and can publish capabilities to connected clients. | A third-party or MuleSoft MCP server, or a Salesforce Hosted MCP Server. |
An MCP server can expose three core primitives:
- Tools are executable operations, such as checking warehouse stock, retrieving an account summary, or updating a Case. The AI application can offer them to the model for selection.
- Resources are contextual data, such as files, records, or schema information, that the application can retrieve and use.
- Prompts are reusable, parameterised templates that a compatible application can present for a user to select.
For a tool call, the lifecycle is straightforward. The client and server need a compatible protocol revision and feature set. The host then uses the client to discover the server’s tools and can make their names, descriptions, and input schemas available to the model. If the application approves a selected tool, the client sends the structured call to the correct server. The server executes it under the configured identity and permissions, returns a result, and the host decides what enters the conversation context.
The official MCP architecture guide goes deeper into capability negotiation, tools/list, tools/call, transport, and notifications.
🔄 Two Separate Salesforce MCP Patterns
Section titled “🔄 Two Separate Salesforce MCP Patterns”The most important Summer ‘26 idea is that Salesforce can sit on either side of an MCP connection. “Both directions” does not mean that one connection works as a duplex Salesforce integration. These are two independent deployment patterns that share MCP messages but have different onboarding, identity, and policy surfaces.
These two terms appear throughout this article, so it helps to define them once. The control plane is the setup and administration layer: the one-time work of registering, activating, curating, and governing what a connection is allowed to do. The runtime plane is the live request traffic: the actual discovery and invocation calls that flow while an agent or client is working.
The diagram shows where setup ends and live traffic begins: the upper rail represents the control plane, while the double arrows represent runtime traffic. This distinction matters because Registry and External Client Apps configure and govern a connection; they do not proxy every MCP request. With that boundary established, start with the first two rows below to choose the direction, then compare identity, onboarding, governance, and runtime behaviour.
| Design aspect | Pattern 1: Agentforce consumes | Pattern 2: Salesforce provides |
|---|---|---|
| Request direction | Agentforce calls out to an MCP server and uses an approved tool. | An external AI application calls into Salesforce through a hosted MCP server. |
| Best fit | Give an Agentforce agent a capability that is not already available as a suitable native action. | Let people work with governed Salesforce capabilities from an MCP-compatible AI application. |
| Where the user works | In Agentforce, which acts as the host. Its native MCP client manages the server connection. | In an external host such as Claude, ChatGPT, Cursor, or a custom application. Its embedded MCP client manages the connection; Postman can act as a protocol test client. |
| Capability provider | A third-party or MuleSoft MCP server exposes tools to Agentforce. | A Salesforce Hosted MCP Server exposes selected Salesforce capabilities to external clients. |
| Capabilities available to the host | Allowlisted server tools become Agentforce actions. Server prompts and resources are not currently supported. | Tools and supported Flex templates published as MCP prompts. Prompt availability also depends on the external client. |
| Onboarding path | Register a manual external server in API Catalog or Agentforce Registry. Use Registry for advanced OAuth 2.1 configuration; manage MuleSoft servers through API Catalog. | Activate a standard server or create a custom server in API Catalog. Register the external client with an External Client App, then configure the client with the server URL and consumer key. |
| Connection authentication | No authentication or OAuth 2.0 client credentials, with some advanced OAuth 2.1 client-credentials configurations available through Registry. User-level external authentication is not supported. | Per-user OAuth 2.0 authorisation code flow with Proof Key for Code Exchange (PKCE), normally registered through an External Client App. |
| Identity used at runtime | No verified external identity for an unauthenticated connection, or a shared application or machine identity with client credentials. The conversational user’s identity is not delegated. | The named Salesforce user who authorised the client. Their Salesforce permissions and sharing access apply to each call. |
| Live request path | Agentforce’s MCP client calls the server directly. Registry and API Catalog are not runtime proxies. | The external client’s MCP client calls the Salesforce hosted endpoint directly with the user’s token. The External Client App is not a runtime proxy. |
| Primary governance controls | Server registration, tool allowlisting, generated action assignment, agent instructions, and applied Gateway policies. | Server activation or curation, External Client App policies, the user’s Salesforce access, and audit logs. |
This asymmetry changes which use cases are safe. An Agentforce agent can use a client-credentials connection to retrieve an organisation-wide invoice list, for example, but it cannot currently use MCP to make a personalised external request as the individual person in the conversation. A no-authentication connection provides even less identity assurance and should expose only capabilities that are safe without caller authentication. In the reverse direction, a hosted server call runs with the authenticated Salesforce user’s object permissions, field-level security, sharing access, and audit identity.
That distinction needs to be designed before you register a server, not discovered during user acceptance testing.
Both patterns share a prior question: is MCP the right contract at all? If a stable Agentforce action, External Service or existing integration already delivers the outcome for a known consumer, changing protocol adds work without necessarily improving the design. You still have to onboard it, govern it, test it and monitor it.
MCP earns its place when compatible AI clients need the same discoverable capability, or when Agentforce needs to consume provider-managed tools. Its registration and curation model can also be a reason if it provides a governance boundary you do not already have. The decision table later in this article compares MCP with API actions, MuleSoft and A2A against those criteria.
Both walkthroughs live in a separate guide so this article can stay with the decision rather than the screens. That guide covers prerequisites, registering a third-party server in Agentforce Registry, activating a Hosted MCP Server and connecting Postman to it, Gateway policies, and the release checklist.
📞 One Service Scenario, Two Separate Connections
Section titled “📞 One Service Scenario, Two Separate Connections”A short service journey makes the architecture more concrete. The same customer issue can touch both Salesforce MCP patterns without turning them into one connection.
-
A customer asks Agentforce for an order update. The service agent needs fulfilment data held in an external order platform before it can answer.
-
The external capability has already been approved in the control plane. An administrator registered the order provider’s MCP server in Agentforce Registry, configured the connection to use OAuth client credentials, reviewed the available security information, and allowlisted only
check_order_status. They then applied an MCP attribute-based access control policy for that read tool, added a separate quota-management policy, and added the generated action to the agent. -
Agentforce makes the outbound call. The agent collects and validates the order number, selects the generated action, and calls the external MCP server using the shared application identity established by the client-credentials connection. Agentforce preview confirms the action selection and returned result, while trace data shows whether the in-sync action was available to the agent. The provider’s service logs complete the picture for slow or failed downstream calls.
-
A representative later uses an external assistant to review the escalated Case. That assistant opens a separate connection to a focused Salesforce Hosted MCP Server. The representative authorises it through an External Client App using OAuth with PKCE, so Salesforce evaluates the hosted Case tools using that named user’s permissions and sharing access.
-
Each direction keeps its own evidence trail. Agentforce preview and trace data, together with the downstream provider’s logs, support the outbound order-status path. Event Monitoring’s API Total Usage data supports the inbound hosted-server path, where
API_CLIENT_CATEGORY = SALESFORCE_HOSTED_MCPidentifies Hosted MCP traffic. Together they reconstruct the business journey without pretending that one log source covers both systems.
🚀 What MCP Changes in Integration Architecture
Section titled “🚀 What MCP Changes in Integration Architecture”The architectural shift is from predefined calls to discoverable capabilities. Traditional integrations connect known systems through a fixed sequence: this consumer calls this endpoint with this payload. MCP provides a consistent contract for describing and invoking the available capabilities, while the agent’s reasoning layer decides which one to use at runtime. In Salesforce, that means you can expose a curated set of Salesforce tools to external AI clients and bring approved external tools into Agentforce as agent actions.
Four shifts stand out.
-
The interface moves from endpoint to capability. A useful tool describes a business operation and its inputs, not merely an HTTP path. The underlying implementation can still be an API, Flow, Apex action, or MuleSoft process.
-
The connection becomes reusable. A server can publish a curated set of tools to more than one compatible client, and Agentforce can import reviewed and allowlisted external tools without a bespoke action implementation for every provider.
-
Salesforce becomes both consumer and provider. Agentforce can reach outward, while employees can work with Salesforce from assistants where they already spend time. CRM becomes a governed capability as well as a destination UI.
-
Governance moves closer to discovery. Registration and security scanning shape how the tool becomes available. So do allowlisting, policy enforcement and per-user authorisation. Tracing belongs there too, rather than being postponed until after the agent is built.
The word standard should not be mistaken for automatic. MCP does not decide which system owns business logic, transform an unreliable payload, guarantee idempotency, create a support model, or recover a failed multi-system transaction. Those responsibilities remain.
🧰 Reuse Salesforce capabilities through MCP
Section titled “🧰 Reuse Salesforce capabilities through MCP”Custom Salesforce Hosted MCP Servers can combine selected standard tools with Flows and Apex. They can also expose APIs, prompts and agents your organisation already owns. The important decision is not merely what Salesforce can expose.
Start with the smallest self-contained business capability. Choose the backing implementation according to who owns it and how deterministic it must be. Then ask what could happen if an external AI client selects or invokes it unexpectedly.
Publishing a capability through MCP does not make it MCP-only. The same Flow, Apex action, Named Query or API can continue to support Lightning and internal automation. Conventional integrations can keep using it too.
Keep the reusable business logic in the underlying asset. Give the MCP surface its own task-specific contract, including its name, schema, description, annotations and controls. That avoids building a second implementation for external agents without forcing internal callers to inherit an agent-shaped contract.
| Starting point | Choose it when | Design check |
|---|---|---|
| Scoped SObject tools | The client needs general record discovery, queries, or controlled mutations and the standard tool contract fits. | Prefer the narrowest operation set. The user’s permissions still apply, and write or delete operations need deliberate confirmation. |
| Named Query API | Several clients need the same bounded, parameterised read contract. | Constrain the parameters and result size rather than recreating free-form SOQL. See the Named Query API article. |
| Autolaunched Flow | Admins own a deterministic, multi-step process with branching, lookups, or record updates. | Only autolaunched flows with defined inputs and outputs are eligible. User permissions, governor limits, and the lack of progress reporting still matter. |
| Apex invocable action | The operation needs complex calculation, validation, integration handling, or precise transaction control. | Keep the code bulk-safe, tested, securely enforced, and explicit about errors and side effects. |
Apex REST or @AuraEnabled method | An existing platform capability already matches one complete, agent-usable outcome. | Do not expose it only because it exists. Review its inputs, outputs, permissions, side effects, and error contract for agent use. |
| API Catalog endpoint | One registered REST or product-specific Connect API operation provides the required capability. | One tool maps to one endpoint. Put branching or multi-call orchestration in Flow, Apex, or MuleSoft. |
| Prompt Builder Flex template | Users need a selectable, governed MCP prompt, or an external agent needs Salesforce to execute a template server-side as a tool. | These are different interaction patterns. MCP prompt support varies by client, and template execution can consume product credits. |
| Agentforce agent | An external assistant should delegate one specialised reasoning task that Salesforce already owns. | Only agents created in the new Agentforce Builder can be exposed. Publish task-specific tools rather than one vague tool for the whole agent. |
| Product-specific standard tools | A maintained Salesforce server already provides the required product capability. | Recheck the Standard MCP Servers Reference, product entitlement, permissions, limits, and consumption before committing to the design. |
Whichever starting point you choose, each published MCP capability still needs a task-specific name and description, the smallest practical input schema, bounded output, accurate behavioural annotations, and tests with representative users. Salesforce’s custom-server guide is the live source for supported backing types and current configuration constraints.
🔗 Reuse approved server tools across agents
Section titled “🔗 Reuse approved server tools across agents”On the Agentforce side, you do not need to rebuild the same server connection for every agent. Register or activate the server once in the org, approve only the tools you intend to use, and Salesforce makes those tools available as MCP tool actions in the Agentforce asset library. The onboarding route depends on the source: manually registered third-party servers can use Agentforce Registry or API Catalog, MuleSoft servers sync into API Catalog before you connect them, and Salesforce-hosted servers are activated there.
You then add the relevant action from the asset library to each draft agent or subagent that needs it. An asset-library action can be added to multiple agents, but each agent receives its own copy. This is useful separation: a service agent and a returns agent can both use check_order_status, while keeping different reasoning instructions and tests. Adding the action to one agent does not make it available to every agent automatically.
The shared boundary still matters. Agents that use the same registration also use the same connection. With client credentials, they share the external application identity as well. Agent-specific Gateway policies can restrict tools or set quotas, but they do not turn that shared credential into a delegated identity for the person in the conversation.
Use separate connections when teams need different provider credentials or data scopes. A different quota or audit boundary can be enough reason to separate them too; reuse is not the goal by itself.
The strongest candidates for reuse return a clear business result: calculate shipping options, retrieve a risk score, check an invoice, find available inventory, or create a support ticket in another platform. Raw low-level operations make each agent reconstruct the provider’s workflow and are usually harder to select, combine, and support reliably.
A reused registration is a shared production dependency. Before changing its credentials, allowlist, endpoint or tool contract, identify every agent that uses the generated actions and test each one. A single provider change can otherwise affect several agent experiences at once.
🧑💼 Curate each server for the work
Section titled “🧑💼 Curate each server for the work”Reuse should not mean putting every approved tool on every server. Each tool’s name, description and input schema takes up part of the client’s context, and the model must choose among everything it can see. Salesforce warns that clients can struggle once a server grows beyond a few dozen tools. It is a design warning, not a target to fill. Start with the work one group needs to complete, then add a tool only when you can explain when it should be chosen.
In this context, a persona is a group of users with similar tasks and access needs. A server for service representatives might combine Case reads and order status with entitlement checks and one escalation Flow. A sales server could provide Account and Opportunity reads, a meeting-preparation prompt and a pricing-approval action. Both can reuse capabilities from the same org while presenting a smaller, clearer tool surface.
Split them again when permissions, data sensitivity or operational risk differ. A shared job title is not enough reason to share every tool.
🧾 Design the contract the model actually sees
Section titled “🧾 Design the contract the model actually sees”The model does not see the intent behind an Apex class, Flow, API, or provider implementation. It sees the published tool contract: the name and description that help it decide whether to use the tool, the input schema that tells it what to supply, and any output schema and behavioural annotations that help the client interpret the result. A technically correct operation can still be a poor agent tool when that contract is vague.
Consider the order-status capability used earlier in this article:
| Contract element | Weak contract | Stronger contract |
|---|---|---|
| Name | get_data | check_order_status |
| Description | Gets order information. | Returns the current fulfilment state and latest delivery estimate for a supplied order number. Use when a customer asks where an order is. This tool does not cancel or change the order. |
| Input | id: string | orderNumber: string, the customer-facing order number, including its prefix |
| Result | Raw Order, Order Item, and shipment records plus free-form text | A bounded result such as found, status, estimatedDelivery, requiresEscalation, and lastUpdated |
| Behaviour | Side effects are not described | Accurate read-only, destructive, idempotent, and open-world annotations |
The stronger version establishes four boundaries. Its name and description distinguish it from similar tools. Its input explains which identifier the caller must collect. Its result provides the business answer without making the model reconstruct it from internal records. Its annotations help a client present and handle the operation appropriately, but they are not permission enforcement. The MCP specification requires clients to treat annotations as untrusted unless they come from a trusted server.
Granularity matters just as much as wording. Publishing get_order, list_shipments, find_carrier and calculate_escalation leaves the model to discover and preserve an implementation sequence. Publishing one tool that contains an entire case-management workflow gives the model too little visibility or control. Salesforce’s Hosted MCP best practices recommend the middle ground: a tool should return one useful, self-contained result without absorbing decisions that belong to the caller.
Deterministic sequencing and transaction handling belong in the provider or an orchestration layer such as Flow, Apex or MuleSoft. Expose the business operation the agent actually needs.
Review the contract as part of the product interface, not as documentation added after implementation. Test whether representative prompts select the tool, whether incomplete requests produce a useful validation error, whether no-match and partial-result states are explicit, and whether the result contains only what the next decision requires. Salesforce’s custom Apex example shows how descriptions and structured inputs and outputs become the information an MCP client uses to select and interpret a hosted tool.
🧭 MCP, an API Action, MuleSoft, or A2A?
Section titled “🧭 MCP, an API Action, MuleSoft, or A2A?”These are not four interchangeable products. First decide what is being invoked: a fixed operation, a reusable tool or another independently capable agent. Then decide where authentication and transformation should live. Do the same for orchestration, retries and recovery. MuleSoft can sit behind an API action or an MCP tool. An agent reached through A2A can use MCP tools of its own.
Start with the caller and the identity it must preserve. Decide whether the result must return during the current interaction, and how the work should behave when it is slow or fails. Volume matters too. “High volume” might mean a bulk data job, a stream of business events or many interactive requests, and those need different designs.
| Requirement | Best starting point | Boundary to check |
|---|---|---|
| An existing point-to-point Agentforce action or integration is stable and well governed | Keep the existing action | A protocol migration provides little value when the contract and consumer are fixed. Move only when MCP adds a real reuse, discovery, or governance benefit. |
| A stable, well-described HTTP operation maps cleanly to one request and response | External Service API action | External Services generates the binding from an OpenAPI document. It is the lower-code option, not the place for complete custom request and response processing. |
| Salesforce must own custom validation, orchestration, or error handling | Flow or Apex action | Use Flow for admin-maintainable business orchestration and Apex when you need exact control of validation, callouts, response shaping, or failure behaviour. |
| A provider exposes reusable tools that fit Agentforce’s supported transport, authentication, schemas, and execution limits | MCP for Agentforce | The Summer ‘26 client uses server-to-server credentials rather than the conversational user’s delegated identity. Check the latest MCP for Agentforce considerations before choosing it. |
| An external MCP-capable AI client should act as an individual Salesforce user | Salesforce Hosted MCP Server | Hosted MCP uses interactive, per-user OAuth and applies that user’s object, field, and record access. It is not currently a headless machine-to-machine route. Verify the latest Hosted MCP client and authentication guidance. |
| The integration needs transformation, routing, canonical models, retries, mediation, or enterprise policy enforcement | MuleSoft or your existing integration platform | The integration layer can expose the result through an API action or MCP tool. MCP does not remove the processing, recovery, monitoring, or licensing responsibilities behind that contract. |
| A deterministic system already knows the exact Salesforce operation it must call | REST, GraphQL, Composite, a custom API, or MuleSoft | Model-led tool selection adds cost and uncertainty when no reasoning decision is required. Choose the API by transaction shape, limits, identity, and failure semantics. |
| A large dataset must be loaded, extracted, or reconciled | Bulk API 2.0 or an ETL/data integration tool | Treat it as an asynchronous job and design for partial failure, reconciliation, limits, and restart rather than an interactive MCP call. |
| Systems must react asynchronously to business events or Salesforce record changes | Platform Events or Change Data Capture through Pub/Sub API | Define replay, idempotency, ordering, subscriber recovery, and event allocations explicitly. Salesforce’s event-driven architecture guide covers the pattern choices. |
| One Agentforce agent delegates work to specialised Agentforce agents in the same org | Multi-Agent Orchestration for Agentforce | This is a Summer ‘26 beta with same-org, agent-type, delegation-depth, and timeout constraints. Verify the current Multi-Agent Orchestration considerations. |
| An agent delegates a stateful task to an independently operated agent across a platform boundary | Agent2Agent (A2A), where both platforms support it | A2A adds agent discovery, task lifecycle, status, and artefacts. Product support and release status vary, so check the participating platforms as well as the current A2A specification. |
The result is often a composition rather than a winner. A Hosted MCP tool might run a Flow or Apex action. An Agentforce MCP tool might call a MuleSoft process that owns transformation and recovery. A remote agent reached through A2A might use MCP to reach its own tools.
MuleSoft is especially important when a target system does not publish a suitable MCP server or when a direct tool call would bypass canonical models, policy enforcement, or recovery logic your organisation already depends on. Its MCP Bridge and MCP Connector can make existing APIs agent-accessible without moving that integration behaviour into the agent. In that design, MCP is the agent-facing contract and MuleSoft remains the integration layer behind it.
In practice, keeping the existing action is my likely recommendation. An existing Salesforce integration already has a working consumer and a known contract. Changing the protocol does not improve either by itself. For outbound MCP, it adds a registration to maintain in every org, a tool-action rebinding step after deployment and another governance surface to operate. When the existing path is already an agent action, replacing it with an MCP action does not reduce consumption because Salesforce bills both at the same rate. That can be a fair exchange for a reusable, discoverable contract, but not when a fixed consumer already knows what it needs to call.
The test I apply is whether I can name the second consumer. If it is a specific team, client or agent, the reuse argument is real and MCP starts to earn its place. If the answer is only “we might want one later”, the reuse case is not real yet. Keep the existing action unless MCP solves a concrete discovery or governance problem today.
🔐 The Trust Model Is the Real Product
Section titled “🔐 The Trust Model Is the Real Product”Self-description is MCP’s advantage and part of its risk. A tool description is presented to the model as context, so malicious instructions hidden inside that description can influence the agent. Treating server metadata as harmless documentation misses the core threat.
🧪 Scan before allowlisting
Section titled “🧪 Scan before allowlisting”Where the July 2026 rollout is available, Agentforce Registry assigns an overall server score and an individual score to each third-party tool:
| Score | Salesforce interpretation | Practical response |
|---|---|---|
| Low | No potential or actual malicious instruction detected | Continue the normal supplier, schema, permission, and data review. |
| Medium | Potential but inconclusive risk detected | Investigate the flagged rationale and do not allowlist until it is understood. |
| High | Malicious instruction detected | Reject the tool unless the provider removes the behaviour and the server is reassessed. |
The scan looks for tool-poisoning patterns such as data exfiltration, privilege escalation, steering towards one tool, and instructions that attempt to override agent guardrails.
If your org does not show these scores, continue the same supplier, description, schema, permission, and data review. The absence of a score is not a safety verdict.
🔁 Detect changes after approval
Section titled “🔁 Detect changes after approval”Salesforce captures tool definitions and schemas when you register and allowlist them. It checks those contracts at session start and invocation. If a publisher changes an approved tool significantly, Salesforce blocks the out-of-sync action by removing it from the agent’s available reasoning context.
That protection is deliberately conservative. It can interrupt a legitimate tool after a provider changes its description or schema, so contract monitoring and vendor communication belong in the operating model.
🚪 Enforce policies outside the model
Section titled “🚪 Enforce policies outside the model”Allowlisting and Agentforce Gateway policies solve different problems. Allowlisting decides which server tools Salesforce can make available as Agentforce actions. It does not limit how often an approved tool can be called or decide which agents share the connection.
Agentforce Gateway policies add runtime enforcement to selected MCP server connections. A Quota Management policy caps calls over a configured interval, with the quota shared or separated by tool and by agent. An MCP Attribute-Based Access Control policy allows or blocks tools by name.
You can apply a policy manually to selected servers or use matching criteria to cover current and future registrations by server source or name. You can also narrow the policy to selected agents; otherwise it applies to every agent that calls the protected connection. Registering a server does not prove that the required policy covers it, so check both the server and agent targets before activation.
🧨 Treat tool output as untrusted input
Section titled “🧨 Treat tool output as untrusted input”The MCP controls above answer which tool may run, not whether the values it returns are trustworthy inputs to the next reasoning step. Risk scoring examines tool descriptions for poisoning, contract checks compare approved definitions and schemas, allowlisting selects the tools available to the agent, and Gateway policies control access and call volume. Those controls remain important, but an approved tool can still return content supplied by a compromised provider or copied from an untrusted record.
That content can influence later reasoning. For example, an external search tool might return a document containing instructions to ignore the user and invoke another tool. If Agentforce includes that result in its reasoning context, the embedded instruction becomes an indirect prompt-injection attempt.
The risk can persist if the result is written to Salesforce. A later agent or prompt template may retrieve it as ordinary CRM data, and a conventional integration may do the same. In the other direction, a Case description can carry this kind of payload to an external MCP client even when the user is fully authorised to read the Case. Salesforce permissions establish whether the content may be read. They do not establish that its text is safe for another model to follow.
Salesforce documents prompt defence through system policies and prompt injection detection as a Beta feature for detecting injection attempts in user prompts. Neither is documented as a distinct control that inspects MCP tool-result payloads before Agentforce reasons over them. Prompt defence is one layer rather than a guarantee. Bound the consequences with least-privilege identities, narrowly scoped tools and deterministic validation. Sensitive writes or destructive actions need explicit approval.
👤 Preserve user accountability on hosted servers
Section titled “👤 Preserve user accountability on hosted servers”Every Salesforce Hosted MCP call runs as the user who completed the OAuth authorisation flow. CRUD permissions, field-level security, sharing, profile permissions, and permission sets still apply, and the action is attributed to that user in Salesforce audit data.
Tool annotations improve client behaviour by labelling read-only, destructive, idempotent, and open-world operations. They remain hints. A client might ignore them, so they cannot replace permissions, a focused server, or human confirmation for destructive work.
Salesforce’s security guide covers the hosted server’s authentication, authorisation, permission, and logging layers in more detail.
🚧 Current Boundaries to Design Around
Section titled “🚧 Current Boundaries to Design Around”The main Salesforce MCP connection paths are generally available in Summer ‘26, but that does not make them interchangeable with every integration pattern. Their boundaries should shape the first use case and the rollout plan. The constraints below reflect Salesforce documentation reviewed on 26 July 2026.
Check the current documentation again before implementation. Transport, authentication, schema support and timeouts can all change the design. So can billing, packaging and the status of a product-specific server.
📥 Agentforce consuming external servers
Section titled “📥 Agentforce consuming external servers”- Transport is fixed. Agentforce supports Streamable HTTP. HTTP+SSE,
stdio, and other transports are not supported. - Authentication is application-level. No authentication and OAuth 2.0 client credentials are the standard supported patterns. Some OAuth 2.1 client-credentials configurations require additional setup. Authorisation-code flows, including PKCE, and JWT bearer flows are not supported in this direction.
- The conversational user’s identity is not delegated. User-level external authentication is not supported, so the provider sees no individual external identity for a no-authentication connection or the shared application identity used by client credentials.
- Agentforce consumes tools only. MCP server apps, prompts, and resources are not supported by the Agentforce MCP client.
- Builder favours shallow schemas. Primitive values, top-level objects and properties, and top-level arrays of objects have the strongest support. Nested properties, nested arrays of objects, and dynamic payloads are not supported end to end. If a value cannot be resolved to a Lightning type, the action can still run, but that value cannot be stored in a variable or used in deterministic downstream logic.
- Timeouts apply at two levels. An MCP client call times out after 60 seconds. The Atlas reasoning engine has a 120-second timeout, which several calls can exhaust together.
- Each invocation is billable. MCP tool actions are billed at the same rate as other agent actions, with usage reported through Digital Wallet.
- Deployment requires rebinding. Agents can be packaged or deployed with MCP tool-action references, but server registration metadata is not packaged. Register the server, allowlist its tools, and replace the deployed references with actions generated in each target org.
- Connected does not always mean usable. Registry can continue to show a server as connected when it is unavailable or its tools are out of sync. Use an end-to-end test to establish availability, then check the
Available Actionstrace event before activation.
📤 External clients consuming Salesforce
Section titled “📤 External clients consuming Salesforce”- Hosted MCP currently uses a named-user flow for third-party clients. Salesforce’s current connection guide has a user complete the OAuth authorisation-code flow, with supported clients using PKCE. The MCP session is tied to that Salesforce user. Salesforce does not currently document a shared principal or machine-to-machine flow for Hosted MCP.
- Client registration and server authorisation are separate boundaries. The current third-party client guide requires an External Client App and says a Connected App cannot replace it for MCP authentication. Salesforce documents Vibes separately as not requiring an External Client App. Although a third-party client is configured with an app consumer key and a server URL, Salesforce’s security guidance says the app configuration cannot restrict access to one specific Hosted MCP server.
- Server curation and Salesforce access provide the working boundary. Standard server tool sets are fixed. Activate only the standard servers you need, or create a custom server when the standard surface is too broad. The authenticated user’s object permissions, field-level security, sharing, profile permissions, and permission sets still apply.
- The underlying capability keeps its limits and costs. API rate limits, governor limits, product licences, and consumption still apply. For example, Data 360 MCP calls count against the underlying Connect API limits and Flex Credit usage.
- Custom logic still needs normal engineering controls. Flow and Apex run as the authenticated user and retain their platform limits, sharing behaviour, error-handling needs, and testing responsibilities.
- Client behaviour varies. Tool annotations are hints rather than enforcement, and prompt support differs between MCP clients. Test the behaviour you rely on before making it a control or required interaction.
🤝 Across both patterns
Section titled “🤝 Across both patterns”- The tool contract affects selection. Clear names, descriptions, input schemas, and bounded outputs help the model choose and call a capability correctly.
- More tools can make the client less capable. Large or overlapping tool sets consume context and make selection less reliable. Curate around the work instead of exposing every available operation.
- Technical success is not business success. A successful tool call does not prove that the agent chose the right tool, interpreted the result correctly, or handled side effects safely.
- One log source is not enough. Observability must show whether the tool was available and selected, then record the invocation, latency and errors. It also needs the downstream effects, consumption and the user’s outcome.
These constraints do not make MCP unsuitable. They tell you where a measured pilot should begin: a small tool set, read-only access, a clear identity model, simple schemas, representative users, and an observable fallback path.
Turning that pilot into an accepted release takes more than a successful call. Validate each environment and approve the provider. Establish the runtime identity and where data is processed. Then exercise failure and capacity limits, and assign ownership for monitoring and recovery. The setup guide carries the full pre-activation and release checklist for both directions.
🔭 What to Watch Next
Section titled “🔭 What to Watch Next”Salesforce and MCP are changing quickly, so this section focuses on developments that could change an architecture or release decision. It is not a forecast. Each item starts with the current documented position, then names the evidence that would justify revisiting the design. A product announcement or protocol addition is a reason to investigate, not proof that Salesforce supports it.
The current-state statements below were checked against published documentation on 30 July 2026.
🪪 Identity and authorisation
Section titled “🪪 Identity and authorisation”When Agentforce consumes an external MCP server, current Salesforce support is limited to servers that require no authentication or use OAuth 2.0 client credentials. It does not delegate the conversational user’s identity. In the other direction, the current Hosted MCP documentation describes interactive authorisation for a named Salesforce user, not a shared principal or headless machine-to-machine flow.
The MCP project now defines optional client-credentials and enterprise-managed authorisation extensions, but protocol inclusion does not make them Salesforce features. Both ends must explicitly support an extension.
Revisit the design when: Salesforce documents a different identity model. For outbound calls, that would mean a delegated-user flow. For Hosted MCP, it would mean a supported headless identity with defined scopes and clear revocation, policy and audit behaviour. Until then, neither pattern can adopt the other’s identity model.
🧬 Protocol revision and interoperability
Section titled “🧬 Protocol revision and interoperability”MCP 2026-07-28 is the current protocol revision. It replaced the protocol-level session and initialisation handshake with stateless requests, added server/discover and per-request capability negotiation, and introduced breaking changes from 2025-11-25. The Salesforce pages cited in this article do not state which protocol revisions Agentforce or Hosted MCP support.
Revisit the design when: Salesforce, the other endpoint and the chosen client share a documented protocol revision. Put that exact combination through the same authorisation, discovery and tool-call tests, then record the result. The label MCP-compatible is not enough by itself.
🐌 Tool shapes and long-running work
Section titled “🐌 Tool shapes and long-running work”The current MCP specification lets tools describe complex inputs and outputs with full JSON Schema 2020-12, but Agentforce Builder cannot use every valid schema end to end. Salesforce says support is strongest for primitive values and simple top-level fields. It also limits an MCP client call to 60 seconds and the wider Atlas reasoning step to 120 seconds. A tool can therefore be valid MCP and still be too complex or slow for Agentforce.
The optional MCP Tasks extension is designed for work that cannot finish inside a normal request. Instead of keeping the request open, a server can return a durable task ID. A compatible client can then reconnect, check progress, provide requested input, or request cancellation. The extension works only when both the client and server explicitly advertise support; the current Salesforce considerations do not document Tasks support for Agentforce.
Revisit the design when: Salesforce documents the schema features or Tasks behaviour you need, and every participating component passes an end-to-end test. Until then, keep Agentforce tool contracts shallow and put long-running work behind an asynchronous job pattern.
📦 Promotion and configuration portability
Section titled “📦 Promotion and configuration portability”For outbound connections, Salesforce documents that agent metadata can be deployed with MCP action references. External server registration metadata is not packaged, so those references must be replaced in each target org.
For Hosted MCP, custom-server metadata can move through Metadata API. Server activation and External Client App policy still need target-environment checks, as do the client configuration and user access.
Revisit the design when: Salesforce provides stable identifiers and deployment support for the required registrations and bindings, or supported automation removes the manual rebinding step. Until then, do not call the lifecycle portable unless a fresh target org can reproduce the connection without hidden Setup work.
🧾 Governance and end-to-end evidence
Section titled “🧾 Governance and end-to-end evidence”The two directions still have separate control and evidence planes. Outbound evidence sits in Gateway policies, Agentforce trace data and provider logs. Hosted MCP uses External Client App policy, Salesforce permissions and Event Monitoring.
The MCP project’s March 2026 roadmap identifies audit trails and SSO-integrated authentication as enterprise gaps, alongside gateway behaviour and configuration portability. The current protocol defines OpenTelemetry trace-context conventions, but that does not prove end-to-end propagation through Salesforce.
Revisit the operating model when: You can follow the whole business transaction. That means correlating policy coverage and identity with consent, tool selection and invocation. You also need the downstream effect, cost and recovery evidence. A new dashboard or risk score can improve one control, but it is not a unified evidence model by itself.
🔓 Headless 360’s privileged capability surface
Section titled “🔓 Headless 360’s privileged capability surface”The Headless 360 MCP Server is a Beta service. It exposes four tools: Discover, Describe, Dispatch and Dispatch (Read-Only). That keeps the visible tool set small while opening a growing operation library. The library spans user administration and Apex, as well as event-driven integration and Named Credentials. Calls run as the authenticated user. Salesforce recommends making configuration changes in a sandbox or Developer org before applying them in production.
Revisit the release decision when: The service reaches a status appropriate to your risk appetite and Salesforce documents enough about operation coverage and limits, approvals, audit evidence and failure recovery for your use case. A small number of discovery tools does not make the underlying capability surface low risk.
🌐 Agent delegation beyond one Salesforce org
Section titled “🌐 Agent delegation beyond one Salesforce org”Multi-Agent Orchestration for Agentforce is Beta. It supports Agentforce agents in one org and permits one level of delegation. The separate A2A protocol defines discovery and task lifecycle for independently operated agents, including their messages and artefacts. It is not an MCP tool-call mode.
Revisit the design when: Salesforce explicitly supports the cross-org or external-agent direction you need and documents identity propagation, policy enforcement, timeout, task ownership, tracing and recovery. Until then, keep an MCP tool call, same-org subagent delegation and an A2A task as three separate architectural contracts.
Of these signals, richer identity choices and a deployable connection lifecycle would remove the most significant Salesforce-specific workarounds. Protocol features such as Tasks and broader schemas become valuable only after Salesforce and the other endpoint support them together. Headless 360 and external agent delegation expand what an agent can reach, but they also enlarge the approval, audit, and recovery problem.
🎯 Final Thoughts
Section titled “🎯 Final Thoughts”Summer ‘26 makes MCP an architectural capability in Salesforce rather than a developer experiment. Availability alone is not a reason to adopt it. Before using MCP in production, make five decisions explicit:
- Start with the business need. Define the outcome, who benefits and how you will recognise success. Then ask whether the work genuinely benefits from agent-led tool selection and a reusable MCP contract rather than a deterministic process.
- Choose the connection direction. Decide whether Agentforce is consuming a capability or Salesforce is providing one; the identity, onboarding, and governance model changes with the direction.
- Curate before connecting. Expose a small, outcome-oriented tool surface instead of giving the model every available operation.
- Keep identity and enforcement explicit. Use the appropriate OAuth model, Salesforce permissions, allowlists, and applied Gateway policies rather than relying on agent instructions as security controls.
- Prove the operating model. Test with representative users and exercise the failure paths. Make sure the audit evidence, ownership, rollback and target-org bindings are ready before activation.
The most important judgement is knowing what MCP does not replace. It standardises the agent-facing tool boundary, but your team still owns identity, business logic and transaction design. Data governance, monitoring, recovery and support remain yours too.
Use MCP where a reusable, discoverable capability makes the integration easier to understand and govern. Keep conventional integrations where determinism, throughput or established orchestration matters more than agent-led tool selection.
If MCP fits the business need, continue with the Salesforce MCP setup guide to build and verify a bounded connection in either direction. For the wider Agentforce development model, review AI and the Salesforce developer journey. The official quick-look module below reinforces the MCP client and governance concepts.