How do I connect Cursor to my CRM?
Cursor reads MCP servers from its configuration. Add the CRM's server URL and token, and its tools appear to the coding agent beside your regular code tools.
The short answer
- Cursor discovers MCP servers through its own configuration file inside the editor. Adding the CRM's server URL and a token makes the CRM's tools available to Cursor's agent the same way file and terminal tools already are.
- This setup is most common among teams who build automations or integrations around a CRM and want a live system to test against while writing code, rather than switching to a separate client to check the effect of a change.
- The tools that appear are identical to what any other MCP client would see from that server. Cursor adds nothing CRM-specific. It treats the CRM as one more tool source next to your codebase.
- Running a coding agent against a production CRM in the same session as editing code is the setup most likely to produce an accidental write. Use a sandbox or test instance for this workflow.
Why the config file, not a dedicated menu
Cursor was built as a code editor first. MCP support was added as a general extension point rather than a CRM-specific feature. That means the setup path runs through the same configuration file developers already use to register other MCP servers: a JSON entry naming the server's URL and how to authenticate to it. Once saved, Cursor's agent can see and call every tool that server exposes, the way it already sees your project's files and terminal.
This is useful because Cursor's agent is already comfortable making several tool calls in a row while it works through a task. A developer testing "does this webhook create the right kind of deal" can ask the agent to call the CRM directly and check. No throwaway script, no switching to a browser tab.
What to have ready before connecting
These four items get a CRM's MCP server working in Cursor's configuration.
| Item | Where it comes from | What it does |
|---|---|---|
| Server URL | The CRM's MCP or developer settings page | Tells Cursor where to send tool-discovery and tool-call requests |
| Auth token or header | Issued from the CRM's token or API-key screen, scoped to a role | Authenticates every call as that token's permission level |
| Cursor's MCP config entry | Cursor's own settings, a JSON block naming the server and its auth | Registers the server so the agent can discover its tools at session start |
| A non-production target | A sandbox account, test instance, or throwaway dataset in the CRM | Keeps a stray or exploratory write out of real customer records |
Keep the coding session and the production account separate
The risk here is not Cursor specifically. It is the combination of an agent that is actively writing and running code, and a CRM connection that can write real records, in the same session. An agent debugging a webhook handler might call the CRM's create-deal tool several times while iterating. If that token points at production, those test calls create real deal records a salesperson will eventually find and have to clean up.
A sandbox instance, or at minimum a token scoped to a clearly marked test pipeline, solves this without giving up the workflow. Disclosure: SalesCrew is our product. Because every client gets a dedicated database, teams building integrations against it can provision a second, non-production instance to point a coding agent at. Exploratory tool calls then never touch a real pipeline.
Editing code and writing to production in one session needs a sandbox
Questions
- Is Cursor's MCP setup the same as Claude's?
- Both follow the same MCP standard, so a server that works with one generally works with the other. The difference is where you register it. Cursor reads servers from its own configuration file inside the editor. Claude's desktop app has a separate settings screen. The CRM server and token are the same either way.
- Why would a developer connect a CRM to a code editor at all?
- Teams building automations around a CRM want a live target to test against while writing the code. Cursor's agent can call the CRM's tools directly to check a webhook payload, inspect a record shape, or run a query without switching to a separate client.
- Does Cursor's agent write to the CRM the same way it edits code?
- Mechanically yes. Once a tool is registered, the agent can call it during a coding session the same way it edits a file. That is exactly why a production CRM instance is the wrong target for this kind of session. Use a sandbox, so a stray write does not land in real records.