Teams now have three practical ways to connect Claude to Salesforce: Salesforce-hosted MCP capabilities, a packaged connector such as ApexGenius, or a custom MCP server. The connection is only the first layer; identity, tool scope, approval, evaluation, and operating ownership determine whether it belongs in production.
MCP provides a common tool interface, which reduces the need to invent a different integration contract for every AI client. It does not choose the workflow or provide a universal security boundary. Those properties still belong to the Salesforce, connector, Claude, and business-process architecture around it.
This guide covers MCP in plain English, the trade-offs among the three connection paths, the security work to complete, and the first read-heavy workflows worth evaluating.
What MCP is, in plain English
The Model Context Protocol (MCP) is an open standard — introduced by Anthropic in late 2024 and adopted across the industry since — for connecting AI assistants to tools and data. The easiest mental model is a USB-C port. Before USB-C, every device needed its own cable. Before MCP, every AI-to-app pairing needed its own bespoke integration. With MCP, an application exposes one server, and any compliant AI client — Claude, ChatGPT, and a growing list of others — can plug into it.
Mechanically, an MCP server publishes a set of tools: things like “run this query,” “describe this object,” or “update this record.” When you connect Claude to a Salesforce MCP server, Claude can discover the tool list and select a tool when a request needs it. Approval and credential handling depend on the client and server configuration. With a per-user OAuth design and tools that enforce user context, Salesforce profiles, permission sets, field-level security, and sharing remain central controls; verify every tool and execution context.
The practical difference from copy-paste is enormous. Answers come from live data instead of a stale export. The assistant can take governed actions — update the stage, log the call, draft the record — instead of just talking about them. And every call is auditable, because it goes through Salesforce's own API and security stack.
Option 1: Salesforce Hosted MCP + Claude
This is the native route: Salesforce hosts the MCP server, you configure it in Setup, and Claude connects to it directly. It ships with supported editions — broadly, the Enterprise tier and up; check your edition before you plan around it — and it is controlled entirely by your admin. Here is the sequence.
- Confirm prerequisites. You need an edition that includes Hosted MCP, admin access to Setup, and a decision about which users get this capability. Do that last part on paper first — “who gets an AI with org access?” is the question that actually takes time.
- Create an External Client App. In Setup, create an External Client App — the successor to connected apps — and enable OAuth for it. This is what lets Claude authenticate: you define the scopes and callback, and Salesforce issues the credentials the OAuth handshake will use.
- Activate the hosted MCP servers. In Setup's MCP configuration, activate the hosted server or servers you want to expose and assign access through permission sets. This is where you decide exactly what surface area the assistant can see.
- Add the connector in Claude. In Claude's settings, open Connectors, add a custom connector, and paste your org's MCP server URL. Claude routes you through the standard Salesforce login, you approve the OAuth grant, and the connection is live.
- Test with something real. Ask Claude for your open opportunities closing this month. It should request permission to use a Salesforce tool, run the query, and answer from live data. If it can see records it should not, stop and fix permissions before going further.
What you get depends on the server you enable. Salesforce documents standard SObject servers, product-specific servers, and custom servers that can expose approved Apex actions, Flows, and APIs. Broader platform capabilities can have separate release status. Verify the exact server, tools, edition, and production status instead of treating “Hosted MCP” as one fixed capability bundle.
Option 2: ApexGenius — packaged Salesforce MCP
Full disclosure: we build ApexGenius, so weigh our bias accordingly. It is a hosted Salesforce MCP for Claude and ChatGPT, running in production since launching in 2025 — and it exists because our own client work kept demanding more capability than the native servers expose, with less ceremony.
The base setup is packaged: create an account at apexgenius.ai, authenticate to an authorized org through Salesforce OAuth, and add the connector in the compatible AI client. Governance, permission design, sandbox validation, and role-based rollout still take the time the operating workflow requires.
The real difference is scope. ApexGenius is full read/write: SOQL and SOSL, record CRUD, schema describes, and — the part admins and developers care about — metadata. It can read and edit Apex classes, LWC, and Flows, deploy changes through the Metadata API, run anonymous Apex, and pull debug logs. It is the difference between an assistant that can look at your org and one that can work on it.
The honest framing: if you want the smallest possible vendor surface, only need governed data access, and you are on a supported edition, the hosted servers can be a good answer. If you need the packaged Salesforce development and metadata scope ApexGenius exposes, evaluate the product and its security model directly against the use case.
Option 3: A custom MCP server
You can also build your own. A prototype can be straightforward; production is the real cost: identity and token lifecycle, secret management, authorization, rate limits, logging, evaluations, failure handling, and ongoing ownership.
When it is worth it: you have a platform team and unusual constraints — data residency, a mandated API gateway, network isolation — or you want one server that fuses Salesforce tools with your internal systems into a single surface Claude can use. When it is not: everything else. Most teams should configure or buy before they build.
Security: do this before you scale it
Salesforce security is a central layer, but MCP does not guarantee how a server implements identity or tools. Apply these controls to the complete connection path:
- Least privilege by default. Connect as a user with a dedicated permission set scoped to what the workflows need — never a system administrator account someone uses for daily work.
- Sandbox first. Point the connector at a full or partial sandbox until your workflows and prompts have hardened. Promote to production deliberately, not by default.
- Verify FLS, sharing, and execution context. Test allowed and denied records and fields for every role and custom tool; do not infer effective access from the OAuth screen alone.
- Humans approve consequential writes. Configure the client and tool policy to require review before risky mutations, and start read-only while the workflow is being evaluated.
- Audit it like an integration. Retain the connector, Salesforce, and workflow logs available to your design and review them on the same cadence as other API clients.
What to build first
The best first workflows are high-frequency, low-risk, and read-heavy. Three patterns to evaluate first:
- Pipeline hygiene sweep. Ask Claude for every open opportunity with a close date in the past, a stage untouched in 21+ days, or an empty next step. Run it weekly so the team reviews one exception list instead of reconstructing it across reports.
- Pre-call account brief. Before a customer call: open opportunities, open cases, and the last ten activities on the account, compressed into a one-page brief. Reps stop walking into calls blind, and nobody built a dashboard to get there.
- Weekly forecast digest. Every Monday: pipeline by stage, commit versus last week, and which deals moved. The same numbers your CRM always had — now delivered as a paragraph a human actually reads.
That is the whole path: pick a connection route, lock down permissions, start with reads, expand deliberately. For the deeper version of how we deploy Claude against Salesforce — patterns, guardrails, and what production looks like — see Claude + Salesforce. And if you would rather have it stood up for you with governance done right the first time, that is exactly what our AI Setup & Enablement engagement is for.