Model Context Protocol (MCP) for Salesforce: The 2026 Complete Guide

Every Salesforce org will be talked to by an AI agent in 2026. Some of those agents live inside Salesforce (Agentforce). Others - Claude Desktop, Cursor, ChatGPT, custom agents, Slackbot - live outside it. The question that quietly broke 2024 was: how do all those agents call Salesforce without each one needing a custom integration?

The answer is Model Context Protocol - MCP - an open standard that has become, in less than 18 months, the default way AI tools talk to systems like Salesforce. If REST is the API for humans-writing-code, MCP is the API for agents-deciding-what-to-do. This guide is the practical, opinionated walkthrough: what MCP is, how Salesforce implements it, what you can do with it today, and where it changes the integration patterns you've been using for a decade.

What MCP actually is

Model Context Protocol is an open specification, originally released by Anthropic in November 2024 and now maintained as a multi-vendor standard. It defines a small JSON-RPC-based wire protocol that lets an AI application (the "host") discover and call tools, fetch resources, and use prompt templates exposed by external systems (the "servers").

The shorthand that has stuck is "USB-C for AI." Before USB-C, every device had its own connector. Before MCP, every AI tool needed bespoke plumbing for every system it wanted to use - Salesforce, Jira, GitHub, your internal pricing service. MCP standardizes the connector. A Salesforce MCP Server you stand up once can be called by Claude, by Cursor, by Agentforce, by Slackbot, by a custom agent your team writes - without changing the server.

The protocol itself is unglamorous on purpose. It uses JSON-RPC 2.0 over either stdio (for local servers) or HTTP with Server-Sent Events (for remote ones). It defines a handful of message types: initialize, tools/list, tools/call, resources/list, resources/read, prompts/list, prompts/get. That's most of it. The unglamorous shape is the point - it's small enough that any LLM can reason about it, and any vendor can implement it.

Why "context" is in the name

The name throws people. MCP isn't only about calling tools - it's about giving a model the context it needs to act intelligently. Three primitives:

• Tools - functions the agent can call (e.g., "create a Case", "run this SOQL query").
• Resources - read-only data the agent can pull into its context window (e.g., a record, a dashboard, a doc).
• Prompts - reusable prompt templates the host can offer the user (e.g., "Summarize my pipeline").

A well-designed MCP Server exposes all three. A Salesforce MCP Server might expose query_records as a tool, account_record as a resource template, and weekly_pipeline_review as a prompt.

Why MCP matters for Salesforce specifically

To understand why Salesforce committed to MCP early and deeply, look at what an Agentforce agent actually does. It plans a sequence of tool calls. Tools come from somewhere. Pre-MCP, every external tool you wanted to give an agent had to be wrapped: as an Apex callout, an External Service, a Flow with an HTTP action, a custom prompt template. Internal tools were fine - Apex classes, Flow invocations, SOQL queries are first-class citizens. External tools were each a small project.

Worse, the reverse problem was equally bad. An agent running in Claude Desktop or Cursor had no clean path into Salesforce. Developers wired up OAuth, called REST endpoints, parsed responses, and hand-rolled a tool definition for whichever LLM they were using. Each combination - (any external agent) x (any Salesforce capability) - was a custom build.

MCP collapses both directions of that matrix. Salesforce ships a server; any MCP-compatible host can call it. You ship a server for your internal pricing service; Agentforce can call it. The integration becomes O(N+M) instead of O(N*M).

The 2025-2026 timeline

• November 2024 - Anthropic releases MCP spec and reference servers.
• June 2025 - Salesforce announces MCP support across the platform: Agentforce as MCP client, an OSS MCP Server SDK for Salesforce, and a public roadmap for hosted servers.
• Late 2025 - Slackbot becomes an MCP client, letting Slack messages drive cross-system MCP tool calls.
• April 2026 - Salesforce-Hosted MCP Servers go GA and become free in Developer Edition, bundled alongside Agentforce Vibes and Claude in the standard developer org.

That last milestone is the one that changes the developer experience. A fresh Developer Edition org now ships with a working MCP endpoint you can point Claude Desktop at in five minutes.

How MCP works under the hood

There are three roles, and conflating them is the most common source of confusion.

A typical session looks like this:

1. The host launches and loads its configured servers.
2. Each client sends initialize, negotiating protocol version and capabilities.
3. The client calls tools/list and resources/list, learning what the server can do.
4. The user types a request. The host packs the available tools into the LLM's context.
5. The LLM decides to call a tool. The host routes that call through the MCP client to the server.
6. The server executes (a SOQL query, a record update, a Flow invocation), returns a JSON result.
7. The host feeds the result back into the LLM, which either calls another tool or composes a response.

The wire format, in one example

A tools/call request to query Salesforce records looks roughly like this:

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "query_records",
    "arguments": {
      "soql": "SELECT Id, Name, Amount FROM Opportunity WHERE StageName = 'Closed Won' AND CloseDate = THIS_QUARTER"
    }
  }
}

The server runs the query against the authenticated org and returns rows in the response. The LLM never sees raw OAuth tokens - the host manages auth, the server enforces scope, and the model only sees the structured result.

Stdio vs HTTP

Local MCP Servers run as subprocesses and talk over stdio - this is how Claude Desktop loads filesystem and Git servers on your laptop. Remote servers like the Salesforce-Hosted MCP Server use HTTP with Server-Sent Events for streaming responses. As an architect, prefer remote whenever the data lives somewhere centralized; stdio is for local-only tools.

Salesforce's MCP implementation

Salesforce's MCP story has three pieces: hosted servers, Agentforce as a client, and the OSS SDK for custom servers.

Salesforce-Hosted MCP Servers

These are managed MCP endpoints Salesforce runs against your org. As of April 2026 they are free in Developer Edition, with paid metered tiers for production orgs. The hosted servers expose a curated, governance-friendly tool set rather than the entire API surface - more on the specific tools below.

The hosted approach matters because it solves the operational problem most teams underestimate: an MCP Server that talks to Salesforce needs OAuth, Named Credentials-style secret handling, audit logging, and rate-limit awareness. Salesforce running it for you means you don't reimplement those, and the Einstein Trust Layer sits in front of everything by default.

Agentforce as MCP client

Agentforce is now an MCP client. That means an Agentforce agent can have, alongside its Apex actions and Flow actions, an MCP-tool action that calls any MCP server you point it at - your own custom server, a third-party server (GitHub, Notion, Jira), or another org's hosted server.

This is a quietly enormous change. Before, exposing your internal pricing API to an Agentforce agent meant writing an Apex External Service definition, generating an OpenAPI spec, registering it as an action, and wiring the schema. Now you stand up an MCP Server (or use one off the shelf) and add it to the agent. The Atlas Reasoning Engine treats MCP tools the same way it treats native ones.

Slackbot as MCP client

In late 2025, Slackbot became an MCP client. Send Slackbot a message in your workspace, and it can call any MCP server your admin has connected. For Salesforce shops on Slack, this means a single sentence in #sales-ops can trigger a Salesforce MCP call, a Jira MCP call, and a Confluence MCP call, with the response composed back into the channel. It is the closest thing the Salesforce ecosystem has to a universal command line.

The OSS SDK

Salesforce ships an open-source MCP Server SDK for Salesforce - a TypeScript and Python toolkit that wraps OAuth, JWT, REST API, SOQL, and Metadata API calls and lets you publish them as MCP tools with a few lines of code. We'll use it below.

What tools the Salesforce MCP Server exposes

The hosted server's tool catalog is curated rather than exhaustive. The design intent is "give an agent enough to be useful, not enough to be dangerous by default." You can extend it with custom tools, but the baseline is roughly this:

Two design notes worth internalizing. First, the server doesn't expose raw Metadata API deploy operations to the agent - those remain developer-only via the SF CLI. Second, every tool runs as the connected user. If your sales rep's connected app can't see a Closed Won opportunity in another region, neither can the agent on their behalf. This is why running MCP through the user's OAuth session, not a system-integration user, matters.

Building a custom MCP Server for Salesforce

The hosted server gets you 80% of common cases. The other 20% is your business logic, your internal APIs, and the org-specific knowledge no generic server can know.

When to build your own

• You want to expose a non-Salesforce internal service (pricing, inventory, fraud check) to Agentforce and to external agents in one shot.
• You have a multi-step Salesforce operation (create opportunity -> attach product configuration -> kick off CPQ flow) that you want to expose as a single semantic tool.
• You want to give agents read-only access to a curated slice of your org with stricter governance than the hosted server provides.
• You want to expose Data Cloud calculated insights or Tableau queries the hosted server doesn't cover.

A minimal server in 30 lines

Using the open-source SDK in TypeScript:

import { SalesforceMcpServer, tool } from "@salesforce/mcp-sdk";
import { z } from "zod";

const server = new SalesforceMcpServer({ name: "acme-pricing", version: "1.0.0" });

server.addTool(tool({
  name: "get_quote_for_account",
  description: "Returns the latest approved quote for a given Account Id.",
  inputSchema: z.object({ accountId: z.string() }),
  handler: async ({ accountId }, ctx) => {
    const sf = await ctx.salesforceConnection();
    const result = await sf.query(
      `SELECT Id, Name, TotalPrice FROM SBQQ__Quote__c
       WHERE SBQQ__Account__c = '${accountId}' AND SBQQ__Status__c = 'Approved'
       ORDER BY CreatedDate DESC LIMIT 1`
    );
    return result.records[0] ?? null;
  },
}));

server.start();

The SDK handles OAuth (via the JWT bearer flow against a Connected App you configure), session refresh, and the JSON-RPC protocol. Your tool function receives an authenticated ctx.salesforceConnection() and returns a plain JSON value.

Where to host it

Three reasonable options:

1. Heroku with the Salesforce add-on - lowest friction for Salesforce shops.
2. AWS Lambda + API Gateway behind a Hyperforce-friendly VPC - production-grade for regulated workloads.
3. MuleSoft Anypoint as an MCP-fronted Mule app - if you already have MuleSoft and want to wrap existing Mule APIs as MCP tools.

Whatever you choose, register the server endpoint in Setup -> MCP Servers and assign which Agentforce agents (and which Slack workspaces) can call it.

Security: what does and doesn't leave your org

Security is the conversation that derails MCP rollouts when it isn't addressed up front. Three principles to anchor on.

The Trust Layer is still the boundary

When Agentforce calls an MCP tool, the request and response still pass through the Einstein Trust Layer: PII masking, prompt defense, output toxicity scoring, and the zero-retention contract with model providers all apply. MCP doesn't bypass any of it. The Trust Layer sits between the agent's reasoning loop and the LLM provider; MCP tools execute inside that boundary.

When an external MCP host (Claude Desktop, Cursor) calls the Salesforce-Hosted MCP Server, the Trust Layer's masking applies on the way out. Field-level encryption, Salesforce Shield field audit, and standard sharing rules all apply unchanged.

OAuth scopes are the real access control

Every MCP session is authenticated as a Salesforce user via OAuth. The Connected App that fronts the MCP Server has scopes; the user has profile/permission-set permissions; the agent inherits the intersection. Treat the Connected App's scopes the same way you'd treat any high-privilege integration: principle of least privilege, IP restrictions, refresh-token rotation, and login flow auditing.

What goes to the LLM

A common misconception is that MCP "sends your data to OpenAI/Anthropic." It doesn't, by itself. The host application sends data to whichever LLM it's using - that's true with or without MCP. What MCP changes is which data the LLM sees: only the tool results the agent explicitly requests, after Trust Layer masking, scoped by the user's perms. This is dramatically less surface area than dumping records into a prompt the way pre-2024 RAG pipelines often did.

For Agentforce specifically, the LLM provider is governed by your org's model selection (Atlas-default, OpenAI, Anthropic, or your own bring-your-own-LLM via Data Cloud). MCP doesn't change that choice; it changes what the chosen model can do.

Real-world use cases

Five concrete patterns we're seeing in the field right now.

1. Developer workflow in Claude Desktop or Cursor

A developer working in Claude Desktop adds the Salesforce-Hosted MCP Server, points it at a Sandbox, and now the model can answer "what fields does the Account object have in this org?" or "show me the last five failed Apex jobs." This replaces a dozen sf CLI invocations with natural language.

2. Agentforce calling an external pricing API

A B2B agent receives "what's the volume discount for 500 seats of Pro on a 3-year term?" The Agentforce agent calls a custom MCP tool that hits the company's pricing service, returning the discount table. No Apex, no Flow - the MCP Server is the integration.

3. Slack-driven cross-system queries

A sales ops manager DMs Slackbot: "show me opportunities over $100K with no activity in 14 days, and check Jira for any open blockers tagged 'sales'." Slackbot calls the Salesforce MCP Server for the SOQL, the Jira MCP Server for the issues, and composes the answer.

4. Automated Apex test runs from any agent

A custom MCP tool exposes "run Apex tests for these classes" and returns pass/fail with coverage. A coding agent (Cursor, Claude Code, Agentforce Vibes) can run tests as part of a feature loop without leaving its environment.

5. Customer-facing Agentforce agents with bring-your-own context

A retail agent answering "where's my order?" calls an MCP Server that wraps the company's logistics provider's API. The same MCP Server is reused by the internal customer-service agent, by the chatbot on the marketing site, and by the Slack-based escalation tool.

6. Org-context for AI coding assistants

The Agentforce Vibes / Claude integration shipped in Developer Edition uses MCP to give Claude code-aware context: the org's metadata, the running test suite, the deployed Apex. The coding agent doesn't have to be told what your org looks like - it asks the MCP Server.

MCP vs. standard API calls

MCP doesn't replace REST, SOAP, Bulk, or Pub/Sub. It adds a new layer above them, optimized for AI consumers.

The rule of thumb: if a human or a deterministic pipeline is calling Salesforce, use the API directly. If an LLM is deciding what to call based on a user's request, use MCP. They coexist - many MCP tools are thin wrappers around REST or SOQL calls, and that's exactly the right factoring.

Getting started

Three paths depending on who you are.

If you're an admin

1. Spin up a fresh Developer Edition org (free).
2. In Setup, enable the Salesforce-Hosted MCP Server. The Connected App is created for you.
3. In Agentforce Builder, add the MCP Tools action group to an agent. You'll see the curated tool catalog.
4. Test in the Agent Preview pane: "How many opportunities closed last quarter?"

If you're a developer

1. Install Claude Desktop (or Cursor, or any MCP host).
2. In your Developer Edition org, generate an MCP connection URL from Setup -> MCP -> Connections.
3. Paste the URL plus your OAuth token into Claude Desktop's mcp.json config.
4. Ask Claude: "describe the Opportunity object in my org." It'll call describe_object via MCP and answer.

If you're an architect

Plan for governance before rollout. Catalog which MCP Servers your org will allow (hosted, third-party, custom), define a Connected App naming convention with scoped permission sets, decide which agents can call which servers, and stand up audit dashboards on top of MCP call logs (Salesforce surfaces these in Event Monitoring).

FAQ

Is MCP a Salesforce-only standard?

No - MCP is an open, vendor-neutral spec maintained at modelcontextprotocol.io. Anthropic created it; Salesforce, OpenAI, Google, Microsoft, and dozens of others have implemented either client or server support. A Salesforce-Hosted MCP Server is callable from any compliant host.

Does MCP replace Apex and Flow?

No. Apex and Flow are still the two primary ways to express business logic on the Salesforce Platform. MCP is the protocol agents use to invoke that logic - and to invoke external services - in a standard way. Most production MCP tools are thin wrappers over Apex methods, Flows, or REST API endpoints.

How is MCP different from External Services and OpenAPI actions?

External Services let you register an OpenAPI-described REST API as Flow-callable actions. MCP is broader: it's a bidirectional protocol designed for LLM consumers, with discovery, resource fetching, and prompt templates - not just function calls. External Services remain great for deterministic Flow integrations; MCP is better when an LLM needs to choose what to call.

Is MCP available outside Developer Edition?

Yes. Developer Edition gets the hosted server free; Enterprise, Unlimited, and Performance editions pay metered MCP usage as part of their Agentforce consumption tier. Production usage requires Connected App configuration and is governed by your org's Einstein Trust Layer policies.

What to read next

• What Is Agentforce 360? The Complete 2026 Guide - how the Atlas Reasoning Engine consumes MCP tools.
• Salesforce Integration Patterns: REST vs SOAP vs Bulk vs Composite - the API layer that sits underneath most MCP tools.
• Salesforce Headless 360: The Complete 2026 Guide - the broader move toward composable, API-first Salesforce that MCP is part of.
• Term pages: Agentforce, Einstein Trust Layer, Atlas Reasoning Engine, Prompt Builder, Named Credential.