.png)
|
5 min de lecture
Salesforce MCP Server: Tools, Permissions, and How to Connect It Safely
Par Ashish Dubey
Published:
.png)
Conçu pour la vitesse : latence d'environ 10 ms, même en cas de charge
Une méthode incroyablement rapide pour créer, suivre et déployer vos modèles !
- Gère plus de 350 RPS sur un seul processeur virtuel, aucun réglage n'est nécessaire
- Prêt pour la production avec un support complet pour les entreprises
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.
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:
TrueFoundry Managed MCPs catalogue showing provider tiles with an Add button, where the platform supplies every URL, authentication detail, scope, and credential
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.
MCP Servers panel showing the not-connected state for an MCP server with a Connect Now button that starts the OAuth authorization flow
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.
MCP Gateway authentication and authorization flow showing inbound authentication, access control, and outbound authentication as three distinct stages
Inbound — clients authenticate to the AI Gateway with one of:
TrueFoundry AI Gateway offre une latence d'environ 3 à 4 ms, gère plus de 350 RPS sur 1 processeur virtuel, évolue horizontalement facilement et est prête pour la production, tandis que LiteLM souffre d'une latence élevée, peine à dépasser un RPS modéré, ne dispose pas d'une mise à l'échelle intégrée et convient parfaitement aux charges de travail légères ou aux prototypes.
Conçu pour la vitesse : latence d'environ 10 ms, même en cas de charge
Try now.
INSCRIVEZ-VOUS
Comment pouvez-vous empêcher les coûts de GenAI de grimper en flèche à grande échelle ?
Gartner Hype Cycle for Platform Engineering 2026
One Layer of Control for All AI
Table des matières
Gouvernez, déployez et suivez l'IA dans votre propre infrastructure
Summarize with
Découvrez-en plus
Aucun article n'a été trouvé.
.png)
.png)
Aucun article n'a été trouvé.
.png)
.webp)
.webp)
Questions fréquemment posées
What is the Salesforce MCP server?
It’s a Model Context Protocol server that exposes Salesforce CRM data — accounts, contacts, opportunities, cases, and custom objects — as tools an AI agent can call. Salesforce serves it from inside your own org: install the TrueFoundry Salesforce managed package, enable the MCP Service in Setup, and activate sobject-reads for read-only access or sobject-all for full read/write.
What tools does the Salesforce MCP server expose?
It depends which server you activate. sobject-reads exposes read tools over your sObjects; sobject-all adds create, update, and delete. Tools are parameterized by object type and query filters rather than published as a fixed list, so the Tools tab is the authoritative inventory for your org — and each tool there can be enabled, disabled, re-described, or annotated.
Is the Salesforce MCP server safe to use in an enterprise?
It’s one of the easier integrations to govern: per-user OAuth means every action runs as the authenticated user under that user’s CRUD permissions, field-level security, and sharing rules. The residual risk is the write path — activate sobject-reads where writes aren’t needed, disable write tools where they are, and gate the rest behind human approval with Once validity.
Can I deploy TrueFoundry in my own VPC or on-prem?
Yes. TrueFoundry runs in your VPC, on-prem, air-gapped, or hybrid, so prompts and responses never leave your domain even as you route across many providers.
Does TrueFoundry support MCP and AI agents generally?
Yes. It includes an MCP Gateway, an Agent Gateway, and an MCP & Agents Registry with tool-level access control. Agents on LangGraph, CrewAI, AutoGen, or a custom framework can all be governed centrally.
S'intègre-t-elle à ma pile d'observabilité existante ?
Oui. La passerelle est compatible OpenTelemetry et s'intègre à Grafana, Datadog, Prometheus, ou à votre pile technologique préférée. Elle trace chaque requête, du prompt à l'exécution de l'outil et du modèle, vous offrant ainsi une journalisation unifiée sans avoir à remplacer ce que vous utilisez déjà.
