Salesforce MCP Server: What It Is and What It Can Answer

Your Friday forecast call runs on questions Salesforce can't answer quickly: which committed deals went quiet, who on the buying side replied this month, what changed since the last review. A Salesforce MCP server lets an assistant like Claude, ChatGPT, or Copilot put those questions to your org in plain language and act on the records the asker is allowed to see. It answers from whatever's in the org. That last clause decides whether the answers are worth having, and it's where this guide spends most of its time.

What Is a Salesforce MCP Server?

MCP stands for Model Context Protocol, an open-source standard for connecting AI applications to external systems. An MCP server is the piece that sits in front of one system and publishes a catalog of tools an assistant can call. For Salesforce, those tools look like this: find an account, query opportunities, update a field, run a flow.

So a Salesforce MCP server is that catalog, pointed at your org. Your assistant sends a question, the server turns it into API calls, and the results come back as context the assistant can reason over and report on. Your CRM doesn't change. What's new is who can question it, and from where.

Today you'll find 3 kinds.

• Salesforce Hosted MCP Servers. Salesforce's own, running on its infrastructure. They entered beta on October 9, 2025 and reached general availability on April 29, 2026, for Enterprise Edition orgs and above.
• Salesforce DX MCP Server. An open-source server for developers and admins. It runs SOQL, deploys and retrieves metadata, and runs Apex tests from editors like VS Code, Claude Code, and Cursor.
• Community and custom servers. Open-source projects on GitHub, or one your own team writes, typically wrapping the Salesforce API with query, create, update, and delete tools.

Your RevOps and security teams will get asked about the first. Developers own the second. Build-vs-buy conversations start with the third.

How Does a Salesforce MCP Server Work?

3 parts move. Your client is the assistant the team already types into. In front of Salesforce sits the server, a catalog of tools. Between them sits authentication, and that's where governance lives or dies.

Salesforce's hosted servers use per-user OAuth 2.0, so every tool call runs as the person asking. Field-level security, object permissions, and sharing rules apply to every call. A manager who asks about accounts outside their territory gets what Salesforce gives them in the UI: nothing.

Salesforce also scopes the hosted catalog. SObject Reads is query only. SObject Mutations creates and updates but can't delete. SObject All does everything, and separate servers cover Data 360 queries and Tableau Next analytics.

Start with Reads. Widen the scope after a month of logs shows what people actually ask.

Community servers work differently. Many authenticate with one set of credentials, a username and password plus security token, or an OAuth client ID and secret. Every question then runs with that single user's access, whoever typed it.

That works in a developer sandbox. It's a liability in an org whose sharing rules exist for a reason.

What Can You Ask It?

Anything the fields can support. In practice the questions fall into 4 groups.

• Lookup. "Show me the open opportunities on Acme over $200K." Rows come back from a single query.
• Roll-up. "How much commit pipeline closes this month by region?" Named queries and Data 360 SQL handle the aggregation.
• Change. "Move the close date on Acme Expansion to October 15 and add a note." Mutation tools write the fields, under the same permissions.
• Process. "Start the renewal flow for accounts with contracts ending in Q4." Flows and Apex invocable actions are exposed as tools.

Every answer is an honest reading of the record: stage, amount, close date, last activity date, the notes someone typed. For a RevOps leader that alone removes a loop. A question that used to mean a day of report filters now takes one sentence, inside a chat window already open.

What it can't do is tell you whether the record is true.

What a Salesforce MCP Server Can't Answer

It can't see what never reached Salesforce. Your champion opened the proposal and went silent for 11 days. Legal joined an email thread and asked about data residency. Procurement's calendar shows nothing for 3 weeks.

None of that is a field, so none of it is in the answer. Fields hold what a rep logged, when they logged it, in the words they chose. Salesforce's own State of Data and Analytics research found that 84% of data and analytics leaders agree AI's outputs are only as good as its data inputs. An assistant connected to a partial record gives fluent, confident answers about a partial record.

You can measure the gap on your own org in an afternoon. Pick 10 deals that closed lost last quarter. Ask the server for the last activity on each, then check the reps' calendars and inboxes for the same weeks. A Salesforce MCP server inherits that distance on day one.

Closing it is a data problem, not a protocol problem. MCP carries whatever you feed it. Our library page on why CRM data accuracy fails covers the structural reasons the fields stay incomplete.

Build, Buy, or Both: Where the Activity Layer Comes From

Most teams end up running two connections: Salesforce's hosted server for reading and writing records, and a second MCP source for the activity that never becomes a record. That's the build-vs-buy decision.

Building it means capturing every email, meeting, and call across the team, then matching each one to the right account and opportunity, including contacts nobody created in Salesforce. That matching has to stay current as people change roles. The result then gets exposed as MCP tools with the same per-user permissions. Our post on why an LLM is not your system of record walks through what that layer has to hold.

Buying it means connecting an activity layer that already exists. Backstory MCP is one: it gives Claude, ChatGPT, Gemini, Copilot, or a custom agent the matched history behind each deal, every email, meeting, call, and transcript, alongside the CRM fields. It reaches only the accounts, opportunities, and activities you can already view in Backstory, and connecting through MCP grants no additional permissions. Reps don't change anything, because the capture is automatic.

Neither route replaces the Salesforce server. Records don't move; they still live in Salesforce. Only the evidence differs: what the assistant gets to reason over when you ask whether a deal is real.

How to Evaluate a Salesforce MCP Server

6 checks, in the order they cost you later.

1. Whose permissions run the query. Per-user OAuth with field-level security and sharing rules enforced on every call, or one integration user for everyone. Ask to see the token flow, not the slide.
2. What the server is allowed to change. Read-only first. A delete tool in the hands of a general-purpose assistant is a change-control incident waiting on a typo.
3. What sits behind the tools. Fields only, or fields plus the emails, meetings, and calls that explain them. Run the 10-deal test above before you decide.
4. Whether answers show their evidence. "At risk" should arrive with the stakeholder who went dark and the date. A score without a receipt can't be defended on a forecast call.
5. Where your team will ask. It has to be reachable from the client people already use, whether that's Slack, Claude, ChatGPT, or Copilot. A separate chat window is another tool to check, and another tool nobody opens.
6. What the audit trail records. Every call as the authenticated user, in a log your security team can read. Salesforce's hosted servers do this by default. Hold anything you build to the same bar.

How to Get Started

1. Enable the read-only hosted server (SObject Reads) in a sandbox and connect one client, following Salesforce's getting-started guide.
2. Write down the 5 questions your forecast call always asks. Run them. Save the answers.
3. Compare each answer with what happened on the deal, using inboxes and calendars, and mark the misses.
4. Connect the activity layer and run the same 5 questions. Setup for Claude, ChatGPT, Copilot, Gemini, and n8n takes a few minutes per client; you sign in with your Backstory credentials and won't need a CRM license to authenticate.
5. Widen the scope only after step 3 stops producing misses.

Red Hat, a Backstory customer, reports a 50%+ increase in win rates on deals with 70%+ MEDDPICC completion, with 2,000 sellers submitting forecasts in one unified view. Those are answers with the full history attached, delivered where the sellers already worked.

Salesforce MCP Server FAQ

Is a Salesforce MCP Server the Same as Agentforce?

No. MCP is the open connection standard. Agentforce is Salesforce's platform for building and running agents. Salesforce describes the hosted MCP servers as integrating with Agentforce and MuleSoft, so the tools you expose over MCP aren't tied to a single assistant.

Which Salesforce Edition Do You Need?

Salesforce's GA announcement lists hosted servers for Enterprise Edition orgs and above. Community and custom servers need API access plus a user with the right object and field permissions, so check your edition's API allowance before a pilot.

Does a Salesforce MCP Server Change How Reps Work?

No. It's a question-and-answer path for the people who ask. Reps keep working in Salesforce, Slack, and their inbox. Only one thing moves: how fast a manager gets an answer without first asking a rep to update a field.

MCP is settled. What your assistant can see is the open question. See what a deal looks like with the full history attached, inside Claude, ChatGPT, or Copilot: take the Backstory MCP tour.