Lint GrowthBook experiments with explint.com before you launch
Read an experiment draft from GrowthBook with its MCP server, check the plan with explint.com while it is still a draft, and fix the gaps before anyone writes code or splits traffic.
What you need before you start
- A GrowthBook workspace with an experiment drafted, including its hypothesis, metrics, and traffic settings written in GrowthBook or ready to paste in.
- A GrowthBook API key or personal access token with read access, which you create under Settings and then API Keys in GrowthBook.
- An assistant that can hold two MCP connections at once, and an A/BLint project whose rules fit your team.
- Ten minutes to connect GrowthBook, because its MCP server runs on your machine through a small command and needs the key you just made.
Connect GrowthBook and A/BLint
- Add the GrowthBook MCP server to your assistant using the setup in GrowthBook's MCP documentation, which runs the @growthbook/mcp package with your GrowthBook API key, and restart your assistant so it picks the server up.
- Add A/BLint in the same assistant at https://explint.com/mcp and finish the browser sign-in, or use an API key from the MCP page in your A/BLint workspace if your assistant asks for a key instead.
- Ask the assistant to list your draft experiments in GrowthBook, because seeing your own experiment names come back tells you the key and the connection both work.
- Name the experiment you want checked and your A/BLint project, so the assistant reads one draft and checks it against one rule set.
How the check runs
- The assistant reads the experiment from GrowthBook, including its name, hypothesis, description, variations, metrics, and traffic split.
- It turns that into one clear piece of text that keeps the headings your team uses, since a tidy text helps the checker and helps you compare the report against the draft.
- It sends the text to A/BLint with ablint__lint and gets back errors, warnings, and passes.
- It lays the findings beside the GrowthBook fields they came from, so you can see whether a gap lives in the hypothesis, the metrics, or the run settings.
- You edit the draft in GrowthBook, then ask for a fresh check, and the assistant confirms which findings cleared and which still need work.
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 GrowthBook MCP tools to read the draft experiment called [experiment name]. Build one text from its hypothesis, description, variations, primary and guardrail metrics, traffic split, and run length. Lint that text with explint.com against the project [your A/BLint project name]. Show me each error and warning with the GrowthBook field it came from. Do not change anything in GrowthBook yet. Suggest edits in this chat, and when I update the draft, read it again and lint it again.
What A/BLint looks for
A/BLint scores the text against the rules switched on in your project. The default project uses the rules below, and your team can turn rules off, change how strict they are, or add its own rules in plain English. 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.
| Rule | Level | In plain words |
|---|---|---|
| hypothesis/names-metric-and-direction | error | The guess names the number it expects to move and which way it should move, such as a rise in checkout completion. |
| metrics/has-one-primary-metric | error | One main number decides the test, so the team agrees before the test starts which result matters most. |
| guardrails/are-listed | error | The write-up names the numbers that must not get worse, such as speed, errors, refunds, or people leaving. |
| guardrails/have-launch-thresholds | error | Each guardrail has a clear limit that would stop a launch, written as a number the team can check without debate. |
| variants/control-is-described | error | The current experience is described well enough that a reader who has never seen it can picture what people see today. |
| variants/each-differs-from-control-stated | error | Each version says exactly what changes, so the team can tell afterwards which change caused the result. |
| power/has-a-sample-size-calculation | error | The plan shows how many people the test needs, worked out from the current rate and the smallest change worth caring about. |
| duration/covers-full-business-cycles | error | The test runs long enough to cover full weeks, so a busy Monday and a quiet Sunday both count in the result. |
An example you can compare against
Before
New pricing page
- Hypothesis
- The new pricing page will convert better.
- Primary metric
- Conversion
- Variations
- Control, New page
- Traffic
- 50 percent
After, checked again
Simpler pricing table for the Starter plan
- Hypothesis
- If we replace the feature matrix with three plain rows that name the price, the seat limit, and the support level, then the share of pricing page visits that start a trial will rise, because support chats show visitors cannot tell which plan fits a small team.
- Main number
- Share of pricing page visits that start a trial.
- Guardrails
- Pricing page load time must not get worse by more than 0.3 seconds, and refund requests in the first month must not rise.
- Versions
- Control is the current matrix. The test version changes only the table, with the same prices and the same trial button.
- Split and size
- 50/50, about 18,000 visits over three full weeks, enough to spot a 1.5 point rise.
- Decision rule
- Ship if the main number rises and both guardrails hold. Run again with a new table if the result is flat.
Still flagged on the rewrite
- errorguardrails/have-launch-thresholdsOne guardrail carries a number and this one does not, so only half the guardrails can be checked without debate.
- warningrandomization/states-the-unitVisits are counted, and the plan never says a returning visitor stays in the same version.
The stronger plan describes the current page before it describes the new one, and it gives the decision rule its own line so nobody has to invent it after the results arrive. GrowthBook already asks for much of this in its experiment fields, so the check stays quick once filling those fields fully becomes habit.
Fix what it finds and check again
Start with the errors, and have the assistant suggest each rewrite in the chat before anything is written back to GrowthBook, so wording your team already agreed stays yours to approve. Rewrite the experiment plan so a teammate reading it cold could say what will change, what number will judge it, and what would stop a launch, then lint the same experiment plan again and ask which rules now pass that failed before.
Limits and things to check yourself
- GrowthBook's MCP server talks to the GrowthBook API with the key you give it, so keep that key in your assistant's private settings and use a read only key when you only want checks.
- Numbers that live in a linked dashboard or a warehouse query will not reach the checker, so paste the current rates and the sample size working into the experiment description.
- A/BLint checks the plan as written. It does not check your feature flag code, your tracking, or whether the metric is wired up correctly in GrowthBook.
- A passing score says the write-up covers what the rules ask for. It cannot say the idea is worth testing, that the traffic exists to reach a clear result, or that the change is safe to build, and those calls stay with your team.