Statsig MCP Server Cursor IDE Setup 2026: OAuth Deeplink vs Console API Key

How do you set up the Statsig MCP server in Cursor? Statsig hosts its own MCP endpoint at https://api.statsig.com/v1/mcp. The recommended path is OAuth: add a minimal url-only entry to ~/.cursor/mcp.json, restart Cursor, and sign into your Statsig account when prompted — Cursor handles the OAuth exchange automatically. If your Cursor version doesn't support OAuth-based remote servers well, fall back to a Console API key passed through the mcp-remote proxy instead.

Statsig is a feature-flagging and experimentation platform — think of it as sitting in the same category as LaunchDarkly, covered in this site's LaunchDarkly MCP guide, though the two platforms don't share a config format or tool set. This guide covers Statsig's own hosted server, not a community reimplementation.

What the Statsig MCP Server Does

Connected in Cursor, the agent can work with Statsig's experimentation and feature-gate primitives directly from chat:

Because experiment and gate creation are write operations, the same caution that applies to any write-capable MCP server applies here: an agent that can create an experiment can also misconfigure one, and a live experiment affecting real users is a worse place for a mistake to land than most other MCP-connected systems on this site.

Prerequisites

Method 1: OAuth (Recommended)

Step 1: Add the Minimal Config

Open ~/.cursor/mcp.json and add:

{
  "mcpServers": {
    "statsig": {
      "url": "https://api.statsig.com/v1/mcp"
    }
  }
}

No token, header, or command needed at this stage — the URL alone is enough to trigger Cursor's OAuth flow on first use.

Step 2: Restart Cursor and Authorize

Restart Cursor completely, then go to Settings → Cursor Settings → Tools & Integrations to confirm the statsig entry appears. The first time you actually use it in chat, Cursor prompts you to sign into your Statsig account and authorize the MCP server to access your Statsig project. Complete that browser flow once; Cursor manages the resulting session from there.

Step 3: Verify

List the feature gates in my Statsig project and tell me which ones are at 100% rollout.

A response naming real gates confirms both the connection and the OAuth authorization succeeded.

Method 2: Console API Key via mcp-remote (Fallback)

If your Cursor build doesn't handle the OAuth-based remote entry cleanly, or you'd rather use a static credential for a scripted setup, generate a Console API key at console.statsig.com/api_keys and configure the mcp-remote proxy instead:

{
  "mcpServers": {
    "statsig": {
      "command": "npx mcp-remote https://api.statsig.com/v1/mcp --header statsig-api-key:${AUTH_TOKEN}",
      "env": {
        "AUTH_TOKEN": "console-your-real-console-api-key"
      }
    }
  }
}

mcp-remote exists specifically to bridge clients that expect a local command entry to a server that's actually a remote HTTP endpoint — the same pattern shows up across several hosted MCP servers on this site, not just Statsig's. Statsig's own docs note that OAuth-based authentication is the preferred path over long-lived API keys precisely because it supports scoped access and easier permission management; treat the API-key path as the compatibility fallback, not the default choice.

Practical Workflows

Checking experiment status before a standup

List all currently running experiments and tell me which ones started more than 30 days ago — those are candidates for a decision meeting.

Auditing gate rollout state

Show me every feature gate at less than 100% rollout, along with their current percentage, so I know what's still ramping.

Standing up a new experiment from a description

Create a new experiment testing a 10% vs 90% split for the new onboarding flow, targeting only users on the web platform.

Review the generated configuration in the Statsig console before letting it actually start — treat this the same way you'd treat any AI-generated config touching production traffic.

Pulling gate details for a specific rollout

Get the full targeting rules for the gate named "new-checkout-flow" and tell me which user segments currently see it enabled.

Troubleshooting

OAuth prompt never appears
Confirm your Cursor build actually supports OAuth-based remote MCP entries — check Settings → Cursor Settings → Tools & Integrations for the statsig entry's status. Older Cursor versions that predate reliable remote-OAuth support should use Method 2's mcp-remote fallback instead.

"Unauthorized" using the Console API key path
Confirm the key actually starts with console- and was copied without a trailing newline or space. Also confirm your org owner has Console API access enabled in organization settings — Statsig gates this even for a key that otherwise looks valid.

Connected but can't see an experiment you know exists
The connection inherits whatever permissions the authenticated account (OAuth) or the Console API key's owning account (API-key path) actually has in Statsig. If your role can't see a given project or experiment in the Statsig console itself, the MCP connection can't see it either.

Server entry shows in mcp.json but never appears in Cursor's tool list
Restart Cursor fully rather than just reloading the window — remote MCP entries in Cursor are more sensitive to a full restart picking up config changes than some local command-based servers are.

Frequently Asked Questions

Q: Is the Statsig MCP server official, or a community integration?
A: Official — Statsig hosts and documents it directly at api.statsig.com/v1/mcp, with setup instructions published on Statsig's own docs site, not a third-party reimplementation.

Q: Should I use OAuth or a Console API key?
A: OAuth is Statsig's recommended default — it supports scoped access and is easier to manage permissions for than a long-lived static key. Use the Console API key path only as a fallback when your Cursor build doesn't handle the OAuth-based remote entry well.

Q: Can the MCP server create experiments, or only read existing ones?
A: Both. The tool set includes creating new experiments and inspecting existing ones, along with listing and inspecting feature gates. Treat experiment-creation calls as write operations affecting real user traffic and review generated configs before they go live.

Q: Does this replace the Statsig console for managing experiments?
A: For quick lookups, status checks, and drafting new experiment configurations from a description, yes. For fine-grained rollout scheduling, metric configuration, and anything meant for broader team visibility, the Statsig console remains the more complete tool.

Q: How is this different from the LaunchDarkly MCP setup on this site?
A: Both are feature-flagging platforms with their own official MCP servers, but the config shape and tool sets aren't interchangeable — Statsig's hosted endpoint favors OAuth with an mcp-remote fallback, while LaunchDarkly's integration follows its own auth and tool conventions. See the LaunchDarkly MCP server guide if you're comparing the two rather than committed to Statsig already.

Q: Do I need org owner permissions to set this up myself?
A: Not necessarily to use it, but your org owner needs to have enabled Console API access in organization settings first — that's a prerequisite Statsig applies at the org level, independent of which individual sets up the Cursor connection.

Related Guides

Official docs cited