Salesforce MCP: How the Model Context Protocol Connects AI Agents to Your CRM

Every AI integration problem eventually arrives at the same question: how do you connect an intelligent agent to the systems it needs to act on, without writing a bespoke connector for every combination of model and tool? The Model Context Protocol is the industry's answer — and Salesforce has moved decisively to embed it at the centre of the Agentforce platform. This post covers the protocol itself, Salesforce's six MCP solutions available today, the inbound versus outbound architecture patterns, the security model, and the limitations your architects need to understand before committing to an MCP-based design.

What Is MCP?

The Model Context Protocol is an open standard originally developed by Anthropic and subsequently donated to the Agentic AI Foundation (AAIF). It establishes a standardised communication protocol that allows AI models to discover and invoke external tools, retrieve data from external resources, and use prompt templates — all through a single consistent interface.

The motivation is straightforward. Without a standard, connecting N AI models to M external tools requires N × M custom integrations. Every new model needs its own connector to every tool it might call; every new tool needs to be integrated separately into every AI application. MCP collapses this to N + M: each model implements the client side of the protocol once, and each tool implements the server side once. The result is a plug-and-play ecosystem in which any compliant client can work with any compliant server — the same logic Salesforce uses to describe MCP as the USB-C port for AI.

The protocol is built on JSON-RPC 2.0 and supports two transport mechanisms: stdio for local integrations where client and server run in the same environment, and HTTP with Server-Sent Events (SSE) for remote connections. Three primitives define the surface area of any MCP server:

• Resources — data exposed to the AI model for context (documents, database rows, CRM records).
• Tools — executable functions or APIs that allow the AI to take action (creating a Salesforce record, querying an order, sending a message).
• Prompts — reusable prompt templates that encode workflows or interaction patterns the server makes available to the client.

MCP Architecture Deep Dive

MCP uses a three-tier client-server architecture. Understanding each tier is essential before evaluating how Salesforce implements it.

Host — the AI-powered application that users interact with directly. Claude Desktop, Cursor, and Agentforce are all hosts. The host contains the LLM and is responsible for deciding when to invoke MCP capabilities and how to incorporate the results into its responses.

Client — embedded within the host, the MCP client maintains a 1:1 connection to each MCP server the host is configured to use. It handles the JSON-RPC message framing, request-response mapping, and capability negotiation. A single host can contain multiple MCP clients, each connected to a different server.

Server — an independent process that exposes Tools, Resources, and Prompts through the MCP standard. Servers can run locally (as a subprocess of the host, communicating via stdio) or remotely (over HTTP with SSE for server-sent streaming events). Each server typically focuses on a specific integration: a GitHub MCP server, a PostgreSQL MCP server, a Salesforce MCP server.

The protocol handshake is a defined sequence. On connection, the client sends an initialize request containing its protocol version and capabilities. The server responds with its own capabilities. The client then sends an initialized notification to confirm the session is active. From that point, the client can query available tools, request resources, and invoke tools — and, notably, the server can request sampling from the client, asking the LLM to generate a completion as part of a server-side workflow. This bidirectionality is what distinguishes MCP from a simple REST wrapper.

Salesforce's MCP Ecosystem — What Ships Out of the Box

As documented in the Agentforce Developer Guide, Salesforce offers six MCP solutions across its platform, Heroku, and MuleSoft. These span both client and server roles, and span Beta through Generally Available status.

The six solutions differ substantially in what they expose and who they serve:

• Salesforce DX MCP Server (Beta) — enables natural language commands against Salesforce orgs without writing SOQL or Apex. Verified sample prompts from the developer guide include: "Query my DreamHouse org and show me info about my properties" and "Run agent tests in my org". Targeted at developers and architects working in AI-assisted development environments.
• Salesforce Hosted MCP Servers (Beta) — fully-managed Salesforce-operated endpoints that expose CRM and Commerce data as MCP tools to external AI assistants. Sample prompts: "Look at the Account object in my Salesforce org and tell me which fields are required to create an Account" and "Get all accounts from my Salesforce org that have annual revenue over 1 billion dollars". Pricing is currently TBD.
• Agentforce Vibes Extension MCP Client — an IDE extension that acts as an MCP client, allowing developers to use the Salesforce DX MCP Server from within their development environment. Generally available.
• Heroku MCP Server — facilitates interaction between LLMs and the Heroku Platform. Sample prompts: "List all my Heroku apps associated with the AwesomeSauce team" and "Deploy the HerokuRules project". Allows AI assistants to manage Heroku infrastructure directly through natural language.
• MuleSoft MCP Server — enables interaction with the MuleSoft Anypoint Platform. Sample prompts: "Create a Mule project that creates an order in NetSuite every time an opportunity in Salesforce is updated to stage Closed Won" and "Deploy Mule application in current project with high security, high availability, and performance optimised settings".
• Anypoint Connector for MCP — connects LLM applications with APIs managed through MuleSoft. Sample prompts: "Get a list of all approved vendors, including their product categories" and "Create a purchase order for 100 units of widgets". Positions MuleSoft-managed APIs as MCP tools consumable by any compliant AI agent.

Inbound vs Outbound MCP

The most important architectural distinction in any Salesforce MCP design is the direction of the connection: is Salesforce acting as an MCP client (outbound) or an MCP server (inbound)? These are fundamentally different patterns with different governance requirements.

Outbound MCP — Salesforce as MCP Client. Agentforce connects to external MCP servers. An Agentforce agent can invoke tools hosted by third-party MCP servers — PayPal, Slack, GitHub, or any compliant endpoint. As announced in the June 2025 developer blog, Agentforce includes a native MCP client in Pilot with the Agentforce 3 (July 2025) release, enabling agents to connect to any MCP-compliant server without custom code. Governance is managed through a central MCP Server Registry in which authorised admins whitelist the servers and specific tools that agents are permitted to use. Rate limiting applies at approximately 50 requests per minute per server per agent.

Inbound MCP — Salesforce as MCP Server. External AI applications connect to Salesforce via Salesforce-hosted MCP servers. Claude Desktop, Cursor, ChatGPT, or any MCP-compliant host can use these servers to query CRM records, access Commerce APIs, and perform actions — all through natural language translated to MCP tool calls. The hosted MCP servers expose specific Salesforce APIs as tools. These servers are fully managed by Salesforce; customers do not need to deploy or maintain infrastructure to use them.

Security Model

The security architecture for Salesforce MCP is layered and closely mirrors the security model for standard Salesforce API access, with additional controls specific to the agentic context.

Authentication. The hosted MCP server validates OAuth 2.0 tokens — either a JWT from the Shopper Login API (for Commerce scenarios) or a standard Salesforce access token — before processing any request. The MCP specification, following OAuth 2.1 guidance, mandates PKCE (Proof Key for Code Exchange) for authorisation code flows. Token passthrough is explicitly forbidden: each MCP server must validate tokens directly against the authorisation server rather than forwarding them through intermediaries.

Salesforce platform security enforcement. All MCP-driven operations execute in the context of an authorised Salesforce user. This means the standard Salesforce security stack applies in full: object permissions, field-level security (FLS), organisation-wide defaults, sharing rules, and record-level access. If a field is hidden for a given user profile, the MCP server will not return it, even if the requesting AI agent explicitly asks for it.

MCP Server Registry. For outbound scenarios, Agentforce provides a central registry where org administrators whitelist permitted MCP servers and their specific tools. Tools from approved servers are saved as actions in the Agentforce Asset Library and become available to agents through the standard agent builder. Unapproved servers cannot be accessed by Agentforce agents.

Rate limiting. Connections to external MCP servers are rate-limited at approximately 50 requests per minute per server per agent as a default. This protects both the target server and prevents runaway agent loops from consuming excessive quota.

Audit trail. All MCP interactions are logged through Salesforce's event monitoring infrastructure, providing an auditable record of agent activity for compliance and incident investigation.

Just-in-time access controls. For high-impact actions, human-in-the-loop approval can be required before an agent executes a tool call. This is the recommended pattern for any MCP-driven action that modifies data at scale or carries significant business risk.

Principle of least privilege. Salesforce's guidance recommends using a dedicated integration user with minimal permissions for MCP connections, rather than connecting under an admin account. This limits the blast radius if a token is compromised.

Limitations and Considerations

Before committing to MCP as a core pattern, architects should understand the current constraints:

• Beta and Pilot status. As of April 2026, the most significant Salesforce MCP capabilities — Salesforce DX MCP Server, Salesforce Hosted MCP Servers, and the native Agentforce MCP client — are in Beta or Pilot. None are generally available, and production use carries the standard early-adopter risk of breaking changes and limited support SLAs.
• Targeted API surface only. The hosted MCP servers support access to "certain targeted APIs" on the Salesforce platform. This is not a full Salesforce API gateway. Not every Salesforce object, action, or metadata type is exposed as an MCP tool. Architects must verify that the specific capabilities their use case requires are actually available before designing around hosted MCP servers.
• No custom MCP server building on Salesforce Platform yet. Customers cannot yet build and deploy their own MCP servers on the Salesforce Platform itself. This is on the public roadmap, but the current options for custom servers are Heroku (using the Heroku MCP Server pattern) or self-hosted infrastructure.
• Rate limiting constraints. The ~50 requests per minute per server per agent default may be inadequate for high-frequency agentic workflows. The ceiling should be confirmed with Salesforce account teams for any production design that requires sustained high throughput.
• No cross-session memory. Each MCP request is isolated. Agents do not retain memory of prior MCP interactions across sessions. Multi-step workflows requiring state preservation must manage that state explicitly in the agent's context window or through external storage.
• Raw metadata without semantic context. MCP servers can expose raw Salesforce metadata — field names, API names, object structures — without business context. AI agents interpreting raw metadata without guidance can produce misinterpretations. Well-defined system prompts and targeted tool descriptions are essential to guide agent behaviour.
• Security vetting of public MCP servers is essential. As of December 2025, more than 10,000 public MCP servers had been created. The MCP Server Registry whitelist is the primary control mechanism; admins must actively curate and review which servers are permitted rather than relying on any implicit trust from a server appearing in a public registry.
• Pricing TBD. Salesforce has not announced pricing for the hosted MCP servers. Any commercial case for MCP-based integrations should explicitly note this uncertainty.

The Future of MCP in Salesforce

The roadmap signals that MCP will become progressively more central to the Salesforce agentic platform. Key announced directions include:

• Custom MCP servers on Salesforce Platform. Salesforce has confirmed that customers and partners will be able to build and package custom MCP servers on the Salesforce Platform for standard and custom functionality. This will unlock the ability to expose proprietary business logic and custom objects as MCP tools without requiring external hosting infrastructure.
• AgentExchange marketplace for certified MCP servers. AgentExchange — Salesforce's marketplace for agent assets — is positioned as the distribution channel for certified MCP servers. Expect a curated catalogue of third-party MCP servers that have been vetted for security and compatibility with Salesforce's governance model.
• Broader API surface exposure. The current hosted MCP servers cover CRM and Commerce APIs. The roadmap points toward broader exposure — more Salesforce clouds and more API surface becoming MCP-accessible over successive releases.
• Multi-agent orchestration. MCP's bidirectional communication model — including the ability for servers to request sampling from clients — positions it as a candidate communication layer for multi-agent architectures, where specialised agents collaborate on tasks that exceed the capability of any single agent.
• Industry-specific MCP servers. Given Salesforce's investment in industry clouds (Financial Services Cloud, Health Cloud, Public Sector Solutions, Education Cloud), industry-specific MCP servers with domain-appropriate tool definitions and pre-built compliance controls are a logical extension of the current platform-level work.

MCP is still early. The protocol is maturing, the Salesforce implementation is in Beta, and the enterprise security playbook is being written in real time. But the architecture is sound, the governance model is grounded in Salesforce's existing security stack, and the direction is clear: AI agents that connect to business data and take action in the real world will do so through standardised protocols like MCP. The organisations that invest in understanding and designing for this pattern now will have a meaningful head start when general availability arrives.

---