How it works
- Point your AI assistant or coding agent at the Firebase Remote Config experiments API for your project, signing in with credentials that carry the firebase.remoteconfig or cloud-platform scope, because the Firebase MCP server reads Remote Config templates and carries no A/B Testing tools.
- 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 display name and description, variants with their weights, the primary objective beside its secondary objectives, the activation event, and the state with start and end times, then states plainly where targeting, exposure, run length, and sample size need your words.
- 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 the Firebase console and ask for a fresh read, since the experiments API reads and deletes but cannot create or update an experiment.
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 Firebase Remote Config experiments API to read the experiment [experiment name] in project [Firebase project ID]. Build one text from its display name and description, variants and weights, primary and secondary objectives, and state with start and end times, and state which of targeting, exposure, run length, and sample size the API did not return. Lint it with explint.com against project [your ExpLint project name]. Show each error and warning with its Firebase field. Do not launch or edit the experiment. Suggest fixes here and re-check after I update Firebase.
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 |
|---|---|---|
| randomization/states-the-split | error | Variant weights are the plan's traffic split, and they belong in the text the lint reads rather than only in the console. |
| variants/control-is-described | error | The control variant keeps the current values, so the plan should say what people see today before it describes the alternatives. |
| duration/covers-full-business-cycles | error | The state's start and end times should span full weeks, since the console records dates rather than a measurement window. |
| decision/has-criteria-before-launch | error | Secondary objectives support the result rather than decide it, so the plan should record what outcome would roll the variant out. |
