Salesforce MCP Server Setup for Cursor IDE (2026)

How do you set up the Salesforce MCP server in Cursor? Authenticate the Salesforce CLI against your org (sf org login web), install @salesforce/mcp, point Cursor's mcp.json at it with your org alias, then restart Cursor. There's no separate API token to generate and paste — the server reuses your existing CLI session, which also means it can do anything your Salesforce user can do.

That last part is the thing to actually read before you wire this into a production org. More on that below.

This Setup Is Different from the Other CRM Guide on This Site

The HubSpot MCP server guide uses a Private App token you generate once and paste into a config file — static, scoped to specific object permissions, easy to revoke. Salesforce's CLI-based auth works differently: it's a live session tied to your actual user account, with whatever permission set, profile, and sharing rules your admin assigned you. There's no separate "MCP scope" to configure. If you can see it and edit it in the Salesforce UI, the AI can too.

For a team setup where multiple people or a CI system need a fixed, auditable set of permissions instead of "whatever this one user can do," a Connected App with OAuth client credentials is the better fit — Salesforce's own docs cover registering one. This guide covers the faster path: personal CLI-based setup for one developer.

Prerequisites

Step 1: Install the Salesforce CLI

If you don't already have sf installed:

npm install --global @salesforce/cli

Confirm it worked:

sf --version

Step 2: Authenticate Your Org

sf org login web --alias my-org --instance-url https://login.salesforce.com

Use https://test.salesforce.com instead of login.salesforce.com if you're authenticating against a sandbox — this is the step people most often get wrong when following an old tutorial, since sandboxes and production use different login hosts.

This opens a browser window. Log in and grant access. Once it completes, sf stores the session locally and my-org becomes your default alias for CLI and MCP commands alike.

Step 3: Install and Configure the MCP Server

npm install -g @salesforce/mcp

Add it to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "salesforce": {
      "command": "npx",
      "args": ["-y", "@salesforce/mcp", "--orgs", "my-org"],
      "env": {}
    }
  }
}

The --orgs flag takes the alias you set in Step 2. No token, no key — the server shells out to your authenticated sf CLI session for every request.

Step 4: Restart Cursor and Verify

Quit and reopen Cursor, then check View → Output → MCP for a clean startup. Test with something read-only first:

List the fields on the Opportunity object

If you get real field names and types back, the connection works.

Sandbox First, Production Later

Because this setup inherits your full user permissions rather than a scoped token, the blast radius of a wrong prompt is whatever your account is allowed to do — which for most Salesforce admins and senior devs includes bulk edits and deletes. A migration script gone wrong in Postgres has a rollback. A bad "update all opportunities matching X" prompt against a live Salesforce org does not have an equivalent undo button.

Two practical steps before you point this at production:

Practical Workflows

Check object schema before writing integration code

What are the API names and data types for all custom fields on the Lead object?

Saves a trip to Setup → Object Manager every time you're not sure whether a field is Lead_Source__c or LeadSource__c.

Pull a record for context while debugging

Show me the Opportunity record with Id 006XXXXXXXXXXXX — I need to see why the automation isn't updating StageName

Check validation rules before building a form

List the active validation rules on the Contact object so I know what my new signup form needs to satisfy

Cross-reference picklist values

What are the valid picklist values for Opportunity.StageName in this org? I want to make sure my integration's enum matches exactly

Salesforce orgs frequently customize standard picklists, so this catches mismatches a generic Salesforce API doc would miss.

Troubleshooting

"No default org set" error
The MCP server relies on the CLI's stored auth — run sf org list in a terminal to confirm my-org shows up as authenticated, and re-run the login command if it doesn't.

Session expired
CLI sessions expire periodically depending on your org's session settings. Re-run sf org login web --alias my-org to refresh it; the MCP server picks up the renewed session automatically on the next request.

"Insufficient access" on an object or field
This is a permission problem, not a config problem — the CLI session has exactly the access your Salesforce user has. Check your profile/permission set in Setup, not the MCP config.

Server doesn't appear in Cursor
Run npx -y @salesforce/mcp --orgs my-org directly in a terminal. If the CLI itself throws an auth error there, fix that first — the MCP layer won't work around a broken CLI session.

Frequently Asked Questions

Q: Do I need to set up a Salesforce Connected App, or does the CLI login work on its own?
A: For a single developer, the CLI login (sf org login web) is enough — no Connected App registration required. Connected Apps with OAuth client credentials matter more for team or CI setups where you want a fixed, auditable permission set instead of "whatever this developer's account can do."

Q: Can the AI create or update Salesforce records, or only read them?
A: It can do both, since it's operating through your authenticated CLI session with your full permissions. There's no built-in read-only mode — if you want query-only behavior, authenticate with a user whose permission set doesn't include write access to the objects you care about.

Q: What happens when my CLI session expires mid-project?
A: Requests through the MCP server start failing with an auth error. Re-run sf org login web --alias my-org in a terminal to refresh the session — you don't need to touch the Cursor config again.

Q: Does this work against a Salesforce sandbox, or only production?
A: Sandboxes work the same way, but you authenticate against test.salesforce.com instead of login.salesforce.com in the login command. This is also the recommended place to test your setup before connecting it to a production org.

Q: Should I use this instead of building a custom Apex or REST integration?
A: Different jobs. This is for interactive, exploratory work inside your editor — checking schema, pulling a record for context, verifying validation rules. It's not a replacement for a proper Apex trigger, Flow, or REST integration that needs to run unattended or handle high volume.

Related Guides

---