Use Cursor

DispatchSEO is a backend with an MCP server on the front of it. Any coding agent that speaks MCP can drive it, and Cursor speaks MCP. If Cursor is the editor you already live in, you don't have to switch to use this.

One thing up front, because finding it out later would cost you a night: Cursor does not run the scheduled overnight builds yet. Everything else works, and the rest of this page is honest about which is which.

What you get

The capability list is the same. One thing about that last row is worth knowing before you plan around it: the overnight builds run on a server with no browser, so they can't use the login you'll do in step 1. They need a Cursor API key - any plan can mint one at cursor.com/dashboard/api (open that URL directly; the page is often missing from the dashboard's own menu).

Builds draw on your Cursor plan's included usage, and the free plan's pool is small - so a nightly schedule realistically wants a paid plan for capacity. If you'd rather not pay for that, pick Claude Code or Codex as the builder on Settings → Coding agent and keep using Cursor all day - the builder setting only decides who runs the scheduled jobs, not who you work with.

Step 1: install Cursor

If you already use the Cursor editor, you have what you need for the editor half and can skip to step 2.

For the command line, run this:

curl https://cursor.com/install -fsS | bash

That installs cursor-agent into ~/.local/bin. If your shell can't find it afterwards, that directory isn't on your PATH - add it:

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc && source ~/.zshrc

Check it worked:

cursor-agent --version

Step 2: connect your project

Open a terminal in your site's repo folder - the same folder you'd open in Cursor - and paste the command from your dashboard: Settings → Project key, Cursor tab. It already has your project's key filled in.

It looks like this:

mkdir -p .cursor && node -e '...' && cursor-agent mcp enable dispatchseo-yoursite

Two things it does, both on purpose:

• It writes .cursor/mcp.json in this folder, merging into that file rather than replacing it. Any MCP servers you already had are left alone.
• It approves the server. Cursor won't load an MCP server it hasn't been told to trust, so writing the config isn't enough on its own. This is the step people miss when they wire it up by hand.

Step 3: check it actually connected

cursor-agent mcp list

You want to see exactly this:

dispatchseo-yoursite: ready

ready means Cursor reached the server and authenticated. Two other answers you might get:

• not loaded (needs approval) - the config is there but the approval isn't. Run cursor-agent mcp enable dispatchseo-yoursite.
• Error: Connection failed - the server was reached but rejected the key. Copy the command from your dashboard again; the key is probably truncated.

To see the tools themselves:

cursor-agent mcp list-tools dispatchseo-yoursite

That prints all 61, with their arguments.

Step 4: use it

There are no slash commands - those are a Claude Code file convention. With Cursor you name what you want in a normal prompt:

Use the dispatchseo tools. Call get_instructions with workflow "research", then follow it.

Or just ask for something and let it find the tool:

Using dispatchseo, show me my current keyword queue and what's ranking.

The same works in the Cursor editor's chat, since the editor and the CLI read the same .cursor/mcp.json.

Two things that surprise people

A written config is not a connected server. Cursor keeps an approval list, and a server it hasn't approved shows as not loaded and hands the agent no tools at all. The connect command above handles this. If you ever edit .cursor/mcp.json by hand, re-run cursor-agent mcp enable <name> after - changing the config invalidates the old approval.

The connection belongs to the folder, not to you. .cursor/mcp.json sits in the repo, so each site you manage gets its own connection and its own key, and they can't shadow each other. Open a different project's folder and you get that project's tools. This is what you want, and it's worth knowing before you wonder why the tools vanished in an unrelated repo.

Something's wrong

command not found: cursor-agent - ~/.local/bin isn't on your PATH. See the export line in step 1.

The tools don't show up in the editor - Cursor reads the config when it opens the folder. Close the window and reopen the repo.

Connection failed - the key is wrong or incomplete. Re-copy the command from Settings → Project key; the most common cause is a key that got cut short on the way over.

Everything connects, but nothing gets built overnight - check two things. Cursor has to be selected under Settings → Coding agent, and your site's repo needs a CURSOR_API_KEY secret (the login on your laptop doesn't reach a build server). The setup command collects and verifies that key for you.

Turning on the overnight builds

Two things, in this order:

1. Settings → Coding agent → Cursor. That's one column write; it takes effect on the next scheduled run with no repo edit and no reinstall.
2. A CURSOR_API_KEY secret on your site's repo. Create the key at cursor.com/dashboard/api - open the URL directly - then either re-run the setup command from your dashboard - it collects the key and checks it with Cursor before saving - or set it yourself:

printf '%s' "<your-key>" | tr -d '[:space:]' | gh secret set CURSOR_API_KEY --repo <you>/<your-repo>

The tr -d is not fussiness: terminals paste long keys with a real newline inside them, and GitHub will happily store the broken version.

One honest note on how new this is. Cursor is the newest of the three builders here, and while the whole chain has been run against the real server, it has had less time on a schedule than Claude Code and Codex. If a run fails you'll hear about it - a failure that isn't recognised as a temporary limit is reported loudly rather than quietly retried - but if you'd rather your night shift be the most-travelled path, Claude Code is it.