LaunchDarkly MCP Server Cursor IDE Setup (2026)

How do you set up the LaunchDarkly MCP server in Cursor? LaunchDarkly publishes an official server, @launchdarkly/mcp-server, in two forms: a local one you run with npx and an API access token, or a hosted OAuth server at mcp.launchdarkly.com that needs no key at all. Pick the local route if you want a self-managed, individually revocable credential; pick hosted if you'd rather authorize once in a browser and skip token management. Once connected, Cursor can list and toggle feature flags, inspect targeting rules, and query observability data — logs, traces, errors — without you leaving the editor for the LaunchDarkly dashboard.

The reason this is worth wiring up rather than just checking the dashboard by hand: flag state and observability data live in different systems in most stacks, and correlating "did the error spike start right after we flipped this flag to 50%" normally means two browser tabs and manual timestamp-matching. With both surfaces reachable from one chat session, that correlation becomes a single prompt.

What You Can Do With LaunchDarkly MCP in Cursor

Toggling a flag through an AI chat session is a real production action, not a read-only lookup — treat prompts that change targeting rules with the same caution as a manual dashboard edit, especially against a production environment.

Prerequisites

Method 1: Hosted OAuth Server (No Token to Manage)

Add this to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "launchdarkly": {
      "url": "https://mcp.launchdarkly.com/mcp/launchdarkly",
      "headers": {}
    }
  }
}

Restart Cursor. On the first tool call, it opens a browser window for LaunchDarkly's OAuth authorization — approve it, and the session persists without a secret sitting in your config file. This is the simpler option for most individual developers, and the one to reach for unless you're specifically on a federal/EU LaunchDarkly instance, where it isn't available.

Method 2: Local Server with an API Access Token

Step 1: Create a LaunchDarkly API Access Token

1. In LaunchDarkly, go to Account Settings → Authorization → Access tokens
2. Click Create token
3. Name it something identifiable, like cursor-mcp
4. Assign a role or custom role — for exploratory use, a reader-level role is enough; for toggling flags from chat, the token needs writer-level access to the specific projects/environments you want Cursor to modify
5. Copy the token (api-xxxxxxxx-...) — it's shown once

Scope the role deliberately. A token with account-admin-level access lets Cursor (and anything that can reach your MCP config) touch every project and environment in the account, not just the one you're actively working in.

Step 2: Add the Local Server to mcp.json

{
  "mcpServers": {
    "LaunchDarkly": {
      "command": "npx",
      "args": [
        "-y",
        "--package",
        "@launchdarkly/mcp-server",
        "--",
        "mcp",
        "start",
        "--api-key",
        "api-xxxxxxxx-your-real-token-here"
      ]
    }
  }
}

The token is passed as a --api-key CLI argument to the mcp start command rather than as an env variable — a different pattern than most other API-key-based MCP servers on this site, which typically use an env block. Match this shape exactly; swapping it for an env-based LAUNCHDARKLY_API_KEY entry (the pattern you'd guess by analogy) won't work with this package.

Step 3: Restart Cursor and Verify

Fully quit and reopen Cursor. In chat, try:

List the feature flags in my default LaunchDarkly project

or

Show me the current targeting rules for the checkout-redesign flag

A response naming real flags or rules confirms the connection. If nothing comes back, re-check the token's role — a valid but under-permissioned token often fails silently on specific projects rather than throwing a clear "forbidden" error.

Practical Workflows

Correlate a flag change with an error spike

Show me any errors logged in the last hour, then check whether the checkout-redesign flag was toggled or had its rollout percentage changed around the same time

Gradual rollout, monitored

Increase the rollout percentage for the new-search-ui flag from 10% to 25% in the production environment, then show me the error rate for the next 15 minutes

Pre-launch flag audit

List every flag in the production environment that's been at 100% rollout for more than 30 days — those are candidates for cleanup, not active experiments

Debugging a "why is this user seeing the old version" report

Look up how the checkout-redesign flag is currently targeted, and tell me which segment or rule would apply to a user with attribute plan=free

Flag Cleanup Is a Real Maintenance Cost

Flags that stay at 100% rollout for months without being removed from the codebase are the most common source of LaunchDarkly technical debt — the flag adds a permanent branch to code that no longer needs to be conditional. Cursor's ability to list stale flags (see the pre-launch audit prompt above) is useful for surfacing cleanup candidates, but removing the flag still means editing the code that references it and re-testing the path that remains — the MCP connection surfaces the debt, it doesn't pay it down for you.

Troubleshooting

OAuth popup never appears (hosted server)
Confirm you're not on a federal or EU LaunchDarkly account — the hosted server isn't available there. Those accounts need the local, token-based server instead.

"Forbidden" on some flags but not others
The API token's role scopes it to specific projects and environments. If it can't see or modify a flag in the LaunchDarkly UI under that role, the MCP server can't either — this is LaunchDarkly's permission model working as intended, not an MCP bug.

Server won't start locally
Double-check the --api-key flag is present in args with a real token value, not left as a placeholder. Because the token is a CLI argument rather than an env variable here, a typo in the flag name (--api-key vs --apikey) silently breaks the command rather than producing an obvious config error.

Flag toggled but the app still shows the old behavior
Most LaunchDarkly SDKs cache flag state client-side with a refresh interval or streaming connection. A toggle via MCP updates LaunchDarkly's backend immediately, but a running application may take a few seconds (streaming) to a full refresh cycle (polling) to reflect it — this isn't a broken MCP connection, it's normal SDK caching behavior.

Can't tell which environment a change actually applied to
LaunchDarkly projects have multiple environments (production, staging, test) with independent flag states. Always specify the environment explicitly in a prompt that changes targeting — "toggle X in production" not just "toggle X" — since an ambiguous request can default to whichever environment the token or prior context implies, not necessarily the one you meant.

Frequently Asked Questions

Q: Should I use the hosted OAuth server or the local npx-based one?
A: The hosted server (mcp.launchdarkly.com) is simpler for most individual developers — no token to generate or rotate, authorize once in a browser. Use the local server if you're on a federal or EU LaunchDarkly account (hosted isn't available there), need the server to run in a non-interactive environment, or want a token you can scope, audit, and revoke independently of an OAuth grant.

Q: What permissions does the API token need to toggle flags, not just view them?
A: A reader-level role is enough to list flags and view targeting rules. Toggling flags or editing targeting rules needs a writer-level role (or a custom role with the specific flag-update permission) scoped to the project and environment you want Cursor to modify. Scope it to only what you need — an account-admin token grants far more reach than most workflows require.

Q: Can this MCP server accidentally roll out a flag to 100% in production?
A: Only if the token has write access to that environment and a prompt explicitly requests it. Treat any prompt that changes rollout percentages or targeting rules in a production environment with the same caution as a manual dashboard edit — review what Cursor is about to do before confirming, especially with a broadly-scoped token.

Q: Why did my flag toggle in LaunchDarkly's dashboard but my running app hasn't picked it up yet?
A: SDK caching. Streaming-connected SDKs typically reflect a change within seconds; polling-based SDKs wait for their next refresh interval. This delay is expected behavior in LaunchDarkly's architecture, not a sign the MCP toggle failed — check the flag's current state directly in the dashboard or via another Cursor prompt to confirm the backend change actually took effect.

Q: Does this replace checking the LaunchDarkly dashboard entirely?
A: For quick lookups and routine toggles inside a coding session, mostly yes. For anything involving multiple stakeholders, audit history review, or a rollout you want to watch in real time with the visual percentage-ramp UI, the dashboard is still the better tool — MCP is for keeping flag state in reach while you're heads-down in code, not a full replacement for LaunchDarkly's UI.

Related Guides

---