What does a Salesforce MCP server give an agent?
Access to your org through a fixed list of tools, as the person who signed in. Salesforce made its hosted MCP servers generally available on 29 April 2026 for every Enterprise Edition org and above. On 15 September, at Dreamforce, Salesforce announced AIforce, which includes Claudeforce, and Claude's connector page now lists a Salesforce MCP server as a beta. Any client that speaks the Model Context Protocol (MCP), such as Claude, ChatGPT or Cursor, can now connect.
Salesforce says every call runs with the permissions of the user who authorized the connection: object access, field-level security and sharing rules all apply. There are no service accounts and no machine-to-machine flows. Standard servers ship switched off, and their tool lists cannot be edited.
That is a better default than most integrations get. It also moves the decision to a place people skip: which servers you switch on, and for whom.
Which Salesforce MCP server should you switch on first?
The read-only one. Salesforce ships four standard SObject servers, and the choice among them is the largest permission decision in the whole setup.
The reason to be strict is a limit in the design. Salesforce's developer blog says you cannot restrict an External Client App to a specific MCP server. You control access to the tools that make up the servers, not to the servers themselves. In an IdeaExchange thread asking for per-server binding, the service's product manager explained why Salesforce did not build it: the user's profile and permission sets already govern the objects behind each server.
So the enabled list is a ceiling for every client token in the org. If you switch on sobject-mutations for one pilot, a token issued to your read-only Claude client can call it too if someone points the client at that server, limited only by the user's own permissions.
- 01Enable sobject-reads and nothing else. Let the pilot group ask questions for two weeks and log what they ask.
- 02Read the API log for the objects and fields those questions touched. That is your real read scope.
- 03Add writes as one custom tool backed by a Flow with a fixed field set, not a wider server.
- 04Leave sobject-deletes and sobject-all off. If something must be deleted, the agent creates a task for a person.
The MCP governance guide covers the general checklist. This sequence is the Salesforce-specific part.
Who acted when an agent writes?
The record says a person did. Salesforce states that all MCP actions are attributed to the named user in audit trails. If an agent updates an opportunity, the user's name is on the change, and nothing on the record separates their click from their agent's write.
The activity log is where you separate them. Salesforce logs hosted MCP traffic through Event Monitoring. In Setup, open the Event Log File Browser, filter the API Total Usage event type, and keep rows where API_CLIENT_CATEGORY is SALESFORCE_HOSTED_MCP. Those rows list the user, the objects, timestamps and status codes.
Three versions of who acted
Two limits to plan for. The log files arrive as daily CSVs unless you pull them programmatically, so plan for next-day review, not live. And the log records the API call, not the prompt behind it, so the reasoning behind a write lives in the client. Salesforce's docs list user, objects, time, status code and client IP. They do not say the log names the client app, so check a sandbox export before you promise your approver that it does.
Salesforce recommends a dedicated External Client App for each MCP client: one for Claude, one for ChatGPT, one for Cursor. That is the cheapest way to answer "which client did this" and to switch off one client without cutting the others.
How do you stop an agent?
Decide the levers before go-live, and name who pulls each one. Salesforce gives you four, at different speeds and different reach.
Salesforce also recommends shortening the refresh token lifetime to 30 days or less and turning on refresh token rotation, since the setup guide says refresh tokens stay valid indefinitely by default. The scope matters too. Grant mcp_api and refresh_token, not the broad api scope, which opens the REST, Tooling and Metadata APIs. If an app also holds api, its tokens are no longer limited to MCP.
Run the drill once in a sandbox. Time it. The person on call out of hours has to know where the OAuth Usage page lives, and whether they hold the permission to use it.
What does the setup leave to you?
The approvals, the log review and anything that spans vendors. Salesforce gives you per-user identity, servers that ship switched off and a scoped OAuth grant. It does not decide who signs off on a new client, who reads the logs, or how a write gets caught before it reaches a record.
Who owns what in a hosted MCP rollout
- 01Sign-inAuthorization code flow with PKCE. A named user signs in through a browser.Salesforce
- 02Scopemcp_api on an External Client App, one app per client.Salesforce
- 03PermissionsObject access, field-level security and sharing rules run on every tool call.Salesforce
- 04Log reviewSomeone reads the daily API Total Usage rows for MCP traffic and follows up.Your team
- 05Write gateA person approves or a Flow fixes the fields before a write reaches a record.Your team
Salesforce says as much itself. Its launch post notes that enterprises using MCP across several vendors will want an MCP gateway for central access control, and it names MuleSoft AI Gateway. Our Flex Gateway page and the control plane show where that layer sits. Our AI governance service covers how we put a named reviewer on it.
Before you connect Claude to production, get four answers in writing: which servers are active and why, who holds the stop levers, who reads the logs and how often, and which writes need a person.
