Stale flags accumulate because nobody can cheaply establish whether anything still evaluates them — get-flag-status-across-environments derives that from real evaluation counts and get-code-references shows which repositories still mention it, which turns cleanup into a decision rather than a gamble. The environment tooling serves the same instinct: critical environments are labelled, so a targeting change can be checked against where it is landing before it lands.
LaunchDarkly's own server, covering feature flags and AI Configs. Alongside the flag CRUD it answers the two questions that make a flag change safe: which environments are critical, and where the flag is still referenced.
- list-feature-flags enumerates a project's flags with metadata and targeting rules; get-feature-flag returns one in full, including environments, variations and rules
- create-feature-flag, update-feature-flag and delete-feature-flag cover the lifecycle, with updates able to change targeting rules and variations
- get-flag-status-across-environments reports lifecycle status — new, active, inactive, launched — derived from actual evaluation counts rather than from what someone wrote in the description
- get-code-references identifies which repositories still reference a flag, which is what tells you whether removing it is safe
- get-environments lists a project's environments and which are marked critical, so production and staging are distinguishable before a change lands
- get-audit-log-entries fetches audit history, scoped by a spec such as proj/<projectKey>:env/<envKey>
- AI Configs as their own family: listed, created, read, updated and deleted, with variations added, read, updated and deleted for multi-model or experimental setups
- get-ai-config-targeting and update-ai-config-targeting handle who gets which AI Config — individual targets, rules and rollouts
A LaunchDarkly account and an API key from its Authorization page, passed as --api-key on the start command; clients that support it can read that from an environment variable instead of writing the key into the config file. It runs as npx -y --package @launchdarkly/mcp-server -- mcp start, with a standalone binary from GitHub releases and a Docker image as alternatives. The key's own permissions decide what it can do — flag deletion and targeting changes are real changes to what your users see.
One command plus a key — npx -y --package @launchdarkly/mcp-server -- mcp start --api-key $LD_ACCESS_TOKEN, then supply credentials