The integration challenge facing Salesforce teams
Salesforce solution architects and license owners often spend weeks building one-off REST endpoints so their Agentforce agents can reach data or logic outside the platform. Each new external system requires custom authentication handling, payload mapping, and ongoing maintenance when the third-party API changes. The result is brittle code that consumes developer time and creates governance gaps around permissions and audit trails.
This pain hits mid-market organizations hardest because they lack large integration teams yet still need agents that can check inventory systems, run risk calculations, or pull marketing journey status. The underlying issue is the absence of a shared protocol that both the agent and the external service understand without bespoke translation layers.
How MCP changes the current state of agent integrations
MCP (Model Context Protocol) is an open standard that lets AI hosts discover and invoke tools, resources, and prompts from any compatible server. Salesforce added native support for this protocol in June 2025, allowing bidirectional traffic between Agentforce and outside systems.
Salesforce-hosted MCP servers now expose Apex actions, Flows, Named Queries, and Prompt Builder templates as standardized tools. External clients such as Claude or custom Slackbots can call these capabilities while the platform still enforces per-user permissions, sharing rules, and the Einstein Trust Layer. In the other direction, Agentforce agents can register external MCP servers and treat their tools as native actions.
The shift replaces scattered custom callouts with one discoverable interface. Tool definitions travel with metadata so agents receive clear names and descriptions instead of raw API schemas. This reduces the context-window overhead that plagued earlier raw API approaches.
Why a standards-based approach usually beats heavy custom builds
A lighter MCP route delivers faster time-to-value because you register a server once and let the protocol handle discovery and invocation. You keep ownership of the code you write in Apex or Flow while avoiding the need to maintain separate authentication services for every external partner.
Security and governance come built in. When an external MCP server is registered through the API Catalog, Salesforce applies risk scoring for issues such as tool poisoning and lets you set per-user OAuth credentials. Existing field-level security and sharing rules continue to apply without additional layers of custom checks.
The approach also simplifies maintenance. When a third-party system updates its interface, you update the MCP server definition rather than rewriting every downstream agent action. Winter ’27 enhancements centralized this management in the API Catalog, adding headless registration via REST so teams can automate server creation in CI pipelines.
How the architecture actually works in practice
Start in Setup under API Catalog. Enable MCP servers, then choose between Salesforce-hosted endpoints or external registrations. For a hosted server you add the specific assets you want to expose: an Apex class that calculates loan risk, a Flow that updates Marketing Cloud journeys, or an Agentforce agent that performs account research. Each asset becomes a tool with a human-readable name and description.
Authentication uses External Client Apps with the mcp_api scope. You can configure OAuth 2.0 flows or store per-user credentials through external credentials so every call respects the logged-in user’s context. For external servers, you supply the server URL and allowed tools; Salesforce scans the tool definitions for risk before activation.
Once registered, Agentforce agents discover the new tools through the standard tools/list and tools/call methods over Streamable HTTP. The same registry works in reverse: external assistants call into your hosted server and receive grounded responses because the Salesforce context and Trust Layer remain in place.
Usage is metered. Basic hosted MCP server access is included with Enterprise Edition and above. Agentforce actions invoked through MCP consume Flex Credits at roughly 20 credits per action. Existing API limits still apply for record operations.
Honest limitations to consider before rollout
Not every integration pattern maps cleanly to MCP. Complex nested response structures may require adjustments on the server side, and some legacy Agentforce agents need upgrading before they can be exposed as tools. Per-user authentication is supported for external servers but is not available in every Agentforce context, so test thoroughly if your use case involves headless execution.
Tool descriptions matter. Vague names cause the agent to route requests incorrectly, so teams should treat prompt engineering of these descriptions as a first-class task. Finally, while the protocol reduces custom code, you still own the Apex or Flow logic behind each exposed tool and must monitor usage in the Digital Wallet to stay within Flex Credit budgets.
Decision framework: when MCP is the right call versus a heavier build
Choose the MCP route when your goal is to expose existing business capabilities to multiple AI clients without duplicating logic. It fits best when the external system already supports or can be wrapped with MCP, when governance requirements are met by Salesforce permissions and the Trust Layer, and when you want to avoid maintaining separate API contracts for each integration partner.
A heavier custom integration remains appropriate when the external system demands proprietary message formats that cannot be expressed as MCP tools, when you need real-time streaming responses beyond what Streamable HTTP provides, or when regulatory constraints require dedicated audit infrastructure outside the Salesforce Trust Layer. In those cases the extra development effort is justified because the lighter path would force unacceptable compromises on functionality or compliance.
Next steps for your team
Review the Hosted MCP Servers guide and the Agentforce MCP documentation to map your current custom callouts to potential MCP tools. Once you have identified three to five high-value capabilities, register a test server in a sandbox and measure both development time saved and Flex Credit consumption.
Want help implementing Salesforce MCP servers for your Agentforce agents? Book an intro call to talk through your setup.
Agentforce & AI Agents
Autonomous agents that predict, automate, and execute revenue-driving actions across sales, service, and marketing.
Read Next
Why Agentforce Third-Party Integrations Demand Custom Guardrails
Salesforce admins and solution architects integrating Agentforce with external tools via MCP face supply-chain and privilege risks that native guardrails do not fully cover. This post shows how to add targeted custom controls without heavy custom code.
Agentforce ROI: What Actually Moves the Needle for Busy Leaders
Agentforce has moved past pilots. Here's a simple way to prove ROI: pick one process, capture a baseline, and track leading and lagging metrics.
What Does a Salesforce AI Agent Architecture Look Like for a Head of Salesforce Running Service Cloud?
A Salesforce AI agent architecture has five layers: data and permissions, runtime, tools, channels, and oversight. A Head of Salesforce running Service Cloud should decide them in that order, starting with what the agent may see and do.
