MCP field guide / Salesforce
// mcp field guide · crm
The split here surprises people: Salesforce's official server is developer tooling with read-only SOQL record access — it can't create, update, or delete a record. The destructive CRM surface (full CRUD, bulk DML, anonymous Apex) lives in community connectors. Which one you run changes the risk entirely.
GUARD FIT · OFFICIAL DX (reads)
LOWRecord access is SOQL-only; the sharp targets are deploy_metadata, delete_org and assign_permission_set, not record CRUD.
GUARD FIT · COMMUNITY (CRUD + Apex)
STRONGBulk DML, delete_record, and apex_execute/restful (arbitrary code/API) — unbounded blast radius on a live org.
Overall fit: STRONG on the write surface (mostly the community connector); reads are weak on both.
Official — Salesforce DX MCP (@salesforce/mcp, by the Salesforce CLI team, local, pre-1.0). It's developer/DX-oriented: metadata deploy/retrieve, Apex/agent tests, code analysis, LWC scaffolding, DevOps Center. Record data access is read-only SOQL — there is no create/update/delete record tool. Riskier NON-GA org tools are gated behind --allow-non-ga-tools.12 Community — smn2gnt/MCP-Salesforce (and others, e.g. KirtiJha/salesforce-mcp-server) instead targets CRM data operations: query, get, create, update, delete records (single and bulk), plus anonymous Apex and raw REST/Tooling calls. Which community server is "most-used" is unverified.3
| Tier | Official DX | Community connector |
|---|---|---|
| read-only | run_soql_query, list_all_orgs, get_username, code-analyzer & DevOps-Center reads | run_soql_query, run_sosl_search, get_record, list_sobjects, get_object_fields |
| mutating | deploy_metadata, assign_permission_set, retrieve_metadata, run_apex_test, DevOps-Center writes | create_record, update_record, bulk_create_records, bulk_update_records, apex_execute, tooling_execute, restful |
| destructive | delete_org (NON-GA); deploy_metadata when it overwrites/deletes config | delete_record, bulk_delete_records |
The two things that make the community connector sharp: (1) apex_execute runs arbitrary anonymous Apex and restful issues arbitrary REST calls — their blast radius is whatever the org's API allows, so a single call can do far more than any named CRUD tool. (2) bulk_delete_records/bulk_update_records fan a mistake across many records. There's no verified dedicated flow-execution tool on either server — don't assume a run_flow exists.
Record deletes are soft — but not safely so. delete_record/bulk_delete_records send records to the Recycle Bin, recoverable for ~15 days by default (admin-extendable to 30). The honest caveat: that's recoverable within a window, not guaranteed — the bin auto-purges the oldest records when its storage cap is hit even before 15 days, bulk deletes can exceed bin capacity, and hard-delete paths bypass it entirely.4
Metadata and org deletes are not protected. deploy_metadata that overwrites or removes config, and delete_org, are not Recycle Bin covered — Salesforce is explicit that customizations "cannot be recovered … must be recreated from scratch." Those are truly irreversible without external version control/backup.
Pro-code dev in an agentic IDE. "Deploy my metadata," run Apex tests, scaffold LWC, resolve a DevOps Center conflict — the official DX server's core purpose.
NL CRM data ops (community). "Find open opportunities over $50k and update stage," or bulk-clean duplicate leads.
Reporting / triage. SOQL/SOSL to pull cases or pipeline into a chat context — read-only, safe with just the query tool.
Reads → weak. run_soql_query, get_record, listing — no state change. (One caveat: SOQL can exfiltrate PII at scale — a data-egress/policy concern, not a mutation gate.)
Writes → strong. All of it: record create/update/bulk, deploy_metadata, assign_permission_set (a privilege escalation!), and especially apex_execute/tooling_execute/restful (arbitrary code/API — unbounded). Production-CRM and prod-org config writes are the textbook human-in-the-loop case.
Deletes are the compensation-≠-reversal case. A guard can honestly say record deletes are "recoverable until the Recycle Bin purges — not guaranteed," but deploy_metadata (destructive overwrite) and delete_org must be flagged as irreversible before commit — no undo, recreate-from-scratch only. That's compensation is not undo, with a time-boxed asterisk for records and a hard stop for metadata.
ChronoMCP passes reads through and holds bulk DML, apex_execute, metadata deploys and permission changes for a human — with honest recoverability labels.
Profiles describe third-party software from its public sources; ChronoMCP is not affiliated with Salesforce, and the community connectors are independent, unofficial projects. The official DX server is pre-1.0 and its GA/NON-GA tool set drifts version-to-version; "most-used" community server is not established. Recycle-Bin behavior is Salesforce platform behavior. Risk groupings are our classification. Sources current as of Aug 2026 — check the source links.