Set up the LaunchDarkly MCP Server

Decide before setup: hosted or local

LaunchDarkly offers the MCP server in two official variants. For standard instances, the provider recommends the hosted server at https://mcp.launchdarkly.com/mcp/launchdarkly, which needs no local installation and authorizes through OAuth consent. For EU or Federal instances, the hosted server is not available per the documentation; here the local, self-managed server via the @launchdarkly/mcp-server npm package is the documented path.

Connect the hosted server (recommended)

The simplest way in is the install page at https://mcp.launchdarkly.com/mcp/launchdarkly/install, which connects the client without a manual configuration file. Alternatively, add the endpoint manually — in Cursor via Settings → MCP Tools → Custom MCP, in Claude Code via the claude mcp add command, or in Windsurf via the mcp_config.json file. After saving, the client opens an OAuth consent window; sign in with your LaunchDarkly account there and authorize access to the desired project.

Set up the local server (for EU/Federal or without OAuth access)

First, generate an API key with the Writer or Developer role — not full administrator rights — through the authorization page in your LaunchDarkly account. Then add the following to the client's MCP configuration:

{
  "mcpServers": {
    "launchdarkly": {
      "command": "npx",
      "args": [
        "-y", "--package", "@launchdarkly/mcp-server", "--",
        "mcp", "start", "--api-key", "<YOUR_API_KEY>"
      ]
    }
  }
}

For Federal or EU instances, the server must additionally authenticate against https://app.launchdarkly.us or https://app.eu.launchdarkly.com instead of the default https://app.launchdarkly.com; the specific environment variable for this is documented in the repository (RUNTIMES.md and the README). Standalone binaries from GitHub releases and a Docker image via AWS Marketplace or ECR are also available.

Verify the connection with a read task

Before write actions such as creating or deleting a flag, run a harmless test request first, such as: "List all feature flags in project X." Once the expected project is correctly recognized, tasks like adjusting a targeting rule or checking the rollout status of a specific flag become reasonable next steps.

Keep permissions minimal

Because feature flags directly control the behavior of production applications, the API key or authorized account used should hold only the minimum necessary permissions. LaunchDarkly explicitly recommends the Writer base role or the predefined Developer preset role for this. Test write changes on non-critical flags or in a test environment first, before they affect production rollouts.