Lint Optimizely experiments with explint.com before you launch
Read an experiment from Optimizely with its MCP server, check the plan with explint.com in the same chat, and fix the gaps while the experiment is still in draft.
What you need before you start
- An Optimizely account with an experiment drafted, in Feature Experimentation or Web Experimentation, with its hypothesis and metrics filled in.
- Access to Optimizely's remote MCP server for experimentation, which your Optimizely admin may need to allow for your account.
- An assistant that can hold two MCP connections at once, and an A/BLint project for your team.
- A launch checklist slot where the check can happen before the experiment goes live, while the draft is still easy to change.
Connect Optimizely and A/BLint
- Add Optimizely's experimentation MCP server in your assistant at https://exp.mcp.opal.optimizely.com/mcp following Optimizely's quickstart for your assistant, and sign in with your Optimizely account.
- 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 a few of your experiments by name, because that confirms it can read the project you work in.
- Name the draft experiment and your A/BLint project, so the assistant checks one plan against one rule set.
How the check runs
- The assistant reads the experiment from Optimizely, including its hypothesis, variations, audience, traffic split, and metrics.
- It builds one text that keeps the Optimizely field names as headings, so you can find each finding again in the Optimizely screens without guessing.
- It sends the text to A/BLint with ablint__lint and brings back errors, warnings, and passes.
- It orders the findings by how much they would hurt the result, and it suggests plain wording you can paste back into Optimizely.
- You update the draft, then ask the assistant to read the fresh version and lint it again before you schedule the launch.
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 Optimizely MCP tools to read the draft experiment called [experiment name]. Build one text from its hypothesis, variations and what each one changes, audience, traffic split, primary and guardrail metrics, and planned run time. Lint that text with explint.com against the project [your A/BLint project name]. Show me each error and warning with the Optimizely field it came from. Do not launch or edit the experiment. Suggest wording in this chat, and re-check when I have updated the draft.
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. |
| hypothesis/explains-the-mechanism | warning | The write-up says why the change should alter what people do, in one or two plain sentences a new team member could follow. |
| 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/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/each-differs-from-control-stated | error | Each version says exactly what changes, so the team can tell afterwards which change caused the result. |
| variants/multi-change-bundles-are-labelled | error | When a version changes more than one thing at once, the write-up says so and treats the result as a result for the whole bundle. |
| randomization/states-the-split | error | The plan gives the share of traffic each version gets, so the team can judge whether the test can finish in time. |
| decision/has-criteria-before-launch | error | The team writes down before launch what result would ship, what result would stop, and what result would mean running the test again. |
An example you can compare against
Before
Homepage hero refresh
- Hypothesis
- A refreshed hero will lift engagement.
- Variations
- Control, Hero B, Hero C
- Primary metric
- Clicks
- Traffic
- 33/33/33
After, checked again
One clear promise in the homepage hero
- Hypothesis
- If the hero names the free delivery promise instead of a general brand line, then the share of homepage visits that reach a product page will rise, because our visitor surveys keep showing people leave to check delivery terms before they browse.
- Main number
- Share of homepage visits that reach a product page.
- Guardrails
- Homepage load time must not get worse by more than 0.3 seconds, and visits that end within ten seconds must not rise by more than 2 points.
- Versions
- Control keeps the current hero. Test changes only the headline and subheading, with the same image, button, and layout.
- Audience and split
- All homepage visitors, 50/50, for three full weeks, about 60,000 visits.
- Decision rule
- Ship if the main number rises and the guardrails hold. Keep the current hero if the main number falls.
Still flagged on the rewrite
- errorpower/has-a-sample-size-calculationA large traffic figure is quoted, and no working shows the smallest change it can spot.
- warningaudience/has-exclusion-criteriaEvery visitor is included, with staff, bots, and test traffic never mentioned.
The stronger plan keeps the test down to the words in the hero, so a lift can be read as a lift caused by those words. When a version changes the picture, the layout, and the copy together, the write-up needs to say so plainly and treat the result as a result for that whole package.
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 Optimizely, 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
- Optimizely has more than one product and more than one MCP offering, so make sure you connected the experimentation server and that it can see the project your draft lives in.
- Experiments built mostly in the visual editor can carry their real change as pictures and layout with few words, so describe what each version shows in the experiment description before you lint.
- The check reads the plan, and your team still owns the audience setup, the metric definitions, and the call on whether the result is strong enough to ship.
- 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.