Check Amplitude variants and metrics before launch

Amplitude experiments carry variants, traffic allocation, and dates, and the check reads them alongside metric ids where names are unavailable.

How it works

  1. Connect the Amplitude MCP server at https://mcp.amplitude.com/mcp for US projects or https://mcp.eu.amplitude.com/mcp for EU projects to your AI assistant or coding agent, then sign in with OAuth 2.0 because API-key-only clients cannot connect.
  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 name, description and state, variants with their traffic allocation, the primary, secondary and guardrail metrics, start and end dates, and bucketing choices, and it reports metric identifiers where names cannot be fetched.
  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 Amplitude and ask for a fresh read, and where your account allows MCP writes the agreed field changes can go through the same connection after you review them.

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 Amplitude MCP tools to read the experiment [experiment name or ID]. Build one text from its description, state, variants and traffic allocation, primary, secondary and guardrail metrics, and start and end dates, reporting metric IDs where names are unavailable. Lint it with explint.com against project [your ExpLint project name]. Show each error and warning with its Amplitude field. Do not launch or edit the experiment yet. Suggest fixes here and re-check after I update Amplitude.

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 its primary metric and the direction it expects, since Amplitude records the metric as a setting and the description carries the expectation.
guardrails/are-listederrorAmplitude keeps guardrail metrics beside the primary one, and each guardrail needs a limit rather than only a name in the list.
randomization/states-the-spliterrorThe allocation percentages belong in the plan text, because the traffic split is what the start and end dates are judged against.
duration/covers-full-business-cycleserrorStart and end dates should span full weeks, since a window that opens midweek reads the same visitors differently every day of its life.

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