Guide — public sandbox live; real sending not active — verified 2026-07-15

Run your entire cold email operation with Cursor

Cursor drives the same Coldrig MCP server, the same 17 tools, and the same sandboxed-today boundary as Claude Code — the full provisioning-to-reply lifecycle is identical. What's genuinely different is how you connect it and how you make the workflow repeatable: Cursor takes a hand-edited mcp.json instead of a CLI command, and it has its own convention (Rules) for storing reusable agent instructions instead of Claude Code's Skills. This page covers only that delta; for the full step-by-step lifecycle (provisioning through reply triage) see the Claude Code guide — every tool call there works identically from Cursor.

Honest status disclosure The hosted API, MCP endpoint, and npm CLI work today against a live sandbox — no real domains, mailboxes, or sends. Real sending is not active. See FAQ for what "early access" means concretely.

How is Cursor's setup different from Claude Code?

Exact Cursor config

Mint a tenant token first (no card required):

curl -s -X POST https://agent-cold-email-api.yaakovscher.workers.dev/signup \
  -H 'Content-Type: application/json' \
  -d '{"brand":"Acme","contactEmail":"[email protected]"}'
# → { "tenantId": "ten_...", "token": "..." }

Then add this to personal ~/.cursor/mcp.json:

{
  "mcpServers": {
    "coldrig": {
      "url": "https://agent-cold-email-api.yaakovscher.workers.dev/mcp",
      "headers": {
        "Authorization": "Bearer ${env:COLDRIG_TOKEN}"
      }
    }
  }
}

Set COLDRIG_TOKEN where the Cursor desktop process can read it, restart Cursor, and inspect all 17 tools before you rely on the connection. Full side-by-side with Codex and Cline: the connect reference.

The lifecycle, from Cursor

Identical tool calls to every other client — Cursor just makes them through its own agent chat instead of a terminal session. Full schemas: the MCP tool reference.

StepTool call
Provision domains + mailboxes, start warmupsetup_infrastructure
Poll provisioning + warmup healthinfrastructure_status
Write and launch the campaignlaunch_campaign
Triage repliesinbox, thread, reply, mark, label_thread
Check health, pausemetrics, activity, account, pause / pause_all

What's a Cursor Rule for this, and should I write one?

Cursor's convention for repeatable, project-scoped agent instructions is a Rules file — typically a .mdc file under .cursor/rules/ in your project (the legacy single-file form is .cursorrules at the project root). Nothing below ships with Coldrig; it's a rule you write yourself so Cursor applies the same operating discipline to this project every time, instead of you restating it in chat.

---
description: Operate Coldrig-backed cold email infrastructure for this project
alwaysApply: false
---

Coldrig is connected as the `coldrig` MCP server. Read the bearer token from
the `COLDRIG_TOKEN` environment variable — never hardcode it in this repo.

- Write the offer and sequence content yourself before calling `launch_campaign`;
  Coldrig does not generate outreach copy.
- Check `activity` for new events before assuming nothing has happened — there
  are no push webhooks, only polling.
- Never claim a real send occurred while the tenant is in demo/sandbox mode.
- Never claim guaranteed inbox placement or deliverability.

The reply-handling boundary, in short

No push webhooks in the current public API — activity and inbox are pollable, not pushed. Run Cursor on whatever cadence you choose to check for new replies; there's no callback that fires on its own. Full honest capability matrix: see the detailed breakdown.

Cost

Same platform, same meter, regardless of client: $99/month for 5 provisioned mailboxes, then $10/month per additional mailbox. Full worked examples and the live calculator: pricing.

Try it now

npx agent-cold-email demo

Runs the same fault-injecting sandbox end to end — no real domain, mailbox, or send. Create a sandbox to get a token and connect Cursor for real.

Related guides