Install

Permanently delete a prompt snippet. THIS IS IRREVERSIBLE. Any AI 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 AI 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 AI 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 AI 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 AI 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 AI 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 the 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.

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.

Start a new iteration of an experiment. This begins data collection for the experiment. Use after creating an experiment to activate it, or to start a new round of data collection after stopping a previous iteration. Optionally reshuffle traffic to randomize user assignments.

Update an experiment's metadata (name, description). Does not modify treatments or metrics — use the LaunchDarkly UI for structural changes. Use start-experiment-iteration to begin a new iteration.

Create a new experiment on a flag or AI Config. An experiment measures the impact of different variations on specified metrics. You must provide at least one metric key and define treatments (the variations to compare). One treatment must be marked as the baseline. 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.

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.

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 custom metric in a LaunchDarkly project. 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: - 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 AI 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 AI Config to a target AI 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 and profile 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.

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-ai-config-variation.

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

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

Add or remove specific contexts from individual AI Config targeting in an environment. Individual targets are the highest priority and override all rules. Supported kinds: addTargets, removeTargets, clearTargets, replaceTargets. Each instruction takes a 'variationKey' set to either the variation key (from get-ai-config) or the variation name (from get-ai-config-targeting); the tool resolves either to the internal variation _id before patching.

Update the default (fallthrough) rule for an AI 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-ai-config) or variation name (from get-ai-config-targeting); the tool resolves either to the internal variation _id (UUID) before patching.

Add, remove, or modify custom targeting rules for an AI Config in an environment. Rules are evaluated top-to-bottom; first matching rule wins. Supported kinds: addRule, removeRule, addClauses, removeClauses, reorderRules, replaceRules, updateRuleDescription, addValuesToClause, removeValuesFromClause, updateClause. Use get-ai-config-targeting first to obtain ruleId, clauseId, and variationId values referenced by these instructions. If the environment requires approval, the response includes requiresApproval: true and an approvalUrl instead of executing.

Read the targeting configuration for an AI 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-ai-config-targeting-rules, update-ai-config-rollout, and update-ai-config-individual-targets. Alternatively, use get-ai-config to obtain the variation's slug key.

Clone an existing AI 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 AI Config variation. THIS IS IRREVERSIBLE. Requires confirm=true to execute.

Update an AI Config variation's model, instructions/messages, parameters, attached tools, or judge configuration. All fields are optional: only provided fields are updated. 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 AI 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 AI 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.

Check an AI Config's lifecycle status across all environments. Returns per-environment state (active, inactive, new, launched) and whether targeting is on, plus a summary of which environments the config is active, inactive, or launched in. Useful for understanding where a config is currently being served before making changes.

Create an AI Config with its first variation in one step. This is the recommended way to set up a new AI 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. Use create-ai-config + create-ai-config-variation separately only when you need more control.

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

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

Create a new AI Config in a project. This creates the config shell: use create-ai-config-variation next to add a model, prompts, and parameters. Mode determines whether variations use 'instructions' (agent) or 'messages' (completion).

Get detailed configuration for a single AI Config including all its variations. Each variation includes its model, instructions or messages, parameters, and attached tools.

Search and browse AI Configs in a project. Returns a paginated list with key, name, mode (agent or completion), tags, and variation count. Use query to search by name or key.

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.

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.

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.

Add or remove specific users or contexts from individual flag targeting. Individual targets are the highest priority: they override all rules. Supported kinds: addTargets, removeTargets, addContextTargets, removeContextTargets, replaceTargets. Responses truncate long lists.

Add, remove, or modify custom targeting rules for a flag in an environment. Rules are evaluated top-to-bottom; first matching rule wins. Supported kinds: addRule, removeRule, updateRuleVariationOrRollout, addClauses, removeClauses, reorderRules.

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%).

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 will include requiresApproval: true and an approvalUrl instead of executing.

Update a flag's top-level settings: name, description, tags, temporary/permanent status, or maintainer. Does NOT modify targeting, rollouts, or rules: use the targeting tools for those. Supported instruction kinds: updateName, updateDescription, addTags, removeTags, markTemporary, markPermanent, updateMaintainerMember.

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. For multivariate flags, provide variations array with {value, name} entries.

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.

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. Use query to search by name/key, tags to filter by tag, state to filter by lifecycle state (active, inactive, new, launched, archived), and type to filter by temporary or permanent.