Technical guide
Salesforce MCP server: connecting Claude to your org
A Salesforce MCP server is a Model Context Protocol server that exposes your Salesforce org to an AI assistant such as Claude as a set of callable tools — query records, read metadata, create and update data — with your permissions applied. Claude connects to it, and a user can then ask questions in natural language and get answers grounded in live CRM data instead of guesses. Salesforce ships an official MCP server, and community implementations exist. The hard part is not the connection; it is scoping permissions, controlling write access, and making the tools return data small enough for a model to reason over.
Last updated July 30, 2026 · Skydog Ops
What MCP actually is
The Model Context Protocol is an open standard, introduced by Anthropic, for connecting AI assistants to external systems. An MCP server advertises a set of tools; the AI client discovers those tools and calls them when a user's request requires real data or an action.
Before MCP, connecting Claude to Salesforce meant building a bespoke integration per use case. With MCP, one server exposes the org and any MCP-capable client can use it.
Your options
| Option | What it is | Best for | Trade-off |
|---|---|---|---|
| Salesforce official MCP server | Salesforce's own MCP implementation over the platform APIs | Teams that want a supported path and standard object access | Follows Salesforce's roadmap, not yours |
| Community / open-source servers | Node or Python servers wrapping the Salesforce REST and SOQL APIs | Developers experimenting locally | Unvetted permission handling; not appropriate for production data |
| Custom MCP server | A purpose-built server exposing only the objects and actions you approve | Production use with real permission scoping and audited writes | Requires build and maintenance |
How the connection works
- Authentication. A Salesforce Connected App issues OAuth tokens. Use a dedicated integration user with a tightly scoped permission set, not an admin account.
- Tool definitions. The server declares tools such as query_records, describe_object, get_record, create_record, update_record. Each declares its input schema so the model knows how to call it.
- Permission enforcement. Tool calls execute as the authenticated Salesforce user, so field-level security, sharing rules, and object permissions apply. This is what keeps the model inside the same boundaries as a human.
- Result shaping. Raw SOQL results are too large and too noisy for a model. Production servers cap row counts, trim fields, and return summaries rather than full payloads.
- Write guardrails. Reads are safe by default. Writes should be limited to specific objects and fields, and every write should be logged with the prompt that produced it.
What teams actually use it for
- Pipeline questions in plain language: 'which enterprise deals slipped this quarter and why', answered from live records rather than a static dashboard.
- Meeting prep: a full account brief assembled from opportunities, cases, and activity history in seconds.
- CRM hygiene: identifying stale opportunities, missing close dates, and duplicate accounts, then drafting the corrections for approval.
- Data entry by conversation: updating a record after a call by describing what happened rather than clicking through fields.
- Ad-hoc analysis without a report builder: cohort questions that would otherwise require an admin ticket.
What to get right before production
- Never connect with an admin-privileged integration user. Scope a permission set to exactly the objects and fields the use case needs.
- Treat write access as a separate decision from read access, and default to draft-then-approve rather than direct writes.
- Cap query result sizes at the server. An unbounded SOQL result will blow the model's context window and produce confident nonsense.
- Log every tool call with the user, the prompt, and the records touched. Regulated teams need this and everyone else wants it the first time something looks wrong.
- Decide where the server runs. A local server is fine for one developer; a team needs hosted, authenticated, and monitored infrastructure.
How Skydog builds this
Skydog Ops builds production Salesforce MCP deployments: scoped Connected Apps and permission sets, result-shaped tools, approval-gated writes, full audit logging, and hosting. Skydog also ships Rover, an internal chat-to-CRM agent, with every engagement.
The work usually takes 2 to 6 weeks depending on how many objects and write actions are in scope.
FAQ
Common questions
What is a Salesforce MCP server?
A Model Context Protocol server that exposes a Salesforce org to an AI assistant as callable tools — querying records, reading metadata, and creating or updating data — with the authenticated Salesforce user's permissions applied to every call.
How do I connect Claude to Salesforce?
Create a Salesforce Connected App for OAuth, run an MCP server that authenticates through it as a scoped integration user, and register that server with Claude. Claude then discovers the server's tools and calls them when a request needs live CRM data.
Does Salesforce have an official MCP server?
Yes. Salesforce provides an official MCP implementation over its platform APIs. It is the right starting point for standard object access; teams needing tightly scoped tools, shaped results, or approval-gated writes typically add a custom server alongside it.
Is it safe to give an AI access to Salesforce?
It is as safe as the permission set you give it. Tool calls execute as a Salesforce user, so field-level security and sharing rules apply. The real risks are using an admin integration user, allowing unrestricted writes, and not logging tool calls — all avoidable in design.
Can Claude update Salesforce records?
Yes, if the MCP server exposes write tools and the integration user has the permission. Best practice for production is draft-then-approve: the model proposes the update and a human confirms it, with every write logged against the prompt that produced it.
What does it cost to build a Salesforce MCP integration?
A read-only proof of concept can be stood up in days. A production deployment with scoped permissions, shaped tool results, approval-gated writes, audit logging, and hosting typically takes 2 to 6 weeks of engineering.
