LaunchDarkly

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.

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}

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"}

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.

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.

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. The experiment is created as a DRAFT: it collects no data and affects no end users until an iteration is started. Do NOT call start-experiment-iteration in the same turn as this tool. Summarize the created design for the user, show them the returned `designUrl`, and wait for their explicit confirmation before starting the experiment.

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. VIEWS: pass viewKeys to link the new flag to one or more views at creation time (Views are an Enterprise feature). On accounts without the Views entitlement the API silently ignores viewKeys rather than erroring, so verify the links with get-resource-views if view membership is load-bearing.

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 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

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.

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.

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.

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. Pass viewKeys to link the new segment to one or more views at creation time (Views are an Enterprise feature).

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

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

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

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.

Permanently delete an observability alert. THIS IS IRREVERSIBLE. Requires confirm=true to execute. Use get-alert first to verify you are deleting the right alert. INPUTS: - projectKey (required): The LaunchDarkly project key (e.g., "default"). - alertId (required): The numeric ID of the alert to delete - confirm (required): Must be true to execute the deletion RETURNS: - deleted: Boolean indicating success - alert_id: ID of the deleted alert

Permanently delete a dashboard (visualization) and all of its graphs. THIS IS IRREVERSIBLE. Requires confirm=true to execute. Use get-dashboard first to verify you are deleting the right dashboard. INPUTS: - projectKey (required): The LaunchDarkly project key (e.g., "default"). - dashboardId (required): The numeric ID of the dashboard to delete (from list-dashboards) - confirm (required): Must be true to execute the deletion RETURNS: - deleted: Boolean indicating success - dashboard_id: ID of the deleted dashboard

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

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.

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

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`.

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), or by `view` to scope the search to flags linked to a view (Views are an Enterprise feature).

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.

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.

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.

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.

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.

Get detailed information about a specific observability alert. Use this tool to understand the configuration of an existing alert. INPUTS: - projectKey (required): The LaunchDarkly project key (e.g., "default"). - alertId (required): The numeric ID of the alert (from list-alerts) RETURNS: - id, name, product_type, function_type, function_column, query, group_by_keys - disabled: Whether the alert is currently disabled - threshold_value, threshold_window, threshold_cooldown, threshold_type, threshold_condition - message_content: Custom notification message, if set - destinations: Where notifications are sent (Slack, Email, Webhook, ...) - alert_url: URL to view the alert Example usage: {"projectKey": "default", "alertId": 42}

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.

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}

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

Fetch the full markdown content of a LaunchDarkly documentation page. Pass a URL returned by `search-docs`, or any `https://launchdarkly.com/docs/` URL. The LaunchDarkly docs site serves clean markdown when the URL path ends with `.md` (e.g. `https://launchdarkly.com/docs/home/flags/create.md`). This tool appends `.md` automatically if not already present. Responses are capped at 75 KB. When `truncated` is true, fetch the next logical section directly or narrow your search query. Only `https://launchdarkly.com/docs/` URLs are accepted.

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 details about a specific evaluation definition, including its configuration and last run status.

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

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

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.