All agents

Cursor

Cursor

Connect DataFeeds to Cursor with one entry in .cursor/mcp.json, verify it with a live call, and start asking for real data.

1. Get a token

Register at the API Locker to generate an RSC_token. New accounts include a 30-day free trial.

2. Put it in your environment

Cursor reads the token from the RSC_TOKEN environment variable rather than storing it in a config file. Add it to your shell profile (~/.zshrc, ~/.bashrc) or your secret store:

export RSC_TOKEN='your-token-here'

Cursor is a GUI app, and it inherits the environment of whatever launched it: started from the dock, it may never see a variable you exported in a terminal. After setting the variable, launch Cursor from a fresh terminal (cursor .) so it picks the variable up.

Never paste your raw token into an agent chat. Anything you type into a conversation may be persisted in a transcript, synced to a vendor, or written into a log you don't control. Set the environment variable and let Cursor reference it — no step on this page needs the token's value to appear anywhere. If a token has already been pasted somewhere it shouldn't be, rotate it in the API Locker.

3. Add the server

Add the server to ~/.cursor/mcp.json (global) or .cursor/mcp.json (this project only):

{
  "mcpServers": {
    "datafeeds": {
      "url": "https://mcp.datafeeds.rolling-insights.com/mcp",
      "headers": {
        "Authorization": "Bearer ${env:RSC_TOKEN}"
      }
    }
  }
}

If the file already exists, merge the datafeeds entry into the existing mcpServers object rather than replacing the file. The /mcp path is required — the bare hostname will not work. Note the env: prefix — it is Cursor's own syntax, and it is required. A reference without the prefix is not expanded: Cursor would send the placeholder text itself as your token and fail with an unhelpful 401.

4. Verify

Reload Cursor and check that datafeeds shows as enabled under Settings → MCP. That confirms the config parses, not that the token works — the server only validates it on a real call. So ask for live data in a chat:

Using the DataFeeds tools, what NBA games are on today?

A working connection returns real games. If it doesn't, troubleshooting below separates URL problems from token problems.

5. Enable the skill

The server above gives Cursor live data. The Sports AI Skill also teaches it the API's conventions — sport codes, season semantics, which endpoints exist per sport — so the code it writes against the REST API is right the first time. One command enables it:

npx skills add Rolling-Insights/sports-datafeeds-by-rolling-insights-skill -a cursor -y

-a scopes the skill to Cursor, and -y auto-confirms; the CLI prints its security assessment either way. The command needs Node.js 22.20.0 or newer — switch with nvm use 22 if npx reports EBADENGINE. It touches no MCP config and never involves your token.

Troubleshooting

The connection fails, or every tool call reports a rejected token

This is the most common problem, and it almost always means RSC_TOKEN was not set in the environment Cursor was launched from.

The failure is quiet, because there is nothing in the exchange that tells Cursor to prompt you for credentials. Our server answers an unauthenticated request with a plain 401 and no WWW-Authenticate header, since it does not implement the OAuth discovery flow — a rejected token surfaces as a failed connection or failing tool calls, not a login prompt.

Two Cursor-specific traps produce the same symptom. A reference written without the env: prefix is not expanded — Cursor sends the placeholder text itself as the token, so the config looks right but every call gets a 401. And because Cursor is a GUI app, it only sees variables that existed in the environment that launched it: started from the dock, it may never see what you exported in a terminal.

To fix it:

# Confirm the variable is set — without printing its value.
[ -n "$RSC_TOKEN" ] && echo "RSC_TOKEN is set" || echo "RSC_TOKEN is NOT set"

If it's unset, add it to your shell profile, then open a new terminal and launch Cursor from there (cursor .) so it inherits the variable.

Is it the URL or the token?

Check the unauthenticated health endpoint first:

curl -sS https://mcp.datafeeds.rolling-insights.com/healthz
# {"status":"ok"}
  • Anything other than {"status":"ok"} — wrong URL, or a network or DNS problem. Confirm the host, and confirm your config includes the /mcp path.
  • {"status":"ok"} but Cursor still can't connect — the server is fine and the problem is the token or the config syntax.

GET /mcp returns 405

Expected, not a fault. The server speaks Streamable HTTP and is POST-only — there is no server-to-client event stream to open with a GET. Opening the URL in a browser will show this. It says nothing about whether your setup works.

401 versus 403

The two are diagnostic, and the difference matters:

  • 401 — the token was rejected. It's missing, malformed, expired, or wrong.
  • 403 — the token is valid and authentication succeeded, but your account isn't entitled to that sport or resource. Check your plan in the API Locker, or contact support.

A 403 is therefore good news about your credentials.

Still stuck

Email support@rolling-insights.com with what you tried and what you see — mention you're using Cursor. Please don't include your token.