Audit LaunchDarkly experiments and their treatments

LaunchDarkly names no guardrail field, so the check reads secondary metrics and flag targeting together and says where a guardrail should go.

How it works

  1. Connect LaunchDarkly's hosted MCP server at https://mcp.launchdarkly.com/mcp/launchdarkly to your AI assistant or coding agent, then sign in with OAuth, noting that accounts in the EU or Federal environments use the local @launchdarkly/mcp-server package with an API access token instead.
  2. Install the ExpLint MCP at https://explint.com/mcp to enable your agent to audit tests.
  3. Run the prompt below to audit these plans before the work starts.

How the check runs

  1. It reads the experiment's hypothesis, treatments with one baseline, allocation percentages, primary and secondary metrics, and the flag targeting rule it runs on, then keeps those field names as headings so every finding points at a setting you can open.
  2. It sends that text to ExpLint with explint__lint, which returns errors, warnings, and passes, each finding naming the rule behind it.
  3. You edit the experiment in LaunchDarkly and ask for a fresh read, since planned duration and sample size are estimates there rather than settings the MCP tools return.

Copy and paste this prompt

Change the words in square brackets to name your own project, board, or test.

Prompt for your assistant
Use the LaunchDarkly MCP tools to read the experiment [experiment name]. Build one text from its hypothesis, treatments and allocation, primary metric, secondary metrics, and flag targeting rule. Lint it with explint.com against project [your ExpLint project name]. Show each error and warning with its LaunchDarkly field. Do not launch or edit the experiment. Suggest fixes here and re-check after I update LaunchDarkly.

What ExpLint looks for

ExpLint ships over 24 rules, and a project switches each one on or off or rewrites it in plain English. These are the rules the plans this guide reads break most often. An error means the test cannot answer its question as written, and a warning means the result will be hard to judge when it comes in.

RuleLevelIn plain words
hypothesis/names-metric-and-directionerrorThe experiment has to name the metric and the direction it expects, since LaunchDarkly records the metric as a setting and the prose carries the expectation.
metrics/has-one-primary-metricerrorLaunchDarkly keeps secondary metrics beside the primary one, and the plan has to say which of them decides the outcome when they disagree.
randomization/states-the-spliterrorThe treatments' allocation percentages should sum to 100 in the plan, because a treatment with no stated share cannot be checked.
decision/has-criteria-before-launcherrorThe plan should record what result ships a treatment and what result stops it, since LaunchDarkly has no field that holds a decision.

Read more

Portrait of Kameron Tanseli

Kameron Tanseli

Founder, ExpLint

Kameron Tanseli is the founder of ExpLint and a growth engineer who has run more than 1,500 experiments across a nine-year career. As the founding growth hire at Fyxer he launched 540 experiments in a year while the company grew from $1M to $35M in annual revenue, and he now runs growth engineering at FLORA, where a one-person team ships six to eight experiments a week.

Don’t let a bad test make it to production

Install the MCP and start flagging ticket slop before it reaches your users