The Model Context Protocol (MCP) is an open standard that lets an AI application connect to outside systems through one common interface. An MCP server lists what it offers, mainly tools the AI can call and resources it can read, and an assistant or agent uses them on someone's behalf. For Salesforce, MCP means an assistant such as Claude, or an Agentforce agent, can query records and run approved actions without a custom integration built for each assistant, limited to the permissions you grant.
What MCP is, in business terms
Before MCP, connecting an AI assistant to a business system meant writing an integration for that specific assistant. Connecting three assistants to five systems meant up to fifteen separate projects, each with its own authentication and maintenance. MCP replaces that with a shared contract: a system publishes an MCP server once, and any assistant that speaks the protocol can discover and use it.
The protocol names three roles. The host is the AI application a person works in, such as a desktop assistant or a coding tool. Inside the host, an MCP client holds a connection to one server. The server is the program that fronts a system like Salesforce and answers the client's requests. Servers can run locally on a user's machine or remotely as a web service, and for remote servers the specification recommends OAuth for authentication, which is the model Salesforce uses.
MCP only defines how context and actions are exchanged. It does not decide which model you use, what the AI does with the data, or what it is allowed to do; those decisions stay with the host application and the system behind the server.
What an MCP server exposes
| Building block | What it is | Salesforce example |
|---|---|---|
| Tools | Functions the AI can call to look something up or take an action | Query opportunities, search accounts, create a task, run an autolaunched Flow or an Apex action |
| Resources | Read-only context the AI can load | Object and field descriptions, so the assistant knows what fields exist before it queries |
| Prompts | Reusable instructions or templates offered by the server | A standard account-review template that tells the assistant which records to pull and how to structure the output |
Each tool carries a name, a plain-language description and a defined set of inputs. The assistant reads those descriptions and decides when to call a tool, which is why tool descriptions are part of your governance, not just developer documentation. A vague description invites the assistant to use a tool for jobs it was never meant to do. Servers can also ask the user for input or confirmation partway through a request, which is useful before an action that changes data.
Where MCP meets Salesforce today
MCP runs in both directions around Salesforce, and it is worth knowing which one a proposal describes.
- Into Salesforce: Salesforce-hosted MCP servers, generally available since April 2026 for Enterprise Edition orgs and above, let an outside assistant reach your org. Standard servers cover things like record access and metadata, and custom servers can expose your own Flows, Apex actions and named queries.
- Out of Salesforce: Salesforce describes Agentforce as an MCP client, so agents can call tools on MCP servers that other systems publish, instead of each connection being custom-built.
- Agents as tools: Salesforce documents exposing Agentforce agents and Prompt Builder templates as MCP tools, so an outside assistant can hand work to an agent you already built.
- Custom servers: your developers can build an MCP server on top of Salesforce APIs when the hosted options do not fit, at the cost of running and securing it yourself.
The hosted servers matter because Salesforce runs them, handles authentication, and applies your org's security model to every call. Salesforce also describes a central registry for approved MCP servers and a catalog of vetted ones on AgentExchange; some of that page is written as future capability, so check what is generally available in your org's current release before you plan around it.
Custom servers are not only for Salesforce. Abstrakt Marketing Group, a client, built custom MCP connectors that give staff controlled access to internal systems from Claude, alongside its Salesforce work. That is a typical reason to build one: a system without a published server, and a need to decide exactly which operations people can reach through an assistant.
Permissions and governance
With Salesforce-hosted MCP servers, each call runs as the authenticated user. Object permissions, field-level security and sharing rules apply exactly as they do in the Salesforce interface, and there is no anonymous service account. An admin creates an External Client App to handle OAuth, can limit it to pre-authorized users through a permission set, and turns on only the servers the business needs, since they start inactive.
- Start with read-only tools, and add tools that create or update records one at a time, each with a named business owner.
- Require confirmation in the assistant before any write, and log what was changed and by which user.
- Treat text inside records, such as email bodies and case descriptions, as untrusted input that could try to steer the assistant, and keep sensitive actions out of reach of workflows that read customer-written content.
- Keep an inventory of every MCP server connected to the org, which assistants use it, and which tools are enabled.
- Review connected users, tools and permission sets on the same cycle as your other access reviews.
When MCP is the right pattern
MCP is best when a person, working with an assistant, needs flexible access to Salesforce alongside other systems. It is a poor fit when the job is fixed, high-volume, or customer-facing, where established integration patterns or Agentforce do the work with more control.
| Situation | Is MCP a good fit? | Usually better |
|---|---|---|
| Leaders want to ask ad hoc questions across Salesforce and other tools from their assistant | Yes | MCP with read-only tools |
| Nightly sync of orders or invoices between Salesforce and your ERP | No | An API or MuleSoft integration with defined mappings and error handling |
| An agent answering customers on your website | Only for reaching other systems | Agentforce with subagents, actions and monitoring |
| One fixed rule, such as creating a task when a stage changes | No | A record-triggered Flow |
| An assistant needs to hand a request to an agent you already built | Yes | Expose the agent as an MCP tool |
A useful test for any proposal: if the same input should always produce the same action, build a conventional integration or Flow. If the value comes from a person asking varied questions and deciding what to do with the answers, MCP is likely the right connection. We are a Salesforce Consulting Partner since 2017 with a U.S.-based team, and we help clients scope that first connection, tighten permissions beforehand and decide which tools to switch on.
