quiccsite

MCP Server for Salesforce: Querying Your CRM from Claude Code

If you build on top of Salesforce, you've spent time tabbing between your editor, the Salesforce Developer Console, and Workbench just to check field names or test SOQL queries. An MCP server for Salesforce eliminates that context switching by letting Claude Code query your CRM directly.

Why connect Salesforce to Claude Code?

The obvious use case is running SOQL queries without leaving your terminal. But the real value shows up when Claude can see your actual data model while it writes code.

Ask Claude to build a sync integration and it can inspect the Contact and Account objects, check which fields are populated, and write code that handles your org's custom fields — not just the standard ones from the docs. When a sync breaks, you can ask Claude to pull the last modified records and compare them against what your database has.

A few concrete workflows:

Setting up an MCP server for Salesforce

You have two paths: use a community server or build your own.

Community options

Search the MCP server registry for Salesforce connectors. Several open-source options exist that wrap the Salesforce REST API and expose tools for SOQL queries, object describe calls, and record CRUD. Evaluate them for maintenance activity and whether they support the auth flow you need.

Building your own with jsforce and FastMCP

If you want full control, building a lightweight server is straightforward. The core dependencies are jsforce for the Salesforce connection and fastmcp (or the MCP SDK directly) for the server framework.

Your server needs a handful of tools:

That's enough for most development workflows. You don't need full CRUD unless you're specifically testing write operations.

Register the server in your .claude/settings.json, following the same pattern used for a Postgres MCP server or a Jira MCP server:

{
  "mcpServers": {
    "salesforce": {
      "command": "node",
      "args": ["./mcp-servers/salesforce/index.js"],
      "env": {
        "SF_LOGIN_URL": "https://test.salesforce.com",
        "SF_USERNAME": "dev@example.com",
        "SF_ACCESS_TOKEN_PATH": "~/.sf/token"
      }
    }
  }
}

Authentication

Salesforce auth is the hardest part of this setup. You need a Connected App in your Salesforce org.

Connected App setup: Create one in Setup > App Manager. Enable OAuth, select the scopes you need (at minimum api and id), and set a callback URL. For a local MCP server, http://localhost:3000/callback works.

Token management: The cleanest approach for development is the OAuth 2.0 JWT Bearer flow with a certificate. You authenticate once, and the server can refresh tokens without user interaction. Alternatively, use the username-password flow for sandbox environments where security is less critical.

Store tokens outside your repository. Read them from a file path or environment variable at server startup. Never put Salesforce credentials in your MCP server config or your codebase.

Example workflow

With the server running, a typical session looks like this:

You're building a webhook handler that processes Salesforce contact updates. You ask Claude:

"Describe the Contact object in our Salesforce org and show me any custom fields."

Claude calls the describe tool, gets back the field list, and now knows your org has Customer_Segment__c, Lifecycle_Stage__c, and other custom fields. When it writes the webhook handler, it accounts for these fields without you having to list them out.

Later, a record fails to sync. You ask:

"Query the last 5 contacts modified today and show their SystemModstamp and Lifecycle_Stage__c values."

Claude builds and executes the SOQL query, returns the results, and you can compare them against your application database to find the mismatch.

Security considerations

Use read-only access. Your MCP server's Connected App should use a permission set that only allows read access to the objects you need. There's no reason Claude needs to create or delete records during a coding session.

Use sandbox environments. Point your MCP server at a sandbox or developer org, not production. The connection string should use https://test.salesforce.com as the login URL.

Scope the permissions. Don't grant access to all objects. If you're working on a contacts integration, the Connected App only needs access to Contact, Account, and whatever related objects you're touching.

Audit the queries. Salesforce logs all API calls. You can review what your MCP server queried in Setup > Event Monitoring if you need to verify what data was accessed.

Limitations

A few things to keep in mind:

The setup takes about an hour if you're building your own server, less if you use a community option. You can also extend Claude Code further with plugins and subagents. The payoff is immediate — having your CRM data available while coding against it removes an entire category of context switching from your workflow.