Lint AB Tasty campaigns with explint.com before you launch
AB Tasty publishes an MCP server for its feature experimentation work, with a narrower reach than its full web campaign product, so check feature tests through the server and web campaigns through the API or a careful paste, with explint.com before launch either way.
What you need before you start
- An AB Tasty account with a test drafted, either as a feature experiment that the MCP server can reach or as a web campaign you can read through the API or paste from the editor.
- For the MCP path, the @abtasty/mcp-server package set up in your assistant with the credentials AB Tasty's server asks for, which your developer can install from its project page.
- An A/BLint account with a project for your team, connected in the same assistant.
- A clear note of which AB Tasty product your test lives in, because the fastest way to lose an hour here is asking one tool about the other product's campaigns.
Connect AB Tasty and A/BLint
- For a feature experiment, add AB Tasty's MCP server following the @abtasty/mcp-server setup, which runs the server on your machine, and give it the account details it asks for.
- 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.
- For a web campaign, ask your developer to read the campaign through the AB Tasty API with your account keys, or open the campaign and paste its hypothesis, variations, targeting, traffic, and goals into the chat in a tidy order.
- Whichever path you used, ask the assistant to repeat the plan back with headings before you lint, so you can catch a missing variation or goal while fixing it is still a quick paste.
How the check runs
- The assistant collects the plan from AB Tasty through the MCP server, the API, or your paste, and it names the path it used so the whole team knows how fresh the text is.
- It shapes the plan into one text with headings for the hypothesis, the versions, the audience, the traffic split, the main goal, and the guardrails.
- It sends that text to A/BLint with ablint__lint and brings back errors, warnings, and passes.
- It ties each finding to the AB Tasty field or setup step it came from, and it drafts plainer wording for the weak fields.
- You update the test in AB Tasty, refresh the text through the same path, and ask for a second lint before you 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 a test plan from AB Tasty, read through its MCP server, its API, or pasted below. First, repeat it back with headings for hypothesis, versions and what each one changes, audience, traffic split, main goal, guardrail goals, and run time, and say which headings are empty. 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 launch anything and do not invent numbers. Suggest fixes in this chat, and lint again when I give you the updated plan. Plan: [paste or name the AB Tasty test]
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. |
| 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. |
| 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
Product page refresh
- Goal
- Increase conversions
- Variations
- Original, New design
- Traffic
- 50/50
- Segment
- All visitors
After, checked again
Delivery date shown on the product page
- Hypothesis
- If the product page shows the delivery date beside the price instead of only at checkout, then the share of product views that add to basket will rise, because our research sessions show people leaving to look for delivery information and not coming back.
- Main goal
- Share of product views that add an item to the basket.
- Guardrails
- Product page load time must not get worse by more than 0.3 seconds, and returns must not rise.
- Versions
- Control keeps delivery details at checkout only. Test adds one delivery date line beside the price, with no other change to the page.
- Audience and traffic
- All product page visitors, 50/50, for two full weeks including two weekends.
- Decision rule
- Ship if the main goal rises and the guardrails hold.
Still flagged on the rewrite
- errorguardrails/have-launch-thresholdsReturns are named as a guardrail with no limit the team could check.
- warningpower/has-a-sample-size-calculationThe audience and split are clear, and no traffic count sits behind them.
The stronger campaign picks one main goal out of the goals AB Tasty can track, and it describes the control in words a new starter could picture. Teams that run many campaigns build this habit quickly once the checker starts asking the same kind questions every time.
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 AB Tasty, so wording your team already agreed stays yours to approve. Rewrite the campaign 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 campaign plan again and ask which rules now pass that failed before.
Limits and things to check yourself
- AB Tasty's published MCP server focuses on feature experimentation and related setup, so web campaigns may need the API or paste path in this guide, and you should confirm the current scope in the server project before you promise the MCP path to your team.
- Visual editor changes can hide the real difference between variations behind a name, so describe each variation in sentences before you lint.
- Segment and targeting logic can carry legal or regional limits that a text check cannot judge, so keep your usual targeting review in place.
- 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.