Install

Report a missing capability, bug, parameter gap, or unclear error encountered while using LaunchDarkly MCP tools. This feedback is collected and triaged to improve the toolset. Use this when a tool is missing, returns an unexpected error, or lacks a needed parameter.

Get all stored instances of a specific context by kind and key. Returns every recorded occurrence of the context, including its full attribute set (e.g., merchantCountryCode, disbursementRail) and which SDK/application reported each instance. Use search-contexts to find a context key, then use this tool to inspect its full attribute history across all SDK applications. Pagination: responses include `totalCount` and `continuationToken`. Pass `continuationToken` from the previous response to get the next page.

Search for stored LaunchDarkly contexts in an environment by kind, key, or attribute value. Returns context records including their stored attributes (e.g., merchantCountryCode, disbursementRail) and when the context was last seen. Convenience param: - `kind`: filter to a specific context kind (e.g. `Merchant`, `user`, `organization`). Emitted as the filter clause `kind equals "<kind>"`. Raw filter syntax (passed in `filter`) uses `field operator value` clauses. Operators: `equals`, `notEquals`, `anyOf`, `contains`, `startsWith`, `exists`, `before`, `after`. Combine clauses with `,` (AND) or `|` (OR); group with `()`. Supported fields: `kind`, `key`, `kindKey`, `name`, `applicationId`, `id`, `q` (fuzzy), and `<kind>.<attribute>` for context attributes. Examples: - `kind equals "Merchant"` — contexts of a specific kind - `Merchant.merchantCountryCode equals "US"` — Merchant contexts whose attribute matches - `key startsWith "merchant-"` — contexts whose key has a prefix - `applicationId equals "GoSDK/1.2"` — contexts reported by a specific SDK/application Example combining both params: set `kind=Merchant` and `filter=Merchant.disbursementRail equals "PIX"` to find Merchant contexts on the PIX rail. Note: the contexts API cannot filter by which flag a context evaluated; there is no `flagEvaluated` field. Filter by kind, key, applicationId, or attribute values instead. Sorting: `ts` (oldest first) or `-ts` (newest first, default). Pagination: responses include `totalCount` and `continuationToken`. Pass `continuationToken` from the previous response to get the next page.

Get a time series of service connection minutes from your LaunchDarkly account. Use this for capacity planning, cost analysis, and before/after deploy comparisons (e.g. compare daily incremental minutes around a deploy date). TIME RANGE: Pass `from` and `to` as Unix millisecond timestamp strings. Both default to the current month. Maximum range is 365 days. AGGREGATION TYPES: - 'month_to_date' (default): cumulative minutes from the start of the month to each data point - 'incremental': delta minutes for each granularity period — use this for deploy comparisons GRANULARITY: - 'daily' (default): one data point per day - 'hourly': one data point per hour (useful for same-day deploy impact) - 'monthly': one data point per month (only with aggregationType='month_to_date') FILTERING: Pass `projectKey`, `environmentKey`, `connectionType`, `sdkName`, `sdkVersion`, or `sdkType` arrays to narrow results. When filtering by `environmentKey`, exactly one `projectKey` must also be provided. GROUPING: Pass `groupBy` array to split results by dimension. Valid values: projectId, environmentId, connectionType, relayVersion, sdkName, sdkVersion, sdkType. EXAMPLE — compare May 21 vs Jun 29 deploys: aggregationType='incremental', granularity='daily', from='<ms for May 1>', to='<ms for Jul 1>', environmentKey=['production']

Resolve which release policies would govern a flag in a given environment — a read-only dry-run of the server-side policy matching logic. Does not create or modify anything. Two modes: - `flagKey` (existing flag): calls the server-side release-settings endpoint, which returns the authoritative resolved policy for that flag+environment. - `flagTags` (pre-creation preview): performs client-side matching against all project release policies using the proposed tag set — useful before the flag exists. If both are supplied, `flagKey` wins and the server-side path is used. Returns: - `matchingPolicies` — all policies whose scope matches (sorted by rank ascending, with default rank -1 last); for the flagKey path this contains just the server-resolved winning policy if one exists - `winningPolicy` — the resolved match, or null - `winningReleaseMethod` — release method of the winning policy, or null - `autoAttachedMetricKeys` / `autoAttachedMetricGroupKeys` — metrics that would auto-attach - `warnings` — missing or incomplete policy configuration that must be shown in generated comments; if present, do not state the release plan as a clean policy rollout - `criteria` — echo of the inputs used Use cases: 1. After flag creation: explain which policy governs the flag in this environment 2. Before flag creation: preview which policy would apply given proposed tags

Record an automated rollout config in LaunchDarkly for a feature-flagged change. Use this only for AutomatedRollout requests. The guarding feature flag must already exist in LaunchDarkly. Works for both an existing PR the user points you at and a PR you just filed. PER-ENVIRONMENT RELEASE TYPES: - "override" (default): Pins the exact rollout inline via the optional `override` object. With no `override` object it is an immediate release — the flag turns on once it begins evaluating, the same trigger as guarded and progressive releases, just with no stages to ramp through. - "policy": Waits until the PR is merged and the flag begins evaluating, then resolves the environment's configured release policy and performs the appropriate release according to that policy. Do not pass an `override` object with "policy". The response includes `warnings` if a policy environment has no matching policy or the winning policy is missing stages/metrics; render those warnings in generated comments and do not state the release as a clean policy rollout. Do not add tags automatically to make a policy match. OVERRIDE METHODS (the `override.releaseMethod` field, only for releaseType "override"): - "immediate": Turn the flag on. Omit stages/metrics/rollback. Equivalent to omitting `override`. - "progressive": Ramp the true variation through `stages`. Requires a non-empty `stages` array. - "guarded": Measured rollout through `stages`, gated on metrics, with optional auto-rollback. Requires `stages` plus at least one of `metricKeys` / `metricGroupKeys`. STAGES: Each stage is { allocation, durationMillis }. allocation is basis points (100000 = 100%), must be positive and strictly increasing across stages; guarded caps every stage (including the last) at 50000 (50%) — a guarded rollout auto-promotes to 100% after its last monitored stage completes without regression, so don't add a 100000 stage yourself. Progressive has no such cap and typically ends with an explicit 100000 stage to reach full rollout. durationMillis is each stage's monitoring window in milliseconds and must be > 0 for every stage without exception, including the last one in the array — a zero or omitted duration there is rejected, even though nothing ramps after it. INPUTS: - projectKey (required): LaunchDarkly project key (e.g., "default"). - flagKey (required): Key of the guarding feature flag (must already exist). - environments (required): Per-environment rollout plan. Array of { environmentKey, releaseType?, override? } objects. `override` is { releaseMethod, rolloutContextKindKey?, stages?, metricKeys?, metricGroupKeys?, rollbackOnRegression? }. - repoFullName (optional): GitHub repo as "owner/repo". - prNumber (optional): PR number. - prUrl (optional): Full PR URL. - startingVariationId (optional): For a multi-variate flag, the id of the variation the flag rolls out from. If omitted, a boolean flag assumes the false variation. - endingVariationId (optional): For a multi-variate flag, the id of the variation the flag rolls out to. If omitted, a boolean flag assumes the true variation. A multi-variate flag requires both startingVariationId and endingVariationId to be set. RETURNS: - created: Boolean indicating success. - config_id: Identifier of the created rollout config. - flag_key: Echoed flag key. - environments: Normalized per-environment plan that was sent. - warnings: Advisory warnings for policy environments with missing or incomplete release policies. Example (immediate in staging, guarded in production): {"projectKey": "default", "flagKey": "new-checkout-flow", "environments": [{"environmentKey": "staging", "releaseType": "override"}, {"environmentKey": "production", "releaseType": "override", "override": {"releaseMethod": "guarded", "stages": [{"allocation": 10000, "durationMillis": 3600000}, {"allocation": 50000, "durationMillis": 3600000}], "metricKeys": ["checkout-error-rate"], "rollbackOnRegression": true}}], "repoFullName": "launchdarkly/gonfalon", "prNumber": 12345}

List LaunchDarkly projects in the account. Use to discover project keys before calling project-scoped tools. Filtering: use `query` to search by project name or key (case-insensitive), `tags` to filter by tag (all must match). Sorting: use `sort` with `name` or `-name`. Pagination: responses include `totalCount` and `pageInfo.offset`. To get the next page, set `offset` to the current offset + limit.

Query the audit log to find what changed in a LaunchDarkly account. Returns a chronological list of changes (newest first) with who made each change and what they did. USE THIS TOOL WHEN: - The user asks "what changed recently?" or "what happened in the last X hours/days?" - Investigating whether a flag change could have caused an incident - Looking for changes made by a specific person or to a specific environment OPTIONAL INPUTS: - projectKey: The LaunchDarkly project key (e.g., "default"). Scopes results to a single project. Omit to query across all projects (useful for account-level changes like member invites or project creation). - env: Environment key (e.g., "staging", "production"). Narrows results to changes affecting that environment. - resourceKind: Filter by resource type. Common values: "flag", "segment", "env", "project", "metric", "experiment", "aiconfig", "member", "role", "team", "integration", "webhook", "release-pipeline", "release-policy". Environment-scoped kinds (flag, segment, experiment, holdout, destination, aiconfig) automatically include the env segment. Account-level kinds (member, role, team, webhook, integration) do not require a projectKey. IMPORTANT: Always include resourceKind for best results. Without it, only changes to the project or environment resource itself are returned — not changes to child resources like flags or segments within it. For broad queries (e.g. "what changed recently?"), omit both projectKey and resourceKind to get all changes, or specify resourceKind: "flag" to see all flag changes in a project. - resourceKey: Specific resource key (e.g., a flag key). Requires resourceKind to be set. - tags: Array of tag strings to scope results (AND logic — resource must have ALL listed tags). Tags are supported on all resource types. Example: ["mobile", "v2"] narrows to resources tagged with both "mobile" AND "v2". - query: Full-text search across resource names (e.g., "dark-mode", "checkout"). - startDate: Start of time window in ISO 8601 format (e.g., "2024-06-10T00:00:00Z"). If omitted, no lower time bound is applied — the API returns the N most recent entries. - endDate: End of time window in ISO 8601 format. If omitted, no upper time bound is applied (effectively "now"). - limit: Number of entries to return (1-20). Defaults to 20. EXAMPLES: 1. All flag changes in staging: {"projectKey": "default", "env": "staging", "resourceKind": "flag"} 2. Flag changes in last 7 days: {"projectKey": "default", "resourceKind": "flag", "startDate": "2024-06-04T00:00:00Z"} 3. Changes to a specific flag: {"projectKey": "default", "resourceKind": "flag", "resourceKey": "dark-mode"} 4. Metric changes: {"projectKey": "default", "resourceKind": "metric"} 5. Member/team changes (account-level): {"resourceKind": "member"} 6. All recent changes (any resource): {} 7. Flag changes filtered by tags: {"projectKey": "default", "resourceKind": "flag", "tags": ["mobile"]} PAGINATION: When hasMore is true, the response includes a nextBefore timestamp. To fetch the next page, call again with endDate set to the nextBefore value (keep all other filters the same).

Add or remove individual context keys from a segment's included or excluded lists. Included targets always match the segment. Excluded targets never match, even if rules would include them. Supported kinds: addIncludedTargets, removeIncludedTargets, addExcludedTargets, removeExcludedTargets. Each instruction requires contextKind and values. If the environment requires approval, the response includes requiresApproval: true and the attempted instructions; call `create-approval-request` with the returned instructions to submit it for review.

Add, remove, or modify attribute-based targeting rules on a segment. Rules evaluate context attributes to determine segment membership. Clauses within a rule are ANDed; multiple rules use OR logic. Supported kinds: addRule, removeRule, addClauses, removeClauses, updateClause, addValuesToClause, removeValuesFromClause, reorderRules, updateRuleDescription, updateRuleRolloutAndContextKind. If the environment requires approval, the response includes requiresApproval: true and the attempted instructions; call `create-approval-request` with the returned instructions to submit it for review.

Get detailed configuration for a single segment in an environment. Returns rules, included targets, excluded targets, tags, and creation date. Use to verify segment state after creation or updates.

Create a new segment in a project environment. The segment is empty after creation — use update-segment-rules to add targeting rules or update-segment-targets to add individual context keys. Segment keys are immutable after creation: choose carefully.

List segments in a project environment. Returns a paginated list with rule counts and target counts. Use query to search by name or key, tags to filter by tag. Always list first to avoid creating duplicates. Sorting: use `sort` with `creationDate`, `name`, or `lastModified`; prefix with `-` for descending. Defaults to `-creationDate`. Pagination: responses include `totalCount` and `pageInfo.offset`. To get the next page, set `offset` to the current offset + limit.

Permanently delete a prompt snippet. THIS IS IRREVERSIBLE. Any AgentControl Config variations referencing this snippet will lose their reference. Requires confirm=true to execute.

Update an existing prompt snippet. Creates a new version of the snippet. All fields are optional — only provided fields are updated.

Create a new prompt snippet. A snippet is a reusable text block that can be referenced in AgentControl Config variation prompts using {{snippet-key}} syntax. Provide a unique key, display name, and the text content.

Get a specific prompt snippet by key. Returns the snippet's name, text content, tags, version, and creation time.

List prompt snippets in a project. Prompt snippets are reusable text blocks that can be referenced inside AgentControl Config variation prompts to keep common instructions consistent. Returns key, name, text, version, and tags.

Update an LLM playground's name, variants, or archived status. All fields are optional.

Create a new LLM playground. A playground lets you compare AgentControl Config variations side-by-side. Provide a name and variants — each variant references an evaluation definition (by evaluationId) and a display position.

Get details about a specific LLM playground, including its variants (evaluation definitions and their positions).

List LLM playgrounds in a project. Returns playground names, variant counts, and timestamps. Supports search by name and pagination.

Get the summary results of a completed evaluation run, including pass/fail counts and aggregate scores.

Start a new run of an AI evaluation. This executes the evaluation against the configured dataset and judge criteria. Returns the run ID and status.

Create a new AI evaluation definition. An evaluation defines a comparison between AgentControl Config variations using a dataset and judge criteria. After creation, use run-evaluation to start an evaluation run.

Get details about a specific evaluation definition, including its configuration and last run status.

List AgentControl Config evaluations in a project. Returns evaluation definitions with their names, associated config keys, and last run info.

Permanently delete an offline dataset and its associated metadata. THIS IS IRREVERSIBLE. Requires confirm=true to execute.

Create a new offline dataset for AI evaluation. Provide a dataset name, filename, and format (csv, json, or jsonl). The dataset is created in pending status and must be uploaded separately. Returns the dataset ID and upload URL.

Get details about a specific offline dataset by ID, including its processing status and row count.

List offline datasets for a project. Returns id, name, status, row count, and creation info for each dataset. Datasets can be in pending, processing, completed, or failed status.

Stop an active guarded rollout on a flag's default rule (fallthrough). This immediately halts the progressive rollout and locks the flag to its current state. If the environment requires approval, the response includes requiresApproval: true and the attempted instructions; call `create-approval-request` with the returned instructions to submit it for review.

Start a guarded rollout on a flag's default rule (fallthrough). A guarded rollout progressively increases traffic to the test variation through a series of stages while monitoring metrics for regressions. Each stage specifies a rolloutWeight (percentage in thousandths, e.g. 10000 = 10%) and a monitoring window in milliseconds. Metrics define what to monitor and whether to notify or rollback on regression. Requires the flag to be on and not already have an active guarded rollout. If the environment requires approval, the response includes requiresApproval: true and the attempted instructions; call `create-approval-request` with the returned instructions to submit it for review.

Get detailed statistical results for a single metric on an experiment iteration. Returns, per treatment: sample sizes (analyzedUnitCount, trafficCount, conversionCount), the observed mean and standard deviation, and a `statistics` block with the lift versus control (relativeDifferences: estimate plus lower/upper interval bounds and, for frequentist experiments, a per-comparison pValue), the overall pValue, Bayesian probabilities (probabilityToBeBest, probabilityToBeatBaseline, expectedLoss), and an isSignificant flag. Reads from LaunchDarkly's internal analysis API. Defaults to the current iteration and the latest analysis; pass iterationId to target a previous iteration. Use disableMultipleComparisonCorrection / disableSequentialTesting to see uncorrected numbers. Use get-experiment-results for a cross-metric overview, or get-experiment to discover metric keys.

Get an overall results summary for an experiment, across every metric on the current iteration. Discovers the iteration's metrics, then fetches each metric's analysis from LaunchDarkly's internal results API and returns a compact per-metric summary: which treatment is leading (isBest) — the arm with the highest probability to beat the baseline for Bayesian experiments, or the lowest p-value versus control for frequentist (note: not significance-gated, so a treatment can be flagged leading even when nothing is significant) — each treatment's lift versus control, whether it's statistically significant, and sample sizes. Pass iterationId to summarize a previous iteration. For the full per-treatment statistics (intervals, p-values, Bayesian probabilities) on one metric, use get-experiment-metric-results.

Stop the currently running iteration of an experiment. Data collection ends and the iteration moves to the `stopped` status. A winning treatment is required to stop: pass `winningTreatmentId` (the `_id` of one of the iteration's treatments, available from get-experiment) and an optional `winningReason` explaining the call. If the experiment was inconclusive, declare the baseline/control treatment as the winner.

Stop the current running iteration, create a new draft iteration with the provided field updates applied, and start it — the API-recommended way to mutate treatments, metrics, methodology, or other fields that are locked while an iteration is running. Provide `changeJustification` to record why a new iteration is needed. Field inputs are the same as `update-experiment`; updates are checked against the new iteration's not_started mutability rules. Fields not allowed in not_started are returned under `skipped` rather than being sent.

Start an experiment iteration. This begins data collection for the experiment's current draft iteration. Use after creating an experiment to activate it, or after stopping a previous iteration. The experiment's flag must be toggled on, a randomization unit must be set, and at least one treatment must have a non-zero allocation percent.

Update fields on an experiment or its current iteration. Which fields are mutable depends on the current iteration's status (not_started, running, stopped). This tool first reads the experiment's mutableFieldsByStatus, applies only the updates that are allowed for the current status via the updateExperimentFields semantic patch, and returns any rejected fields under `skipped` with the reason. If no provided field is mutable, the response includes `currentStatus` and `allowedFields` so you can retry with valid inputs. Scalar fields: name, description, maintainerId, tags (string[]), hypothesis, attributes (slicing dimensions, string[]), methodology (bayesian|frequentist|export_only), analysisConfig, randomizationUnit, canReshuffleTraffic, primarySingleMetricKey, primaryFunnelKey, dataSource (launchdarkly|snowflake|databricks), holdoutId, covariateId. Structural fields (typically only mutable while iteration status is not_started; call get-experiment first to see current values): - metrics: array of { key, isGroup? }. Replaces the iteration's metric list. - treatments: array of { name, baseline, allocationPercent, parameters: [{ flagKey, variationId }] }. Exactly one treatment must have baseline=true; allocationPercents should sum to 100. - flags: object keyed by flag key with { ruleId, flagConfigVersion, notInExperimentVariationId? }. Use for the initial flag/rule attachment on a not_started iteration. - flagSettings: same shape as flags but only updates ruleId / flagConfigVersion / notInExperimentVariationId on already-attached flags (used on stopped iterations to rebind without changing flag keys).

Create a new experiment on a flag or AgentControl Config. An experiment measures the impact of different variations on specified metrics. You must provide the initial iteration definition including a hypothesis, metrics, treatments, and flag configuration. One treatment must be marked as the baseline. Use `methodology` to pick the results-analysis approach (`bayesian` default, `frequentist`, or `export_only` for data-export-only mode). Use `analysisConfig` to set thresholds and multiple-comparison correction. Use `iteration.attributes` to declare slicing dimensions and `iteration.covariateId` to enable stratified sampling. After creation, use start-experiment-iteration to begin collecting data.

Get detailed information about a specific experiment, including its treatments, metrics, and current iteration status.

List experiments in a project, optionally filtered by environment. Returns key, name, description, and current iteration status for each experiment. Filtering: - `flagKey`: filter experiments by the flag key they are attached to - `status`: filter by experiment status (e.g. `running`, `stopped`, `not_started`) Pagination: responses include `totalCount`. To get the next page, set `offset` to the current offset + limit.

Permanently delete an AI tool definition. THIS IS IRREVERSIBLE. Any AgentControl Config variations referencing this tool will lose the attachment. Requires confirm=true to execute.

Update an AI tool definition's description or schema. All fields are optional: only provided fields are updated. The schema should be a raw JSON Schema object with type, properties, and required fields.

Turn an AgentControl Config's targeting on or off in a specific environment. Returns the previous and new state. This is equivalent to 'turnFlagOn' / 'turnFlagOff' for feature flags. If the environment requires approval, the response includes requiresApproval: true and the attempted instructions; call `create-agentcontrol-config-approval` with the returned instructions to submit it for review.

Discover available data keys/dimensions for a product type. Use this tool BEFORE creating dashboards to understand what data fields are available for filtering and grouping. INPUTS: - projectKey (required): The LaunchDarkly project key (e.g., "default"). - productType (required): One of "logs", "traces", "sessions", "errors", "metrics", "events" - startDate (required): ISO format start date (e.g., "2024-01-15T10:00:00Z") - endDate (optional): ISO format end date (defaults to current time) - search (optional): Filter keys by name - limit (optional, default 25): Maximum number of keys to return RETURNS: - keys: Array of key objects with name and type - product_type: The queried product type - key_count: Number of keys returned Use the returned keys in: - create-graph groupBy parameter - Query filters Example usage: {"productType": "errors", "startDate": "2024-01-15T10:00:00Z"}

Preview a chart/graph inline WITHOUT saving it to a dashboard. Always use this tool first when a user asks to create or visualize a chart. Returns both the graph configuration and the queried metrics data so the user can see the chart rendered inline. After showing the preview, ask the user if they want to save it to a dashboard (using create-graph). REQUIRED INPUTS: - projectKey: The LaunchDarkly project key (e.g., "default"). - title: Chart title. - type: Chart type — "Line chart", "Bar chart", or "Table". - productType: Data source — one of "Logs", "Traces", "Sessions", "Errors", "Events", "Metrics" (case-insensitive aliases accepted). - expressions: Array of aggregations, each with { aggregator, column }. e.g. [{"aggregator": "Count", "column": ""}] for a raw count, or [{"aggregator": "P90", "column": "duration"}] for a percentile. Valid aggregators: Count, CountDistinct, CountDistinctKey, Min, Avg, P50, P90, P95, P99, Max, Sum. OPTIONAL INPUTS: - query: Filter string using search syntax, e.g. "level=error" or "service_name=api". - groupBy: Array of dimension keys, e.g. ["level"] or ["service_name", "level"]. Use get-keys to discover available keys. - bucketCount: Number of time buckets (default 12). - startDate: ISO start date. If neither startDate nor endDate is provided, defaults to the last 24 hours. - endDate: ISO end date. Defaults to now when startDate is provided without endDate. - display: Display style for bar charts, e.g. "Stacked" or "Grouped". RETURNS: - title, type, product_type, query, expressions, group_by, display: echoed graph configuration. - metrics: time-series buckets queried for the preview. - _hint: reminder that the UI renders the chart directly — do not emit markdown image syntax. Example — logs by level as a stacked bar chart: {"projectKey": "default", "title": "Logs by Level", "type": "Bar chart", "productType": "Logs", "expressions": [{"aggregator": "Count", "column": ""}], "groupBy": ["level"], "display": "Stacked"}

Add a chart/graph to an existing dashboard. IMPORTANT: Before creating a graph: 1. Use get-keys to discover available data dimensions 2. Use the data query tools (query-logs, query-traces, query-aggregations, query-error-groups, query-sessions) to verify data exists INPUTS: - projectKey (required): The LaunchDarkly project key (e.g., "default"). - dashboardId (required): ID of the dashboard to add the graph to - title (required): Chart title (e.g., "Error Rate by Service") - type (required): Chart type - one of: - "Line chart": For time-series trends (errors over time, latency trends) - "Bar chart / histogram": For comparisons (errors by service, requests by endpoint) - "Table": For detailed breakdowns with multiple dimensions - productType (required): Data source - one of: - "Logs": Log entries - "Traces": Distributed traces/spans - "Errors": Error groups - "Sessions": User sessions - "Metrics": Custom metrics - "Events": Product analytics events - expressions (required): Array of aggregations, each with: - aggregator: One of Count, CountDistinct, CountDistinctKey, Min, Avg, P50, P90, P95, P99, Max, Sum - column: Field to aggregate (empty string "" for Count, field name for others) - query (optional): Filter query string using search syntax - groupBy (optional): Array of dimension keys to group by - groupByLimit (optional, default 10): Maximum number of series to render when groupBy is set. High-cardinality dimensions (URLs, click selectors, account IDs) can produce hundreds of series and make the dashboard UI unresponsive — keep this small. Ignored when groupBy is empty. - limitAggregator (optional, default "Count"): Which aggregator to rank groups by when applying groupByLimit. Use the same aggregator you ranked by in query-aggregations. - limitColumn (optional): Column used alongside limitAggregator when ranking groups (e.g. "duration" for P90 latency ranking). Ignored for Count. - bucketBy (optional, default "Timestamp"): Field to bucket by for time-series - bucketCount (optional, default 12): Number of time buckets - display (optional): Display style - "Line", "Stacked", "Stacked area" CHART TYPE SELECTION GUIDE: - Use "Line chart" for: Error rates over time, latency percentiles, request volume trends - Use "Bar chart / histogram" for: Top errors by type, requests by endpoint, errors by browser - Use "Table" for: Detailed error listings, session breakdowns, trace details AGGREGATOR SELECTION GUIDE: - Count: Total number of events (most common) - CountDistinct: Unique values (users, sessions, trace IDs) - Avg/P50/P90/P95/P99: Latency and duration metrics (P95 for Web Vitals / Datadog-style SLOs) - Sum: Aggregate numeric totals NOTE: The backend does NOT currently accept P75. Use P90 or P95 instead if you need a high-percentile Web Vitals metric. Example - Error count over time: {"dashboardId": 12345, "title": "Error Count", "type": "Line chart", "productType": "Errors", "expressions": [{"aggregator": "Count", "column": ""}], "bucketCount": 24} Example - Top 10 errors by service: {"dashboardId": 12345, "title": "Errors by Service", "type": "Bar chart / histogram", "productType": "Errors", "expressions": [{"aggregator": "Count", "column": ""}], "groupBy": ["service_name"], "groupByLimit": 10}

Create a new empty dashboard (visualization) for organizing charts. IMPORTANT: Before creating a new dashboard: 1. Use list-dashboards to check if a similar dashboard already exists 2. Use get-keys to discover available data dimensions for the product types you want to chart INPUTS: - projectKey (required): The LaunchDarkly project key (e.g., "default"). - name (required): Name for the dashboard (e.g., "Frontend Errors Overview") - timePreset (optional, default "last_24_hours"): Default time range. Use format like "last_24_hours", "last_7_days", "last_30_days" RETURNS: - dashboard_created: Boolean indicating success - dashboard_id: ID of the created dashboard - dashboard_url: URL to view the dashboard - name: Dashboard name After creating a dashboard, use create-graph to add charts to it. Example usage: {"name": "API Performance Dashboard", "timePreset": "last_7_days"}

Get detailed information about a specific dashboard including all its graphs. Use this tool to understand the configuration of an existing dashboard. INPUTS: - projectKey (required): The LaunchDarkly project key (e.g., "default"). - dashboardId (required): The numeric ID of the dashboard RETURNS: - id: Dashboard ID - name: Dashboard name - time_preset: Default time range - dashboard_url: URL to view the dashboard - graphs: Array of graph configurations with type, title, expressions, etc. - graph_count: Number of graphs in the dashboard Example usage: {"projectKey": "default", "dashboardId": 12345}

List existing dashboards (visualizations) for the project. Use this tool to see what dashboards already exist before creating new ones. INPUTS: - projectKey (required): The LaunchDarkly project key (e.g., "default"). - search (optional): Filter dashboards by name - limit (optional, default 10): Maximum number of dashboards to return RETURNS: - dashboards: Array of dashboard objects with id, name, graph_count, updated_at, dashboard_url - total_count: Total number of matching dashboards Example usage: {"projectKey": "default", "search": "frontend"}

Query flag evaluations for a session. Retrieve flag evaluation events for a specific session to understand which feature flags were evaluated during that session. The tool always scopes results to the given session via secure_session_id and to feature flag events via events.name=feature_flag. Any additional filters (e.g. service_name) can be supplied via the optional query input. REQUIRED INPUTS: - projectKey: The LaunchDarkly project key (e.g., "default"). - sessionSecureId: The secure ID of the session to get flag evaluations for. REQUIRED. - startDate: Start date in ISO format (e.g., "2024-01-15T10:00:00Z"). REQUIRED. OPTIONAL INPUTS: - endDate: End date in ISO format (e.g., "2024-01-15T11:00:00Z"). If not provided, uses current time. - query: Additional filters appended to the session/feature-flag scope (e.g. "service_name=gonfalon-web"). Defaults to empty string. - direction: SortDirection (must be the string "ASC" or "DESC"). Defaults to "DESC". - limit: Number of flag evaluation entries to return. Do not use a value greater than 100. Defaults to 50. DATE FORMAT: - Use ISO format: "2024-01-15T10:00:00Z" or "2024-01-15T10:00:00-08:00" - Dates should be reasonable and within your data retention period - Always specify timezone if not using Z (UTC) The tool returns flag evaluation events containing timestamp, flag name, and evaluation attributes that occurred during the session. These events provide insights into which feature flags were evaluated and their values during the user session. When doing this, you should specify the startDate as the created_at attribute of the session and the endDate as the startDate plus three hours. Examples: 1. Specific time window: {"sessionSecureId": "abc123def456", "startDate": "2024-01-15T10:00:00Z", "endDate": "2024-01-15T11:00:00Z"} 2. From specific time to now: {"sessionSecureId": "abc123def456", "startDate": "2024-01-15T10:00:00Z"} 3. Extended search: {"sessionSecureId": "abc123def456", "startDate": "2024-01-15T10:00:00Z", "limit": 100} 4. Scoped to a service: {"sessionSecureId": "abc123def456", "startDate": "2024-01-15T10:00:00Z", "query": "service_name=gonfalon-web"}

Query timeline indicator events for a session. Retrieve timeline indicator events for a specific session to understand what happened during that session. Keep in mind that this will not include flag evaluation events, you must use the query-flag-evaluations tool to retrieve those. REQUIRED INPUTS: - sessionSecureId: The secure ID of the session to get timeline events for. REQUIRED. The tool returns timeline indicator events containing timestamp, type, and event data that occurred during the session. These events provide insights into user interactions, page views, clicks, and other important activities during the session. Here's an example of a valid input: {"sessionSecureId": "abc123def456"}

Query project sessions. Retrieve sessions for a given project with explicit date range parameters. REQUIRED INPUTS: - projectKey: The LaunchDarkly project key (e.g., "default"). - startDate: Start date in ISO format (e.g., "2024-01-15T10:00:00Z"). REQUIRED. OPTIONAL INPUTS: - endDate: End date in ISO format (e.g., "2024-01-15T11:00:00Z"). If not provided, uses current time. - query: Search query string (e.g., "identifier='user@example.com' AND has_errors=true"). Defaults to empty string to get all sessions. - count: Number of session entries to return. Do not use a value greater than 50. Defaults to 10. - sortField: Field to sort by (e.g., "created_at", "length"). Defaults to "created_at". - sortDesc: Boolean for descending sort. Defaults to true. - page: Page number for pagination. Defaults to 1. DATE FORMAT: - Use ISO format: "2024-01-15T10:00:00Z" or "2024-01-15T10:00:00-08:00" - Dates should be reasonable and within your data retention period - Always specify timezone if not using Z (UTC) The tool returns sessions containing session information, user details, and core attributes. Examples: 1. Specific time window: {"startDate": "2024-01-15T10:00:00Z", "endDate": "2024-01-15T11:00:00Z"} 2. From specific time to now: {"startDate": "2024-01-15T10:00:00Z"} 3. Filtered sessions: {"startDate": "2024-01-15T10:00:00Z", "query": "has_errors=true", "sortField": "length", "count": 20} 4. Getting a specific session (a wide time-window should be specified since we don't know when the session happened): {"startDate": "2024-01-15T10:00:00Z", "query": "secure_id=LWK4jxZch4GMmVYJ0rW3R6CNymSy", "count": 1} When you reference sessions fetched using this tool you MUST put session ids in an XML tag so that the UI can find them and turn them into links for the user. Here is an example of a sessionId in an XML tag: <session-id>c6wX2TtznM6F0QByEiRBoQBFw1Bv</session-id>

Query project error groups. Retrieve error groups for a given project with explicit date range parameters. REQUIRED INPUTS: - projectKey: The LaunchDarkly project key (e.g., "default"). - startDate: Start date in ISO format (e.g., "2024-01-15T10:00:00Z"). REQUIRED. OPTIONAL INPUTS: - endDate: End date in ISO format (e.g., "2024-01-15T11:00:00Z"). If not provided, uses current time. - query: Search query string (e.g., "error_type='RuntimeError' AND environment=production"). Defaults to empty string to get all error groups. Note: Do not attempt to use the 'event' attribute as part of the query. This is not a valid attribute and you should likely be using the exception.message attribute (see example 4 below) - count: Number of error group entries to return. Do not use a value greater than 50. Defaults to 10. - page: Page number for pagination. Defaults to 1. DATE FORMAT: - Use ISO format: "2024-01-15T10:00:00Z" or "2024-01-15T10:00:00-08:00" - Dates should be reasonable and within your data retention period - Always specify timezone if not using Z (UTC) The tool returns error groups containing error information, frequency, stack traces, and core attributes. Examples: 1. Specific time window: {"startDate": "2024-01-15T10:00:00Z", "endDate": "2024-01-15T11:00:00Z"} 2. From specific time to now: {"startDate": "2024-01-15T10:00:00Z"} 3. Filtered for a specific error type: {"startDate": "2024-01-15T10:00:00Z", "query": "error_type='RuntimeError'", "count": 20} 4. Filtered for a specific service and error message: {"startDate": "2024-01-15T10:00:00Z", "query": "exception.message=\"Cannot use 'in' operator*\" and service_name=gonfalon-web", "count": 20}

Retrieve bucketed, aggregated values over time for a product type. Returns time-series buckets (not raw events) suitable for charting trends, comparing groups, and computing sums/averages/percentiles. Use this instead of query-logs/query-traces/query-sessions/query-error-groups when you want aggregated values over a window rather than individual records. REQUIRED INPUTS: - projectKey: The LaunchDarkly project key (e.g., "default"). - productType: Which product to aggregate over ("errors", "requests", "logs", "sessions", "metrics"). Use "metrics" to query OpenTelemetry / custom metric data points. REQUIRED. - startDate: Start date in ISO format (e.g., "2024-01-15T10:00:00Z"). REQUIRED. OPTIONAL INPUTS: - endDate: End date in ISO format (e.g., "2024-01-15T11:00:00Z"). If not provided, uses current time. - query: Search query string (e.g., "error EXISTS AND service_name=foo"). Defaults to empty string to aggregate all records. - groupBy: Optional field to group results by (e.g., "message", "service_name", or for metrics "metric_name"). - expressions: Array of aggregations to compute per bucket. Each expression is {aggregator, column}. If omitted, defaults to [{aggregator: "Count", column: ""}]. EXPRESSION SCHEMA: - aggregator: one of Count, CountDistinct, CountDistinctKey, Min, Avg, P50, P90, P95, P99, Max, Sum - column: the field to aggregate. Use "" for Count. For metrics productType the column is "value" (the OpenTelemetry metric data point value) — always confirm with get-keys(productType: "metrics") and pick a Numeric key, since passing the wrong column name (e.g. "metric_value") silently returns empty buckets instead of an error. For traces use "duration"; for logs/events the relevant numeric attribute discovered via get-keys. AGGREGATOR GUIDE: - Count: number of records/data points in each bucket (ignores column). - CountDistinct: unique values of column (e.g., unique user_ids). - Sum/Avg/Min/Max: numeric aggregation of column across records. - P50/P90/P95/P99: percentiles of column (e.g., P99 latency). DATE FORMAT: - Use ISO format: "2024-01-15T10:00:00Z" or "2024-01-15T10:00:00-08:00" - Dates should be reasonable and within your data retention period - Always specify timezone if not using Z (UTC) Examples: 1. Error counts for specific window: {"productType": "errors", "startDate": "2024-01-15T10:00:00Z", "endDate": "2024-01-15T16:00:00Z"} 2. Request counts from specific time to now: {"productType": "requests", "startDate": "2024-01-15T10:00:00Z"} 3. Grouped counts: {"productType": "errors", "startDate": "2024-01-15T10:00:00Z", "groupBy": "service_name"} 4. P99 latency for traces: {"productType": "traces", "startDate": "2024-01-15T10:00:00Z", "expressions": [{"aggregator": "P99", "column": "duration"}]} 5. OTel metrics: average data point value grouped by metric_name: {"productType": "metrics", "startDate": "2024-01-15T10:00:00Z", "groupBy": "metric_name", "expressions": [{"aggregator": "Avg", "column": "value"}]} 6. OTel metrics: sum of data point values for a specific metric: {"productType": "metrics", "startDate": "2024-01-15T10:00:00Z", "query": "metric_name=\"http.server.duration\"", "expressions": [{"aggregator": "Sum", "column": "value"}]}

Query project traces. Retrieve traces for a given project with explicit date range parameters. REQUIRED INPUTS: - projectKey: The LaunchDarkly project key (e.g., "default"). - startDate: Start date in ISO format (e.g., "2024-01-15T10:00:00Z"). REQUIRED. OPTIONAL INPUTS: - endDate: End date in ISO format (e.g., "2024-01-15T11:00:00Z"). If not provided, uses current time. - query: Search query string (e.g., "span_name=\"getUserData\" AND service_name=auth"). Defaults to empty string to get all traces. - limit: Number of trace entries to return. Do not use a value greater than 50. Defaults to 20. - direction: SortDirection (must be the string "ASC" or "DESC"). Defaults to "DESC". - sortColumn: Column to sort by (e.g., "duration" to find slowest traces). Default sort is by timestamp. - sortDirection: Sort direction for sortColumn: "ASC" or "DESC". Defaults to "DESC" if sortColumn is set. DATE FORMAT: - Use ISO format: "2024-01-15T10:00:00Z" or "2024-01-15T10:00:00-08:00" - Dates should be reasonable and within your data retention period - Always specify timezone if not using Z (UTC) - Never query a date range of more than 24 hours. If you need to query more data than 24 hours, do not use this tool and instead use the query-aggregations tool. The tool returns a paginated connection with trace entries containing timestamp, span details, and core attributes. Keep in mind that you can query for the traces that occurred during a particular session by using secure_session_id in your query. When doing this, you should specify the startDate as the created_at attribute of the session and the endDate as the startDate plus three hours. To find the slowest traces, use sortColumn="duration" with sortDirection="DESC" instead of adding sort terms to the query string. Examples: 1. Specific time window: {"startDate": "2024-01-15T10:00:00Z", "endDate": "2024-01-15T11:00:00Z"} 2. From specific time to now: {"startDate": "2024-01-15T10:00:00Z"} 3. With query filter: {"startDate": "2024-01-15T10:00:00Z", "query": "span_name=\"getUserData\"", "limit": 20}

Query project logs. Retrieve logs for a given project with explicit date range parameters. REQUIRED INPUTS: - projectKey: The LaunchDarkly project key (e.g., "default"). - startDate: Start date in ISO format (e.g., "2024-01-15T10:00:00Z"). REQUIRED. OPTIONAL INPUTS: - endDate: End date in ISO format (e.g., "2024-01-15T11:00:00Z"). If not provided, uses current time. - query: Search query string (e.g., "message=\"error\" AND level=error"). Defaults to empty string to get all logs. - limit: Number of log entries to return. Do not use a value greater than 50. Defaults to 20. - direction: SortDirection (must be the string "ASC" or "DESC"). Defaults to "DESC". DATE FORMAT: - Use ISO format: "2024-01-15T10:00:00Z" or "2024-01-15T10:00:00-08:00" - Dates should be reasonable and within your data retention period - Always specify timezone if not using Z (UTC) The tool returns a paginated connection with log entries containing timestamp, level, message and core attributes. Keep in mind that you can query for the logs that occurred during a particular session by using secure_session_id in your query. For instance, query="secure_session_id=1234567890" will return all logs that occurred during the session with secure_session_id=1234567890. When doing this, you should specify the startDate as the created_at attribute of the session and the endDate as the startDate plus three hours. Examples: 1. Specific time window: {"startDate": "2024-01-15T10:00:00Z", "endDate": "2024-01-15T11:00:00Z"} 2. From specific time to now: {"startDate": "2024-01-15T10:00:00Z"} 3. With query filter: {"startDate": "2024-01-15T10:00:00Z", "query": "level=error", "limit": 50}

Check whether any SDKs have been active in a given environment. Returns true if any SDK has initialized or sent events in the environment. Use this to verify that an environment is actually in use before cleanup. Optionally filter by sdkName or sdkWrapperName to check a specific SDK.

Get a LaunchDarkly environment and its SDK keys: server-side SDK key, client-side ID, and mobile key. Use this to retrieve the client-side ID needed to initialize a browser or mobile SDK.

Get a LaunchDarkly project with its environments and SDK keys. Use to retrieve SDK keys for an existing project or verify a project exists.

Create a new LaunchDarkly project. Returns the project with its environments and SDK keys. Project keys must be lowercase with hyphens, starting with a letter. Production and Test environments are created by default.

List release policies for a project. Each policy defines preferred release methods and the metrics or metric groups that automatically attach to guarded rollouts when the policy's conditions match (e.g. specific environments or flag tags). Call this BEFORE recommending metrics for a guarded rollout — some metrics may already be determined by an existing policy, and the user should know what will auto-attach before deciding what else to add. Also useful when editing a release policy itself: shows the current state of all policies so you understand what's already configured project-wide. If `warnings` is non-empty, render those warnings to the user and do not describe the affected environments as clean policy rollouts until the policy configuration is fixed.

List recent event keys received by a LaunchDarkly project — used to check which events are actively flowing before creating a metric. Returns up to 50 event keys with last-seen timestamps. If the event key you need isn't here, it may not be instrumented yet. Use this BEFORE create-metric to: 1. Confirm the event key exists and is receiving data 2. Discover event keys when the user isn't sure what to use 3. Check the correct spelling of an event key Supports fuzzy search via `query` to narrow results. Filter by `environmentKey` to check a specific environment. If the desired event key is absent, surface a warning and ask whether the user wants to instrument the event first or proceed and wire it up later.

Create a new metric in a LaunchDarkly project. KIND (optional, defaults to 'custom') — how the metric collects events: - 'custom' → event-driven; agent calls track(eventKey) in code. Requires `eventKey`. - 'pageview' → fires automatically when a user visits a matching URL. Requires `urls`. No code change needed. - 'click' → fires automatically when a user clicks a CSS selector on a matching URL. Requires `urls` + `selector`. No code change needed. Prefer 'pageview' or 'click' when they fit the user's intent — they require no SDK instrumentation. URLS (required for kind='pageview' or 'click') — array of URL match rules. The field name carrying the value depends on the matcher `kind`: - { kind: 'substring', substring: '/checkout' } — URL contains this string (most common) - { kind: 'exact', url: 'https://example.com/checkout' } — URL must match exactly - { kind: 'canonical', url: 'https://example.com/checkout' } — matches the canonical URL - { kind: 'regex', pattern: '/checkout/.+' } — full regex pattern SELECTOR (required for kind='click') — CSS selector that triggers the event, e.g. '.checkout-btn', '#submit'. EVENT KEY (required for kind='custom') — matches the string passed to track() in code. MEASURE TYPE (required) — speak the user's language, not the API's: - 'count' → total number of times the event occurred (isNumeric: false, unitAggregationType: sum) - 'occurrence' → whether each user triggered the event at all — conversion/binary (isNumeric: false, unitAggregationType: average) - 'value' → a numeric value attached to the event like latency or revenue (isNumeric: true) SUCCESS CRITERIA (required): - 'HigherThanBaseline' — more is better (conversion rate, revenue, engagement) - 'LowerThanBaseline' — less is better (latency, error rate, bounce rate) VALUE AGGREGATION (optional, only for measureType='value'): - 'average' (default) — mean value per user, e.g. average page load time - 'sum' — total value per user, e.g. total revenue UNIT (optional) — human-readable label shown in the UI, e.g. 'ms', 'USD', 'requests'. RANDOMIZATION UNITS (optional) — context kinds this metric can be randomized by in experiments. Defaults to ['user']. Override if the project uses different context kinds (e.g. ['member', 'account'] on catfood). If creation fails with 'randomization unit not found', call get-project or ask the user for their project's context kinds. Common templates: - Page visit: kind=pageview, urls=[{kind:'substring', substring:'/checkout'}], measureType=occurrence, successCriteria=HigherThanBaseline - Button click: kind=click, urls=[{kind:'substring', substring:'/'}], selector='.checkout-btn', measureType=occurrence, successCriteria=HigherThanBaseline - API latency: measureType=value, valueAggregation=average, successCriteria=LowerThanBaseline, unit=ms - Signup conversion: measureType=occurrence, successCriteria=HigherThanBaseline - Error count: measureType=count, successCriteria=LowerThanBaseline

Get full details for a single LaunchDarkly metric: measureType, eventKey, successCriteria, unit, description, tags, creation date, and attached flag count. Use after create-metric to verify the result, or to inspect an existing metric before modifying it.

List metrics in a LaunchDarkly project. Returns key, name, measureType (count/occurrence/value), eventKey, successCriteria, tags, and how many flags each metric is attached to. Sorting: use `sort` with `createdAt` or `name`; prefix with `-` for descending (e.g. `-createdAt` for newest first). Filtering (uses `field operator value` syntax internally — just pass the values below): - `query`: fuzzy match on key/name - `tags`: array of tags (all must match) - `eventKind`: one of `custom`, `pageview`, `click` - `isNumeric`: true = value metrics only - `hasConnections`: true = attached to flags or experiments - `maintainerIds`: array of member ID strings (use find-members to resolve) - `maintainerTeamKey`: team key string - `metricUsedIn`: one of `experiments`, `guarded_rollouts`, `any`, `none` - `dataSourceKeys`: array of data source key strings Use before creating a metric to check for duplicates and understand naming conventions.

Permanently delete an agent graph and all of its edges. THIS IS IRREVERSIBLE. Requires confirm=true to execute.

Update an agent graph's metadata or structure. All fields are optional. If rootConfigKey or edges are provided, both must be present and will fully replace the existing graph structure. Pass name or description to update metadata only.

Create a new agent graph in a project. An agent graph defines a directed graph of AgentControl Configs for multi-agent workflows. Provide a rootConfigKey and edges to define the graph structure, or create the graph with just metadata and add edges later via update-agent-graph. If rootConfigKey or edges are provided, both must be present.

Get a specific agent graph by key, including its full edge structure. Each edge connects a source AgentControl Config to a target AgentControl Config with optional handoff data.

List all agent graphs in a project. Returns metadata for each graph including key, name, description, and root config key. Does not include edge data — use get-agent-graph to retrieve full graph structure.

Invite one or more people to the LaunchDarkly account by email. Each invitee receives an email invitation to join. Optionally assign a role (reader, writer, admin) — defaults to reader if not specified.

Search for LaunchDarkly account members and return their IDs. Supports flexible matching: - `query`: case-insensitive substring match across both email and display name (e.g. 'hartmann', 'anthony', 'hart' all work). Use this for fuzzy/partial lookups. - `emails`: exact match on one or more full email addresses. Use when you have the precise email and want a guaranteed result. Returns id, email, displayName, and role for each match. Pass the returned `id` values to tools like list-metrics as `maintainerIds`.

Return the member ID, profile, and team memberships for the currently authenticated user. Use this whenever the user refers to themselves ('my metrics', 'created by me', 'assigned to me') to resolve their member ID before calling tools that require a maintainerId or similar identifier, or to resolve one of their team keys before calling tools that require a maintainerTeamKey. If the member belongs to more than one team, ask which one to use rather than guessing. If the server returns `token_expired`, re-authenticate the Launchdarkly MCP server connection in your MCP client and retry.

Create a new AI tool definition in a project. The schema should be a raw JSON Schema object with type, properties, and required fields (e.g. {"type": "object", "properties": {...}}). Do NOT use the OpenAI function calling wrapper format. After creation, attach the tool to a variation using update-agentcontrol-config-variation.

Get a single AI tool definition including its full schema. Use to inspect a tool's parameters before attaching it to an AgentControl Config variation.

List AI tool definitions in a project. Returns each tool's key, description, and schema. Tools are attached to AgentControl Config variations to give models function-calling capabilities.

Update the default (fallthrough) rule for an AgentControl Config in an environment. Set a percentage rollout across variations, or serve a single variation to all unmatched contexts. Weights must sum to 100. Use human-friendly percentages (e.g., 80 for 80%). Accepts a variation key (from get-agentcontrol-config) or variation name (from get-agentcontrol-config-targeting); the tool resolves either to the internal variation _id (UUID) before patching. If the environment requires approval, the response includes requiresApproval: true and the attempted instructions; call `create-agentcontrol-config-approval` with the returned instructions to submit it for review.

Read the targeting configuration for an AgentControl Config in a specific environment. Returns variations (with their _id UUIDs and names), individual targets, custom rules, fallthrough (default rule), and off variation. The variation name returned here can be passed as 'variationKey' to update-agentcontrol-config-targeting, update-agentcontrol-config-rollout, and update-agentcontrol-config-targets. Alternatively, use get-agentcontrol-config to obtain the variation's slug key.

Clone an existing AgentControl Config variation with selective overrides. Reads the source variation, applies any provided overrides (model, instructions, messages, parameters, tools), and creates a new variation. Returns both the source and created variation so you can compare the diff. Use this for A/B experimentation: change one thing at a time while keeping everything else constant.

Permanently delete an AgentControl Config variation. THIS IS IRREVERSIBLE. Requires confirm=true to execute.

Update an AgentControl Config variation's name, description, model, instructions/messages, parameters, attached tools, or judge configuration. All fields are optional: only provided fields are updated. Pass 'name' to rename the variation in place without recreating it (avoids changing the variation _id). To attach tools, pass the 'tools' array with {key, version} entries (create tools first with create-ai-tool). Pass an empty tools array to detach all tools. To attach judges, pass judgeConfiguration with a judges array of {judgeConfigKey, samplingRate} entries. Pass an empty judges array to detach all judges.

Create a variation for an AgentControl Config. A variation defines the model, prompts, parameters, and tools. modelConfigKey must be in Provider.model-id format (e.g. OpenAI.gpt-4o, Anthropic.claude-sonnet-4-5) for models to display correctly in the UI. Agent-mode configs use 'instructions' (a string); completion-mode configs use 'messages' (an array of {role, content} objects). To attach AI tools, pass the 'tools' array with {key, version} entries (create tools first with create-ai-tool). To attach judges, pass judgeConfiguration with a judges array of {judgeConfigKey, samplingRate} entries.

Health check for an AgentControl Config. Detects common issues: missing models (NO MODEL in UI), missing prompts, orphaned tool references, and empty configs with no variations. Returns a health verdict (healthy, warning, unhealthy) with specific issues and per-variation summaries. Run before updating or experimenting with a config.

Create an AgentControl Config with its first variation in one step. This is the recommended way to set up a new AgentControl Config: it creates the config, adds a variation with model and prompts, and verifies everything is configured correctly. Returns the full config detail with variation. To attach AI tools, pass the 'tools' array with {key, version} entries. IMPORTANT: evaluationMetricKey (format: $ld:ai:judge:<suffix>) is REQUIRED when mode is 'judge'. Use create-agentcontrol-config + create-agentcontrol-config-variation separately only when you need more control.

Permanently delete an AgentControl Config. THIS IS IRREVERSIBLE. Requires confirm=true to execute. Prefer archiving (update-agentcontrol-config with archived: true) when possible.

Update an AgentControl Config's metadata: name, description, tags, or archive status. Does NOT modify variations: use update-agentcontrol-config-variation for model, prompt, or parameter changes. Set archived: true to archive (reversible).

Create a new AgentControl Config in a project. This creates the config shell: use create-agentcontrol-config-variation next to add a model, prompts, and parameters. Mode determines whether variations use 'instructions' (agent), 'messages' (completion), or 'messages' (judge). Judge-mode configs evaluate other AgentControl Config outputs. IMPORTANT: evaluationMetricKey (format: $ld:ai:judge:<suffix>) is REQUIRED when mode is 'judge'; omitting it will cause a 400 error. For agent and completion mode it is not accepted.

Get detailed configuration for a single AgentControl Config including all its variations. Each variation includes its model, instructions or messages, parameters, attached tools, and judgeConfiguration (attached judges with judgeConfigKey and samplingRate). For judge-mode configs the response also includes evaluationMetricKey.

Search and browse AgentControl Configs in a project. Returns a paginated list with key, name, mode (agent, completion, or judge), tags, variation count, and a `usedInGraphs` array listing the agent graph keys that reference each config (as the graph root or as an edge source/target). An empty `usedInGraphs` means the config is not referenced by any graph (orphaned). If graph usage cannot be loaded, `usedInGraphs` is omitted entirely (rather than empty) so an absent field is never mistaken for orphaned. Use query to search by name or key. Sorting: use `sort` with `creationDate` or `name`; prefix with `-` for descending. Defaults to `-creationDate`. Pagination: responses include `totalCount` and `pageInfo.offset`. To get the next page, set `offset` to the current offset + limit.

Apply an already-approved approval request. This executes the changes that were approved by reviewers. Only works on requests with reviewStatus 'approved'. Does NOT approve requests: that must be done by a human reviewer.

List pending approval requests for a flag in an environment. Shows status, review state, and who requested the change. Use to check on approval progress after creating a request.

Create an approval request for a flag change in an environment that requires approvals. Provide the same semantic patch instructions you would use for a direct change. The request will be reviewed by approvers before taking effect. Does NOT approve the request: that must be done by a human reviewer.

Detailed safety check before removing a feature flag. Checks dependencies, code references, active targeting, expiring targets, and cross-environment status. Returns a readiness verdict: 'safe' (proceed), 'caution' (review warnings), or 'blocked' (must resolve blockers first). Always run this before archive-flag or delete-flag. Also returns recommendedValue: the actual variation value to hardcode at call sites when the flag is safe to remove (e.g. true, false, 'blue', 11). Computed from the flag's current deterministic configuration. null when serving is non-deterministic (active rules, rollout splits, individual targets, or prerequisites). For cross-environment consensus on the recommended value, use check-flag-rollout-complete.

List, add, update, or remove expiring targets on a flag. Expiring targets are automatically removed from targeting after a specified date. Dates are shown as ISO strings with days-until-expiry computed. Variation IDs are resolved to human-readable names.

Permanently delete a feature flag. THIS IS IRREVERSIBLE. Requires confirm=true to execute. Always call check-removal-readiness first and only delete if it returns 'safe'. Prefer archive-flag (reversible) when possible.

Archive a feature flag (reversible). This is a soft-delete that can be undone. Recommended as the first step before permanent deletion. Always run check-removal-readiness before archiving.

Copy a flag's targeting configuration from one environment to another. Common use: promote from staging to production. Optionally select which aspects to copy: targeting, rules, offVariation, prerequisites, on state. If the target environment requires approval, the response includes requiresApproval: true and an approvalUrl; follow the approvalUrl to submit the copy request for review.

Add or remove prerequisites for a flag in a specific environment. Prerequisites are other flags that must evaluate to specific variations before this flag is evaluated. Use addPrerequisite to migrate prerequisites onto a new flag, or removePrerequisite + addPrerequisite to update dependent flags to point to a new key. If the environment requires approval, the response includes requiresApproval: true and the attempted instructions; call `create-approval-request` with the returned instructions to submit it for review.

Add or remove specific users or contexts from individual flag targeting. Individual targets are the highest priority: they override all rules. Supported instruction kinds: addTargets, removeTargets, replaceTargets. To target non-user context kinds (e.g. organization), include contextKind on the instruction (e.g. { kind: 'addTargets', contextKind: 'organization', values: ['org-123'], variationId: '<id>' }). Note: addContextTargets and removeContextTargets are NOT supported by the LD API; use addTargets/removeTargets with contextKind instead. Responses truncate long lists. If the environment requires approval, the response includes requiresApproval: true and the attempted instructions; call `create-approval-request` with the returned instructions to submit it for review.

Add, remove, or modify custom targeting rules for a flag in an environment. Rules evaluate top-to-bottom; first matching rule wins. Use get-flag to look up rule _ids, clause _ids, and variation _ids before constructing instructions. Supported instruction kinds and required fields: - addRule: clauses (required), variationId or rolloutWeights (one required). Example — serve On to @launchdarkly.com users: {"kind":"addRule","clauses":[{"contextKind":"user","attribute":"email","op":"endsWith","values":["@launchdarkly.com"]}],"variationId":"<variation-_id>"} - removeRule: ruleId (required, from get-flag). - updateRuleVariationOrRollout: ruleId and variationId or rolloutWeights. - addClauses: ruleId and clauses (required). - removeClauses: ruleId and clauseIds (required). - reorderRules: ruleIds — complete ordered list of all rule _ids.

Change the default rule (fallthrough) for a flag. Set a percentage rollout across variations or serve a single variation to all unmatched users. Weights must sum to 100. Use human-friendly percentages (e.g., 80 for 80%). If the environment requires approval, the response includes requiresApproval: true and the attempted instructions; call `create-approval-request` with the returned instructions to submit it for review.

Turn a feature flag's targeting on or off in a specific environment. Returns the previous and new state. If the environment requires approval, the response includes requiresApproval: true and the attempted instructions; call `create-approval-request` with the returned instructions to submit it for review.

Update a flag's top-level settings: name, description, tags, temporary/permanent status, maintainer, default variations, or custom properties. Does NOT modify per-environment targeting, rollouts, or rules: use the targeting tools for those. Supported instruction kinds: updateName, updateDescription, addTags, removeTags, markTemporary, markPermanent, updateMaintainerMember, updateMaintainerTeam, updateCustomProperty, deleteCustomProperty, updateDefaultVariation. updateMaintainerTeam takes the same Value shape as updateMaintainerMember but with a team key instead of a member id (e.g. { kind: 'updateMaintainerTeam', value: 'team-key' }). Only include a maintainer instruction when the user explicitly asked to change the maintainer — don't reassign it as a side effect of some other requested edit. updateCustomProperty sets or replaces a custom property: { kind, key, name, value[] }. deleteCustomProperty removes a custom property: { kind, key }. updateDefaultVariation sets the flag-level default variation indices used when new environments are provisioned: { kind, onVariation?: number, offVariation?: number } where onVariation/offVariation are zero-based variation indices.

Create a new feature flag in a project. Defaults to a boolean temporary flag. After creation the flag is OFF in all environments: use toggle-flag to enable it. FLAG KINDS: - 'boolean' (default): two variations — true/false. Do not pass a `variations` array. - 'multivariate': custom variations such as strings, numbers, or JSON objects. REQUIRED: provide a `variations` array with at least 2 entries, each with a `value` field. The LaunchDarkly API ignores `kind: 'multivariate'` when no variations are supplied and silently creates a boolean flag instead, so this tool enforces the requirement early. To satisfy org guardrails that require custom properties (e.g. jira.issues, expiry.date), pass customProperties as a map of { key: { name, value[] } }. MAINTAINER: set maintainerTeamKey or maintainerId to assign an owner at creation time. Prefer maintainerTeamKey over maintainerId when a suitable team exists — team ownership survives personnel changes better than an individual. Call get-member-self first to resolve the calling user's ID and team memberships; if they belong to more than one team, ask which one should be the maintainer instead of guessing.

Check a flag's lifecycle status across all environments. Returns per-environment state (active, inactive, new, launched) and a summary of which environments the flag is active, inactive, or launched in. Use before cleanup to verify the flag is inactive everywhere.

Find feature flags that are candidates for cleanup. Returns a prioritized list of stale flags sorted by staleness (worst first). Categories: inactive_30d (no requests in period), launched_no_changes (fully rolled out, no recent changes), never_requested (created but never evaluated). Defaults to showing temporary flags inactive for 30+ days. ENVIRONMENT OPTIONS (choose one): - `env`: single environment key (required when useCriticalEnvs is not set) - `useCriticalEnvs`: auto-discover critical environments from the project's environment config and use the first critical env for staleness classification EVALUATION COUNTS: - `includeEvalCounts`: when true, attaches `evalCounts` (total SDK evaluations per env) to each stale flag using the batched evaluationSummaries endpoint. NOTE: eval counts are total SDK calls, not unique contexts. - `evalWindow`: evaluation window in days (default 30) Optionally filter by maintainer to find stale flags owned by a specific member or team (use get-member-self or find-members to resolve maintainerId).

Get combined health view for a single flag: lifecycle state, last-requested timestamp, targeting summary (rules count, targets count, on/off), age, and whether it's temporary. Use this to assess if a flag is stale or needs attention.

Get detailed configuration for a single feature flag scoped to a specific environment. Returns the full targeting tree including rules, individual targets, fallthrough, prerequisites, and variation details.

Search and browse feature flags in a project. Returns a paginated list scoped to a single environment. Filtering: - `query`: search by flag name or key (case-insensitive) - `tags`: array of tags (all must match) - `state`: lifecycle state — `live`, `deprecated`, or `archived`. Defaults to `live` - `type`: `temporary` or `permanent` - `maintainerId`: member ID of the flag maintainer (use get-member-self or find-members to resolve) - `maintainerTeamKey`: team key of the maintaining team - `sdkAvailability`: one of `client`, `mobile`, `anyClient`, `server` Sorting: use `sort` with `creationDate` or `name`; prefix with `-` for descending. Defaults to `-creationDate`. Pagination: responses include `totalCount` and `pageInfo`. `pageInfo.nextOffset` is the value to pass as `offset` on the next call, or `null` when you are on the last page.