Access Salesforce from Claude

Salesforce's hosted Model Context Protocol (MCP) servers provide a governed way to connect AI clients like Claude to Salesforce capabilities. This article explores the architecture, setup considerations, and potential use cases for enabling natural-language access to Salesforce data and actions while retaining existing access controls.

How the interaction works

In the Claude-Salesforce interaction, Claude does not access Salesforce directly. Instead, it connects to a Salesforce MCP server that exposes a curated set of Salesforce tools.

When a user submits a request, the model determines which available tool is relevant to the task. MCP client then invokes the relevant tool through the MCP server, Salesforce evaluates the request using the authenticated user's permissions, and the results are returned to the client.

MCP does not independently grant Salesforce privileges. The External Client App controls client authentication and authorization, the MCP server determines which tools are exposed, and Salesforce evaluates each operation against the authenticated user's applicable permissions and record access. These controls work together so that exposing a tool does not automatically grant users permission to perform every operation it supports.

Start with a small scope in a sandbox

Always start in a sandbox with a Salesforce-hosted MCP server that matches your use case. Salesforce provides standard servers for common platform capabilities, as well as custom servers that let administrators curate the tools exposed to an AI client. You can also start with a custom MCP server hosted in Salesforce exposing a small set of MCP services. Reference

Claude can then connect to Salesforce's published MCP services through Salesforce MCP server, making selected Salesforce capabilities available to delegated administrators or business users in natural language. Model reads the question and chooses which tool to call, and the client makes that call to the MCP server. Salesforce still checks the signed-in user's access on every call, and the results travel back through the model to form the answer.

This pattern complements a typical developer workflow, wherein developers leverage AI tools to assist with routine tasks. For example, if a developer leverages GitHub Copilot in VS Code to trace Salesforce behavior across Apex, Flows, Lightning Web Components, metadata, integrations, and tests, we can render a complementary experience to a delegated administrator or business user through an MCP connection, wherein an approved client (Claude, for example), can help administrators or business users investigate or perform specific Salesforce tasks using the services exposed to it. In both cases, AI can speed up exploration, explain errors, and turn findings into clear recommendations or even take actions, with careful security settings applied.

The key is in matching the tool to the user and the task: developers work with source code in their IDE; delegated administrators can use approved Salesforce capabilities through a client they can access. And MCP does not grant extra Salesforce privileges by itself. Requests are performed in context of the authenticated user's permissions and the MCP server's exposed tools govern access. Before enabling the capability, define which services are available, whether users can make changes or only read, what data may be shared with the AI provider, and how usage is logged and reviewed.

How to set it up

These are the high-level steps I followed. Menu names can change between releases, so check them against Salesforce's latest published documentation.

Create a custom MCP server. In a sandbox, create a custom server under API Catalog in Setup, with a label, name and description.
Add the tools. While the server is deactivated, add the Salesforce services it should publish as tools. I chose tools that cover both data and metadata, with the ability to read, create and update records, so Claude gets the full context of the data and the data model.
Activate the server. Servers are off by default until an admin turns them on.
Create an External Client App to register the Claude client with Salesforce. Set the callback URL for Claude, add the Access MCP servers’ scope, enable PKCE and JWT-based tokens, and set the OAuth policies, such as, which users may connect.
Add a custom connector in Claude. Add the custom MCP server's URL and the app's consumer key, then approve the Salesforce sign-in.
Test as a real user. Confirm that only the intended tools appear and that results respect that user's access. Salesforce's standard user permissions apply in addition to the app-level checks, so the External Client App and the user's permissions work together with the tool list.

I configured Claude, but the server is not tied to Claude. Any MCP-capable client can connect to the same URL and get the same tools with the same limits.

Considerations

I recommend these considerations in design:

Define actions. Publish the server with a specific set of tools to read, create and update records.
Test in a sandbox first. Configure and test the tools in a sandbox first with no risk to production data.
Keep the scope deliberately narrow. Expose only the tools required for the use case and ensure that only a curated subset of data and metadata is reachable.
Use a signed-in user account. Requests should run with the user's own Salesforce access, so the agent does not see more than the person using it.
Monitor usage and review activity regularly. Use Salesforce audit and monitoring capabilities to understand how tools are being used and identify any unexpected behavior.

Example interactions

A delegated administrator could use Claude to ask:

Which validation rules run when an Opportunity is moved to Closed Won?
Show me the fields used by the Revenue Forecast process.
Find Opportunities missing a Primary Contact.
Create a test Opportunity for Account Acme.

Claude can only answer or perform actions through the tools exposed by the MCP server and only within the permissions granted to the signed-in Salesforce user.

Where it can go next

You can extend the same pattern to other audiences by changing the scope for the use cases, like:

Data and metadata exploration capabilities for delegated admins from specific business units with permission sets limited to their objects and records. Tool list and user-level access can remain the same.
Metadata exploration for architects and developers for dependencies and impact analysis.
Record lookups for support and service teams without navigating several screens.
Use for data quality and documentation by allowing queries for missing data and generated data-model summaries.

The delegated admin case is the one I find most promising. A person who administers only part of Salesforce can get answers about their own area through chat, while the central team keeps the boundary.

Interested in exploring Salesforce MCP and its potential for your organization? Connect with me to exchange ideas and discuss practical use cases. Reach me at support@muditasharma.com