How to Connect Salesforce to Claude with MCP — and Why It's Worth It
Two open-source MCP servers let Claude read, query, and update your Salesforce org. Here's how the connection works, the licensing tradeoff, and what it unlocks.
Connecting Claude to Salesforce turns your CRM from a place you log into and click around in, into something you can simply talk to — and, when you want, something Claude can act inside on your behalf. The bridge that makes this work is called MCP, the Model Context Protocol: an open standard for letting an AI assistant securely use external tools. Point Claude at a couple of Salesforce MCP servers and it can read your data, answer questions about your org, and — with the right setup — create fields, refactor Apex, and update records. Here’s how it works and why it’s worth doing.
What MCP actually is
MCP is a small, open protocol that standardizes how an AI model talks to outside systems. An "MCP server" is just a connector that exposes a set of tools — "run this query," "update this record," "deploy this metadata" — that Claude can call. The servers run locally on your machine, authenticate to Salesforce through the normal Salesforce CLI / OAuth flow, and act through Salesforce’s standard APIs. Nothing proprietary, nothing that bypasses Salesforce security. Claude can only ever do what the connected Salesforce user is permitted to do.
The two servers — and what each one does
In practice you connect two complementary Salesforce MCP servers. They overlap a little, but they’re built for different jobs. Worth saying plainly: both are free and open source — there’s no license to buy for the connection itself.
| Salesforce DX MCP (official) | Community MCP (tsmztech) | |
|---|---|---|
| Built by | Salesforce | Open-source community |
| License | Apache 2.0, free | Open source, free |
| Read data (SOQL) | ✓ | ✓ |
| Write data (create/update/delete) | ✗ | ✓ |
| Create objects & fields | via metadata deploy | ✓ directly |
| Read / write Apex | deploy & code analysis | ✓ + run anonymous |
| Org / DevOps tooling | ✓ 60+ dev tools | ✗ |
The official Salesforce DX MCP server is the developer and DevOps workhorse. It ships 60-plus tools organized into toolsets — org management, metadata deploy and retrieve, SOQL queries, static code analysis via Code Analyzer, even Aura-to-LWC migration. It’s excellent at reading your org and moving metadata around, but its data side is read-oriented; it isn’t built to casually create and update individual records.
The community server (the widely used tsmztech/mcp-server-salesforce) fills exactly that gap. It does full record CRUD — insert, update, delete, upsert — plus it can create and modify custom objects and fields, manage field-level security, read and write Apex classes and triggers, execute anonymous Apex, run aggregate queries, and manage debug logs. This is the server that lets Claude act like a hands-on admin and developer rather than just a reader.
Give Claude its own Salesforce user
The single most important setup decision is who Claude logs in as. You can point the connection at your own user — but the better pattern, and the one I run, is to create a dedicated Salesforce user, "Claude Agent," and connect through that identity instead. The upsides are real and worth the trouble.
- Scoped permissions. Claude gets exactly the access you grant its user — no more. You can dial it up for trusted work or keep it tight, all through standard profiles and permission sets.
- Clean audit trail. Every record Claude touches shows "Claude Agent" as Created By / Last Modified By. You can always see, at the field-history level, exactly what the AI changed versus what a person did.
- Delegation by ownership. Because it’s a real user, you can assign records to Claude. Route new Leads to Claude Agent for enrichment, let it do the work, then hand them back to a rep once qualified. Ownership becomes a work queue.
One real downside: cost. The tempting move is Salesforce’s free Integration User license. I tried it. It’s too restrictive for this use case — at the license level it can’t grant Modify All Data, Customize Application, modify metadata, or author Apex, no matter how you design the permission set. If you want Claude to do admin and developer work, you need a full Salesforce license for its user, which is roughly $165/month — one additional seat.
~$165
/mo for a full SF seat
$0
For the MCP servers
100%
Actions attributable
Records Claude touches directly are attributed to its user. But Flows and triggers always run as their configured running user — so if Claude updates a record and that fires automation, the downstream changes show the automation's user, not Claude. That's how Salesforce's audit model works everywhere, not a quirk of this setup. Plan your "who changed what" expectations around it.
What you can actually do once it’s connected
This is where it gets fun. With the org wired up, Claude isn’t a chatbot bolted onto the side of Salesforce — it’s working inside your data and metadata.
Your org becomes conversational
Ask plain-English questions and get answers off live data: "How many open opportunities over $50K have no activity in 30 days?" "Which lead sources convert best this quarter?" Claude writes the SOQL, runs it, and explains the result. No report builder, no dashboard config — just the question.
It can act as your admin
Need a new field, a picklist, a custom object, field-level security set across profiles? Describe it and Claude builds it through the metadata tools — the same declarative changes you’d click through in Setup, done in seconds and documented in the conversation.
It can read and improve your Apex
Point Claude at a trigger or class and it will read it, explain what it does, and flag performance problems — SOQL in loops, missing bulkification, governor-limit risks. It can go further: write the optimized version and the test class, or recommend converting brittle Apex into a Flow where that’s the better long-term call. (Real engineering judgment still belongs in review — but the first 80% arrives instantly.)
It can spot trends and adoption gaps
Because it can query everything, Claude is good at the analysis nobody has time for: which users actually log in and create records, which fields are sitting empty, where data quality is decaying, how pipeline is trending month over month. Adoption and usage patterns that normally require a consultant and a spreadsheet become a question you just ask.
"Read the LeadTrigger class, find anything that'll hurt us at scale, rewrite it bulk-safe, and generate a test class with 90%+ coverage." Claude reads the Apex, identifies a query inside a loop, rewrites it as a single bulkified query, and produces a passing test class — all in one conversation, all attributable to its user, all reviewable before you deploy.
From conversation to autonomous agents
Everything above is interactive — you ask, Claude does. The next step is letting it run without you in the chair. Two mechanisms make that real:
Skills are packaged, reusable instructions (and scripts) that teach Claude to do a specific job the same way every time — say, "enrich a new Lead from its website and set the verdict field." Once a Skill exists, the work is consistent and repeatable instead of improvised. Scheduled Tasks run a prompt automatically on a cadence — every morning, every hour, every Monday. Combine the two with the Salesforce MCP connection and you have a genuine agent: on a schedule, Claude reads records, applies a Skill’s logic, and writes results back to Salesforce — enriching leads, scoring deals, flagging stale records, summarizing closed cases — with no one watching. It still acts as its own user, so everything it does stays scoped and auditable.
The connection is the easy part. The value is deciding what you want an always-on, fully-auditable teammate inside your org to actually do.
Eric Lovgren, lovgren.ai
Why do this at all
Because it collapses the distance between a question and an answer, and between a decision and the change that implements it. Your data stops being locked behind reports and clicks. Admin and developer work that used to wait for a backlog happens in a conversation. And because Claude runs as a permissioned, audited Salesforce user, you get all of that without giving up the governance Salesforce is built on. It’s the cheaper, simpler, more transparent path to an AI-augmented org — which is exactly the kind of recommendation I’m here to make, whether or not it’s the one a vendor would prefer I sold you.