create-ai-config
Creates a new AI Config within a project. Useful for setting up LLM configurations programmatically.
LABSCO SUMMARY
It answers whether a flag is safe to remove, not just how to remove it.
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.
What it is
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.
What you get
- 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
Requirements
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.
Setup effort
One command plus a key — npx -y --package @launchdarkly/mcp-server -- mcp start --api-key $LD_ACCESS_TOKEN, then supply credentials
USE CASES
01
Deciding whether an old flag can finally be deleted
Check its lifecycle status from actual evaluations, see which repositories still reference it, and remove it once both say it is dead.
02
Shipping a change behind a flag
Create the flag with its variations, see which environments exist and which are critical, and set the targeting rules for the rollout.
03
Working out why someone is seeing the wrong variation
Read the flag's full configuration including its per-environment targeting, then check the audit log for what changed recently.
04
Taking stock of a project's flags
List them all with their metadata, then pull lifecycle status for the ones that look abandoned.
05
Setting up a model configuration you can change without deploying
Create the AI Config, add the variations you want to compare, and target which users get which.
06
Adjusting an AI Config that is already live
Read its current variations and model settings, update the one that needs changing, and check who it is targeted at.
20 tools
Counted once with only startup setup. Other versions, modes or optional credentials may expose a different list.
create-ai-config-variation
Adds a new variation to an AI Config, supporting experimentation or multi-model strategies.
create-feature-flag
Creates a new feature flag within a project. AI agents can use this operation to define feature toggles for controlled rollouts, experimentation, or gated features, automating the flag setup process.
delete-ai-config
Deletes an AI Config and its associated variations. Intended for cleanup or deprecation workflows.
delete-ai-config-variation
Deletes an AI Config variation.
delete-feature-flag
Removes a feature flag from the project. Used by AI agents to clean up deprecated toggles that are no longer in use, improving system hygiene and maintainability.
get-ai-config
Retrieves details of a specific AI Config, including variations and model settings.
get-ai-config-targeting
Retrieves the targeting details of a specific AI Config, including individual targets, rules, and rollouts.
get-ai-config-variation
Retrieves an AI configuration variation.
get-audit-log-entries
Fetches audit log entries for a LaunchDarkly account. Use the spec parameter with format proj/<projectKey>:env/<envKey>:flag/<flagKey> to query a specific flag's change history (use env/* for all environments). The before and after parameters accept Unix epoch timestamps in milliseconds for date-range filtering. Returns at most 20 entries per call, ordered newest-first.
get-code-references
Identifies which repositories have code references to a given flag, helping agents determine if they're operating on the correct repository and understand the scope of cleanup (single vs multi-repo).
get-environments
Identifies which environments exist in a project and determines which are marked as "critical" (production, staging, etc.). Allows agents to programmatically identify critical environments instead of hardcoding assumptions.
get-feature-flag
Fetches the full configuration for a specific feature flag, including environments, variations, and targeting rules. Useful for agents auditing or managing specific feature toggles in a detailed, contextual manner.
get-flag-status-across-environments
Returns lifecycle status (new, active, inactive, launched) based on actual usage patterns, evaluation counts, and configuration stability. This is the key intelligence for removal readiness assessment.
list-ai-configs
Retrieves AI configuration settings for a specific project. This endpoint allows agents to access and modify AI-related configurations, ensuring that the AI's behavior aligns with project requirements and user expectations.
list-feature-flags
Retrieves all feature flags within a project, including metadata and targeting rules. Enables AI agents to enumerate existing flags for inspection, configuration analysis, or generating flag usage reports across environments.
update-ai-config
Updates metadata or configuration of an existing AI Config.
update-ai-config-targeting
Updates the targeting of an existing AI Config.
update-ai-config-variation
Updates a specific variation within an AI Config. Enables fine-tuned control of model behavior.
update-feature-flag
Updates the configuration of an existing feature flag. Enables agents to change targeting rules, modify variations, or adapt rollout strategies dynamically in response to user behavior or experiment results.
BEFORE YOU INSTALL
What to know first
Tools you get
20 tools when we connected. LaunchDarkly's hosted server is more feature-complete and updated more often than this self-managed one. The documentation uses camelCase method names; registered tools are kebab-case.
Requires
npx on PATH
CONTEXT COST
Moderate Standing cost
Rated by the size of the 20 tool definitions that ride along on every turn, not by how many there are
INSTALLATION
Connect your client
Server setup
TERMINAL
npx -y --package @launchdarkly/mcp-server -- mcp start --api-key $LD_ACCESS_TOKENMCP Clients
Cursor, Claude Desktop
JSON
{
"mcpServers": {
"LaunchDarkly": {
"command": "npx",
"args": [
"-y",
"--package",
"@launchdarkly/mcp-server",
"--",
"mcp",
"start",
"--api-key",
"<YOUR_API>"
]
}
}
}<YOUR_API> is your LaunchDarkly API access token, as found on LaunchDarkly's Authorization page.
Qodo Gen
Open the Qodo Gen chat panel in VSCode or IntelliJ -> Connect more tools -> + Add new MCP -> paste -> Save
QODO GEN · JSON
{
"mcpServers": {
"LaunchDarkly": {
"command": "npx",
"args": [
"-y",
"--package",
"@launchdarkly/mcp-server",
"--",
"mcp",
"start",
"--api-key",
"<YOUR_API>"
]
}
}
}<YOUR_API> is your LaunchDarkly API access token, as found on LaunchDarkly's Authorization page.
GitHub Copilot
In the Copilot CLI, run /mcp add to add the server interactively, or create/edit ~/.copilot/mcp-config.json with the following content
GITHUB COPILOT · JSON
{
"mcpServers": {
"LaunchDarkly": {
"command": "npx",
"args": [
"-y",
"--package",
"@launchdarkly/mcp-server",
"--",
"mcp",
"start",
"--api-key",
"<YOUR_API>"
]
}
}
}<YOUR_API> is your LaunchDarkly API access token, as found on LaunchDarkly's Authorization page.
Any MCP client — local build
Clone and build it
Once cloned, you'll need to install dependencies (npm install) and build the server (npm run build).
ANY MCP CLIENT — LOCAL BUILD · TERMINAL
git clone https://github.com/launchdarkly/mcp-server.git
cd mcp-server
npm install
npm run buildPoint your client at your clone
Configure your server definition to reference your local clone.
ANY MCP CLIENT — LOCAL BUILD · JSON
{
"mcpServers": {
"launchdarkly": {
"command": "node",
"args": [
"<YOUR_PATH_TO_MCP_SERVER>/bin/mcp-server.js",
"start",
"--api-key",
"<YOUR_API>"
]
}
}
}
