Lint Eppo experiments with explint.com before you launch
Eppo does not publish an MCP server of its own at the time of writing, so read Eppo through its API and your assistant, or a short copy and paste step, and check the experiment plan with explint.com before launch.
What you need before you start
- An Eppo workspace with an experiment or feature flag drafted, including the assignment setup and the metrics you plan to judge it by.
- A way for your assistant to reach the plan, which for most teams means an Eppo API key used through a small custom MCP or API tool your developer sets up, or the plan copied from Eppo into the chat.
- An A/BLint account with a project whose rules your team trusts.
- Agreement in the team that the check happens before the flag starts taking traffic, while changes are still cheap.
Connect Eppo and A/BLint
- Connect A/BLint in your assistant at https://explint.com/mcp and finish the sign-in, since A/BLint is the MCP server in this pairing and it works the same way it does in every other guide here.
- For Eppo, pick one of two paths and stick to it for the whole team. A developer can give the assistant read access to the Eppo API with an API key through your own MCP or API tooling, or you can open the experiment in Eppo and paste its hypothesis, variations, allocation, and metrics into the chat each time.
- Ask the assistant to repeat the plan back to you in its own words before you lint, because that read-back catches a missed field or a stale paste before the checker scores the wrong text.
- Name your A/BLint project, so the assistant checks against the same rules every time.
How the check runs
- The assistant collects the plan from Eppo through the API path your team set up, or from the text you pasted, and it lists any missing piece out loud before it checks anything.
- It shapes the plan into one text with clear headings for the hypothesis, the versions, the split, the metrics, and the run time.
- It sends that text to A/BLint with ablint__lint and gets back errors, warnings, and passes.
- It walks you through the findings in the order you would fix them in Eppo, starting with the errors.
- You edit the experiment in Eppo, refresh the text, and ask for a second check so the final report matches the plan you are about to launch.
Copy and paste this prompt
Change the words in square brackets to name your own project, board, or test.
Prompt for your assistant
Here is an experiment plan from Eppo, from the API or pasted below. First, repeat the plan back with headings for hypothesis, versions, who gets split and in what share, primary metric, guardrail metrics, and run time, and tell me if any heading has nothing under it. Then lint the full text with explint.com against the project [your A/BLint project name]. Show me each error and warning and the words that caused it. Do not invent numbers I did not give you. Suggest fixes in this chat, and lint again when I give you the updated plan. Plan: [paste or name the Eppo experiment]
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/is-falsifiable | error | The idea makes a clear guess that a result could prove wrong, instead of saying the change will improve things in general. |
| 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. |
| randomization/states-the-unit | error | The plan says who or what gets split into groups, such as a person, a visit, or an account, because every rate depends on that choice. |
| 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. |
| 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. |
| rollout/has-a-rollback-plan | error | The plan says how the change gets turned off quickly if it hurts people, and who can make that call. |
An example you can compare against
Before
new-search
- Hypothesis
- New search will improve engagement.
- Metrics
- Clicks, revenue
- Allocation
- 50/50
- Status
- Ready to start
After, checked again
Search results grouped by product type
- Hypothesis
- If we group search results by product type with a heading for each group, then the share of searches that end in a product view will rise, because support tickets and session recordings show people scrolling past mixed results without spotting the type they wanted.
- Main number
- Share of searches that end in a product view.
- Guardrails
- Search load time must not get worse by more than 0.2 seconds, and searches with no result must not rise.
- Versions
- Control shows one mixed list. Test groups the same results under type headings, with no change to ranking inside each group.
- Split
- Signed in users, split by user, 50/50, staff accounts left out.
- Size and time
- About 30,000 searches over two full weeks, enough to spot a 2 point rise.
- Stop rule
- Turn the flag off if load time breaks its limit for a full day, and the on-call engineer can make that call.
Still flagged on the rewrite
- errordecision/has-criteria-before-launchThe stop result is written down in detail, and no ship result sits beside it.
- warningguardrails/have-launch-thresholdsThis guardrail would be judged by feel, because no rise is given a number.
The stronger plan names the unit that gets split and the person who can stop the test, two details that are easy to leave in someone's head and painful to settle once traffic is flowing. Eppo is strong on assignment and analysis, so the written plan is the place where the reasoning needs to live for the whole team to share.
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 Eppo, 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
- Eppo has no published MCP server of its own at the time of writing, so the read step needs your own API tooling or a paste, and you should re-check Eppo's documentation if that changes.
- Eppo now sits inside Datadog after its acquisition in 2025, so product names, docs, and API paths may move. Follow the Eppo docs your workspace links to, and check any old bookmark against them before you trust it.
- If you use the paste path, the check is only as fresh as your paste. Re-paste after every edit in Eppo, and ask the assistant to show you the exact text it linted.
- 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.