How it works
- 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.
- Install the ExpLint MCP at https://explint.com/mcp to enable your agent to audit tests.
- Run the prompt below to audit these plans before the work starts.
How the check runs
- 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.
- It sends that text to ExpLint with
explint__lint, which returns errors, warnings, and passes, each finding naming the rule behind it. - 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.
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.
| Rule | Level | In plain words |
|---|---|---|
| hypothesis/names-metric-and-direction | error | The 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-listed | error | Amplitude keeps guardrail metrics beside the primary one, and each guardrail needs a limit rather than only a name in the list. |
| randomization/states-the-split | error | The 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-cycles | error | Start and end dates should span full weeks, since a window that opens midweek reads the same visitors differently every day of its life. |



