Salesforce MCP Server: Tools, Permissions, and How to Connect It Safely

What the Salesforce MCP server is

The Salesforce MCP server turns your CRM into callable tools. Model Context Protocol is the open standard that lets an AI agent discover and invoke tools on an external system; Salesforce’s implementation exposes standard and custom sObjects through it.

What makes it different from most remote MCP servers is where it runs: Salesforce serves its MCP servers from inside your org, activated through the TrueFoundry Salesforce managed package — no third-party host in the middle, no OAuth app to stand up.

What you activate determines what agents can reach:

Those two map onto the only decision that matters: does this agent need to change records, or just read them. The Salesforce Servers tab in Setup lists what your edition can activate. [VERIFY] Whether variants beyond these two appear there is not documented.

Within either server, the surface is your data model. The docs describe tools by capability and object type rather than publishing fixed function names, so the Tools tab on the server detail page is the real inventory for your org.

What agents actually do with it

The useful workflows chain reads, and occasionally write:

• Pipeline review. Query open opportunities above a threshold, pull the related accounts and contacts, cross-reference last activity date, flag the deals that have gone quiet.
• Pre-call research. Read the account, its open cases, its closed-won history, and whatever custom objects carry product usage, then write a one-page brief.
• Case triage. Cluster open cases by product area and severity, surface the ones breaching response targets.
• Data hygiene. Find duplicate or incomplete records and normalize fields — the only one here that needs sobject-all.

Three of those four are pure reads, and that’s the pattern. Most of what teams want from a CRM MCP server is reading. So read-versus-write isn’t an abstract principle here — it’s a concrete question answered at activation time, and most agents belong on the read-only side.

Why connecting it raw breaks at team scale

One RevOps analyst wiring Salesforce into Claude Desktop is fine. The same integration across thirty people in sales, support, and finance is not.

An agent with write access can mutate the numbers the board sees. Opportunity amounts, close dates, and stages roll up into forecast; account fields feed territory and ARR reporting. An agent that “cleans up” a stage or deletes a suspected duplicate hasn’t leaked anything — it has corrupted the system of record finance closes the quarter against, and overwritten history isn’t a commit you revert. Prompt injection compounds it: an instruction planted in a case description reaches a triage agent holding the same write tools as a data-hygiene one.

An agent with read access can pull the entire pipeline into a model context. One broad query against Opportunity returns every open deal, its amount, and its owner — and on a shared service account that query isn’t bounded by anyone’s sharing rules. Your forecast becomes a prompt.

Shared credentials erase Salesforce’s own permission model. Profiles, permission sets, field-level security, sharing rules — teams spend years tuning them. Then an integration authenticates with one admin-level credential, every request inherits admin, and that work is gone.

No attribution when something changes. Field history tells you a record changed and which user changed it — not that an agent changed it on a prompt from a Slack thread.

None of this argues against connecting Salesforce. It argues for a control plane in front of it — which is what an MCP gateway is for.

Want to see this end to end?

Spin up a TrueFoundry account, activate the read-only Salesforce server, and hand your team a governed CRM agent in an afternoon.

Get started free

Before you start: what the Salesforce side requires

Because the server lives in your org, this integration has real prerequisites, unlike most managed MCPs.

• A TrueFoundry account with permission to add MCP servers.
• Salesforce Administrator access — you’re installing a package and changing Setup.
• An org edition with API access enabled: Developer, Enterprise, or Professional Edition with API access turned on.

Budget about ten minutes, most of it waiting on the install and activation.

Connecting the Salesforce MCP server through TrueFoundry

TrueFoundry provisions Salesforce as a TrueFoundry Managed MCP: the platform owns the server URL, outbound auth, scopes, and credentials, and keeps them current as Salesforce changes them:

Because the server is yours, Salesforce adds three org-side steps in front of that.

Step 1 — Install the TrueFoundry Salesforce MCP package. Log into your org as an Administrator, then open the installation link in the same browser session:

https://login.salesforce.com/packaging/installPackage.apexp?p0=04ta7000001FUejAAG

On the install screen choose Install for All Users, click Install, and wait for the success confirmation.

Step 2 — Enable the MCP Service. In Setup, search User Interface in Quick Find, find Enable MCP Service, turn it on, and Save.

Step 3 — Activate the MCP server. Still in Setup, search MCP Servers and open the Salesforce Servers tab. Find the server you want — sobject-all for full read/write, sobject-reads for read-only — and click Activate; it can take up to two minutes. Read the next section before you pick.

Step 4 — Connect in TrueFoundry. Go to MCP Servers, find Salesforce MCP, and click Connect. You’re redirected to a Salesforce login and consent screen: log in, review the requested permissions, and click Allow.

Step 5 — Verify. The server should read Connected and the Tools tab should list its tools. Click Try on any tool, or run something like “list all accounts”, to confirm the round trip.

Note what you did not do: no External Client App, no Connected App, no Client ID or Secret, no OAuth scopes, no callback URL.

How authentication actually works

TrueFoundry separates inbound authentication — how a client proves itself to the gateway — from outbound, how the gateway proves itself to Salesforce.

Inbound — clients authenticate to the AI Gateway with one of:

One caveat matters more here than on most servers: a Virtual Account token gives every request identical access, so it can’t support per-user CRM visibility. Use a PAT or the IDE OAuth flow inbound.

Outbound — the OAuth2 Authorization Code flow. Each user authorizes their own Salesforce account; TrueFoundry manages consent, token storage, and refresh. As a managed MCP, the redirect URI is always TrueFoundry’s centrally managed callback:

https://auth.truefoundry.com/mcp/oauth2/callback

This is what makes the Salesforce story strong. Because the outbound identity is the individual user, every action runs as that authenticated user and respects your org’s CRUD permissions, field-level security, and sharing rules. The rep whose profile can’t see Finance-only fields? Their agent can’t either. The support agent limited to one region? Their agent sees one region.

Your permission model isn’t bypassed, duplicated, or approximated at the gateway — it is the enforcement layer, because Salesforce evaluates each call as a real user. Users authenticate twice, once to the gateway and once to Salesforce, and that’s what makes per-user attribution possible.

Choosing read-only at the source

Most MCP servers give you one place to restrict capability: the gateway. Salesforce gives you two, and the upstream one is stronger.

Activating sobject-reads instead of sobject-all means the write and delete tools do not exist on the server your gateway talks to. Not disabled, not gated — absent. No toggle to misconfigure later, no collaborator who can flip it back, no upstream release that quietly adds a write tool.

• Default to sobject-reads. Pipeline reporting, account briefs, case triage, forecast summaries, research agents — none of them write.
• Activate sobject-all only when a workflow demands writes, and pair it with the toggles and approval policies below.

If you’ve already activated sobject-all, disabling the write and delete tools on the Tools tab gets you the same behavior — it’s just a control you have to keep intact.

Scoping tools before you ship

Once connected, the Tools tab lists everything the active server exposes.

Per-tool toggles. Turn a tool off and it’s omitted from tools/list entirely — clients never see it and it cannot be invoked. This isn’t prompt-layer filtering: an agent that cannot see a delete tool cannot be argued into calling one, whatever a poisoned case description says.

Enable new tools by default. Left on, new upstream tools appear automatically. Turned off, only tools you’ve explicitly enabled are available and anything new stays hidden until you approve it. For a system of record, off is the right default.

Bulk Action. Switches every row to checkboxes with Select all, so you can flip a large set at once and Save.

Click the pencil on any tool to change how it’s presented to the model:

The Description override (up to 20,000 characters) steers tool selection when upstream wording is ambiguous. MCP Tool Annotations mark a tool Read-only or Destructive, setting readOnlyHint or destructiveHint — and marking the write tools Destructive is what lets the approval policies below gate a whole class of operations at once.

Who can do what: collaborator roles

Access control attaches to users, teams, or virtual accounts on two dimensions: which servers an identity can reach, and which tools it can invoke.

For a CRM the natural split is RevOps as Manager, sales and support as User, and a sales-ops lead as Approver on the write path — the same MCP access control model as every other server in the registry.

Ready to scope your first server?

Activate sobject-reads, add your team as Users, and ship a read-only CRM agent today.

Start free on TrueFoundry

Human approval for write tools

Disabling writes is the blunt instrument, and for most Salesforce agents it’s correct. But some workflows legitimately write — logging activity, advancing a stage, creating a task — and you want that happening with a human watching.

When a gated tool is called, the call is held rather than executed, an approval request is created, and approvers are notified. After a human approves, calls succeed for a configurable window, then fresh approval is required. Create a policy under AI Gateway → Policies → MCP Tool Approval (marked Beta in the console):

Each policy names the servers it gates and picks an approval scope:

This is where the annotations pay off: mark the write operations Destructive once and gate the class with approval_scope: destructive. When scopes overlap the most specific wins — named > destructive > all.

Validity is either Once (a single execution) or time-based, a duration in minutes. When policies conflict the most restrictive wins: Once beats 10 minutes beats 30. For anything touching opportunity or account records, pick Once — a 30-minute grant on a write tool is 30 minutes in which an agent can loop.

Approvers are notified over Email, Slack, PagerDuty, or MS Teams, and review in the console:

Each request shows the tool, the policy, the requester, the validity window, and the actual tool arguments — so an approver can see that an agent wants to set a $400k opportunity to Closed Lost before waving it through. That visibility is the whole value of the feature on a CRM.

While pending, the caller gets a successful JSON-RPC result carrying _meta.approval_status: "pending" rather than an error, so a well-behaved agent waits and retries. Grants are scoped per requester, and a denial doesn’t permanently block anyone — the next call raises a fresh request.

Testing in the Tool Playground

Exercise the tools by hand first. On the server detail page click Try next to any tool, supply the inputs — the object type such as Account or Opportunity, plus any query filters — click Execute Tool, and read the JSON. Try is disabled for tools you’ve turned off. This catches the boring failures early: a field your profile can’t read, an object the package didn’t expose, a filter shape you guessed wrong.

Using it from your IDE

Open the How To Use tab for your tenant-specific Gateway URL and ready-to-paste snippets.

It covers Claude Code, VS Code, Claude Web, Claude Desktop, Cursor, Windsurf, Codex, and the Python and TypeScript MCP SDKs; Show API Key reveals the token if your client needs one in a header. Take the URL from this tab rather than assembling it yourself — it’s tenant-specific, and a hand-built endpoint is the most common cause of a client that connects but lists no tools.

What you get once it’s behind the gateway

Tool-level metrics. The Tool Metrics tab tracks invocation count, per-tool latency, and error rates. Across the gateway, MCP Metrics adds requests per second, latency at P50/P75/P90/P99, and failure rate by error type.

Full-request observability. Every tool call is traced with caller identity, tool name, inputs, and latency, exporting over OpenTelemetry into Grafana, Datadog, or Prometheus — the attribution layer field history alone can’t give you.

Guardrails. Hooks apply at mcp_pre_tool, before a tool is invoked, where a check can block the call outright, and at mcp_post_tool, on the response before it returns to the agent. The post-tool hook is the one that matters for CRM data — it’s where you catch a result carrying more records or more sensitive fields than should reach a model.

Low overhead. The gateway adds roughly 3–4 ms of latency and handles 350+ RPS on a single vCPU.

One registry. Once several servers are registered you can expose a curated subset of their tools behind one endpoint with a Virtual MCP Server — so a deal-desk agent gets read tools from Salesforce, a Slack tool to post the summary, and nothing else.

Revoking access

Tenant admins can wipe every stored credential on the server from the three-dot menu next to Edit:

Revoke all tokens deletes every auth override and stored OAuth token for all users and virtual accounts on that server, takes effect on the next request, and is recorded in Activity Logs. It’s irreversible, and only tenant admins see the action.

One important limit: it clears tokens at the gateway only and does not revoke the grant inside Salesforce. In an incident, deactivate the server on the Salesforce Servers tab as well — that’s the switch that removes the capability rather than the credential.

Gotchas worth knowing

Read-only is an activation choice, not just a toggle. The strongest read-only Salesforce agent is sobject-reads activated in your org, where write tools never exist. Gateway toggles on sobject-all are a good second line, but configuration drifts.

Field-level security is doing more work than you think. Because every call runs as the authenticated user, a tool that “doesn’t work” for one person and works for another usually isn’t broken — it’s FLS or a sharing rule behaving correctly.

API limits are shared. Agent tool calls draw on the same org API allocation as your nightly jobs.

Related reading

• What Is an MCP Gateway: Architecture and Use Cases — the architectural primer behind this post
• MCP Access Control: Securing AI Agents with an MCP Gateway — how tool- and server-level permissions work in practice
• MCP Authentication Explained — the inbound and outbound auth model in depth
• Virtual MCP Server Explained — bundling tools from several servers into one endpoint
• Enterprise MCP Access Control — role design for large teams

Conclusion

The Salesforce MCP server is unusually well suited to being governed properly, and unusually costly to get wrong. Well suited, because it runs in your own org and authorizes per user, so the permission model your admins already maintain becomes the agent’s. Costly, because the objects on the other side are the ones your forecast and your quarter-end close are built on.

The controls are ordered, and the first is the cheapest: activate sobject-reads unless a workflow genuinely needs to write. Then disable the tools you don’t use, put the write path behind a human with Once validity, and keep the traced call log.

Connect the Salesforce MCP server on TrueFoundry

Free to start