Build against your CRM from Cursor
SalesCrew's MCP server sits beside your code tools in Cursor, so the agent can test a webhook or read a record mid-edit.
- HTTP MCP server
- Signed webhooks
- Read-only tokens by default
The short answer
- SalesCrew connects to Cursor through MCP. You add the SalesCrew server once in Cursor's settings, and its 140+ tools show up to the agent next to file and terminal tools.
- The use is building, not selling. Your coding agent can inspect custom fields with custom_field_list, fire a sample event with webhook_test and check what arrived with webhook_deliveries, all without leaving the editor.
- Your token decides the blast radius. Users get read-only tokens, managers and admins can allow writes, and every call is written to the SalesCrew audit log with the token named.
Mechanism
The tools a developer reaches for most while building an integration.
| What | Mechanism | Direction | Objects | Status |
|---|---|---|---|---|
| Server registration | MCP over HTTP with a Bearer header, set in Cursor | Both | One server per instance | Available |
| Record shapes | contact_search, deal_get, custom_field_list | Outbound | Contacts, deals, custom fields | Available |
| Webhook setup | webhook_create, webhook_update, webhook_rotate_secret | Inbound | Webhooks | Available |
| Webhook testing | webhook_test, webhook_deliveries, webhook_retry | Both | Deliveries | Available |
| Event payload | Signed JSON with event, data and sent_at; X-SalesCrew-Signature is an HMAC SHA-256 of the body | Outbound | Registered events | Available |
| Audit | Each call logged against the token that made it | Internal | Audit log | Available |
Tool names and payload fields read from the SalesCrew MCP server and webhook docs, September 2026. Cursor's own documentation is the authority on its MCP settings.
Setup
Two settings screens and one test prompt.
- 1
Mint a token for the editor
In SalesCrew, open Settings → API access (MCP) and label the token "cursor". Leave Allow writes off unless the task in front of you needs it.
- 2
Register the server in Cursor
Add an MCP server named salesops, type HTTP, with your instance's server URL and the header Authorization: Bearer followed by the token.
- 3
Ask for the tool list
Prompt the agent: "which salesops tools do you have?" The list reflects your scopes, so a missing family usually means a module is off or your role excludes it.
- 4
Wire a webhook while you code
Point a webhook at your local tunnel or staging receiver, have the agent run webhook_test, and read the delivery status in the same session.
- 5
Verify signatures before you ship
Copy the signing secret from Settings → Webhooks and check X-SalesCrew-Signature on every request your receiver accepts.
Keep write tokens out of your repo
Questions
- Why would a developer connect Cursor to a CRM?
- To build against the real thing. While you write a webhook receiver or a sync script, Cursor's agent can fire webhook_test, read webhook_deliveries and pull a record through the same MCP server the rest of your team uses.
- How is Cursor's setup different from Claude's?
- Only the place you register the server. Cursor keeps MCP servers in its own settings, where you add one named salesops with type HTTP, your instance URL and a Bearer header. The token and the tools are identical.
- Can Cursor's agent change production records?
- Only with a write token, and only inside that token's scopes. For day-to-day coding, use a read-only token, and mint a write token when a task needs one.
- Is there an API as well as MCP?
- Yes. Outbound webhooks post signed JSON for the events you pick, and MCP carries every action in the app. Most integrations use both: webhooks to hear about a change and MCP tools to act on it.
Build the integration against a CRM your agent can call
Every app action is an MCP tool, every event can be a signed webhook, and every call is logged.