Salesforce MCP: the five ways to connect an AI client to Salesforce

By Giorgio Bonan. Updated October 21, 2026, published October 21, 2026.

Salesforce MCP is the way AI clients such as Claude, ChatGPT or Slack read and act on Salesforce data through the Model Context Protocol. Since April 2026, Salesforce hosts MCP servers for every Enterprise Edition org and above, and every call runs with the signed-in user's permissions.

There is more than one route, though, and they differ on who hosts the server, who holds the credentials and what you pay.

What MCP does, in one paragraph

The Model Context Protocol is an open standard for connecting AI applications to outside systems. An MCP server lists tools (query records, update an opportunity, run a flow) and an MCP client, the AI application, decides when to call them. For Salesforce, the server is the gatekeeper: it decides which operations exist and checks permissions before anything happens in the org.

The five routes into Salesforce

The first two are the official, supported path for production. The DX server is a developer tool. The last two put someone else's code between the AI client and your CRM, which is a security review in itself.

The hosted servers in practice

Salesforce's developer blog gives the shortest path, which it says takes under 30 minutes:

1. Enable a server in Setup, API Catalog, MCP Servers.
2. Create an External Client App with the mcp_api and refresh_token scopes. Connected Apps are not supported for MCP clients.
3. Connect your client. Postman for testing, then Claude, ChatGPT or a similar client for daily use.

Salesforce suggests starting with the platform/sobject-reads server in a sandbox: it is read-only, so nothing can be changed by mistake. From there you can choose a standard server or build the exact tool set your org needs. A separate Data 360 MCP server covers customer data in Data 360.

The Headless 360 server

The platform/headless-360 server takes a different approach. Instead of one tool per feature, it exposes four tools and a growing library of operations behind them:

At beta launch, most of its operations were Setup tasks for admins: managing users and permission sets, Apex triggers, platform events, named credentials. It is the server the Salesforce in Claude plugin is built on, and the core of what Salesforce first called Headless 360.

One request, end to end

What happens when a seller asks Claude "which of my deals closing this month have had no activity for two weeks?" through a hosted MCP server:

1. The client picks a tool. Claude decides that the question needs a query on opportunities and calls the read tool exposed by the server.
2. The server authenticates the user. The call carries the seller's OAuth token, issued through the External Client App.
3. Salesforce applies permissions. The query runs as the seller: only the opportunities they can see are returned, with only the fields they can read.
4. The API call is counted. It draws on the org's daily API allocation.
5. The client composes the answer. Claude reads the records and writes the reply. That reasoning is billed by Anthropic, not Salesforce.
6. Nothing is written unless the seller asks for a change and approves it, in which case a second, write tool is called and logged under the seller's name.

The answer is only as good as the Last Activity Date and Close Date fields it reads.

Permissions and audit

Every hosted MCP transaction runs as the authenticated user. Object permissions, field-level security, sharing rules, profile permissions and permission sets all apply, and the audit trail attributes each action to that user. If someone cannot edit an opportunity in Salesforce, their AI client cannot edit it through MCP either.

Two practices Salesforce recommends, and that are worth turning into rules:

• Ask before writing. Configure the AI client to require approval before any tool that changes configuration, alters or deletes data.
• Sandbox first. Admins and developers carry broad permissions; their first runs belong in a sandbox or a Developer org.

What MCP calls cost

Today, MCP calls are API calls. They count against the org's daily API allocation, which Salesforce pools across the whole org rather than per user. The published allocation is 100,000 calls plus a number per license: 1,000 per Enterprise license and 5,000 per Unlimited license, per 24 hours, plus any API add-ons you buy.

Worked example. An Enterprise org with 40 licenses has 100,000 + 40 x 1,000 = 140,000 API calls per 24 hours, shared by every integration. If 20 sellers each run a morning brief that triggers 150 MCP calls, that is 3,000 calls, about 2 % of the allocation. A nightly integration that already uses 120,000 calls a day changes the picture: the same briefs would push the org to the edge, and the limit applies to everyone at once.

The second meter is coming. Salesforce plans to register agents and bill each successful call from a registered agent as a Headless Platform Interaction in Flex Credits, targeted for November 2026, with rates still to be announced and 30 days' notice before metering starts. AI usage on the client side (Claude, ChatGPT) is billed separately by the AI vendor, which is why Claudeforce has no single price.

Troubleshooting the first connection

A security review in ten questions

1. Which hosted servers are enabled, and is each one needed?
2. Are write tools enabled, and on which servers?
3. Which External Client Apps hold the mcp_api scope, and who owns each one?
4. Do clients require human approval before write tools run?
5. Which users have broad permissions (admins, integration users), and do they use MCP clients?
6. Is there an integration user acting on behalf of several people (for example in Slack), and is that acceptable for audit?
7. Where are refresh tokens stored on the client side, and who can revoke them?
8. Who reviews API usage weekly?
9. Is every new agent registered once agent registration opens?
10. Has every write scenario been tested in a sandbox first?

Glossary

Sandbox first, in practice

Create the External Client App in a sandbox, enable only the read-only platform/sobject-reads server, and connect one client. Ask it ten questions your sellers would ask and compare each answer with a report. Only then enable a write tool, with approval required, and repeat. The whole exercise takes an afternoon and catches most permission surprises before production.

When MCP is the wrong tool

• Bulk data movement. Loading or syncing thousands of records is the job of the Bulk API or an ETL tool, not of an AI client calling tools one by one.
• Scheduled reporting. A report that must run every morning for every manager is better as a scheduled report or a dedicated job than as a prompt someone remembers to send.
• Strict, repeatable rules. If the answer must be the same every time (for example, "deals with no activity for 14 days"), a deterministic query is cheaper and more reliable than a model deciding how to query.

Choosing a route

• You want sellers to use Claude or ChatGPT on Salesforce data: hosted standard servers, read-only first.
• You want an agent to perform many kinds of tasks: the Headless 360 server, in a sandbox, while it is in beta.
• You are a developer working on metadata: the DX MCP server.
• You are below Enterprise Edition: the hosted servers are not available; a third-party host or a community server is possible if your org has API access, after a security review.

Whatever the route, the AI reads your fields as they are. An opportunity marked Commit with no activity for 90 days will be described as a Commit deal. MCP gives agents access to your pipeline; it does not make the pipeline true.