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
Codex 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'
Then open a new terminal, or source the profile, so the variable is live in the session you start Codex from — the terminal you run codex in, or the terminal you launch your editor from for the IDE extension.
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 Codex 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
Append this block to ~/.codex/config.toml — don't rewrite the file, so any servers you already have are preserved:
[mcp_servers.datafeeds]
url = "https://mcp.datafeeds.rolling-insights.com/mcp"
bearer_token_env_var = "RSC_TOKEN"
This one file configures every Codex surface: the CLI, the IDE extension, and the ChatGPT desktop app all read the same url and bearer_token_env_var fields. In the IDE extension you can also manage MCP servers from the gear menu — either way the config lands in the same place.
The /mcp path is required — the bare hostname will not work. Codex does no string interpolation here: bearer_token_env_var names the variable, and Codex reads its value at run time, so the token never appears in the file — not even as an expanded string.
4. Verify
Restart Codex so it picks up the new server — the CLI does on its next run, and the IDE extension needs an explicit restart. Then ask for live data:
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 Codex 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 codex -y
-a scopes the skill to Codex, 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 Codex was launched from.
The failure is quiet, because there is nothing in the exchange that tells Codex 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.
Remember that bearer_token_env_var names a variable; it does not carry a value. If RSC_TOKEN doesn't exist in the environment Codex runs in, there is nothing to read, and every call fails with a rejected token even though the config looks correct.
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 restart Codex from there — it inherits the environment of the shell that launched it.
The IDE extension doesn't list the server
A known detection gap: the extension can miss servers that codex in the terminal already sees, because it only reads ~/.codex/config.toml when it starts. Restart the extension (or the editor) and it picks the server up — the config is shared, so there is nothing to re-add. The gear menu's MCP view shows what the extension currently sees.
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/mcppath. {"status":"ok"}but Codex still can't connect — the server is fine and the problem is the token or the config syntax.
GET /mcp returns 405
GET /mcp returns 405Expected, 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 Codex and which surface (CLI, IDE extension, or desktop app). Please don't include your token.