Catch poorly planned A/B tests before they go live

Install the connector in your assistant

Every client connects to the same remote server, and they differ only in where the URL or the config block goes, so pick the assistant you work in and follow the steps written for it.

https://explint.com/mcp

A first session, from connecting to a lint you can act on

The session below is the order an assistant works in when it meets your organization for the first time, and each step names the tool that carries it so you can ask for the same steps in plain language.

1. 1

   Read the documentation the server carries

   Call ablint__docs with no arguments when the surface is unfamiliar, and keep the markdown it returns for the rest of the session because every later call is shaped from it and the call itself reads nothing, writes nothing, and spends no lint request.

   { "tool": "ablint__docs", "arguments": {} }
2. 2

   Find the project, or create the one the work needs

   List the projects in the organization to learn the slugs that already exist, and create a project only when the spec belongs somewhere new, since every rule and every lint hangs off a project.

   { "tool": "ablint__project", "arguments": { "operation": "list", "list": {} } }
3. 3

   Read the rules a lint will judge against

   List the rules inside the project before the first lint runs, and add a rule for any check the team keeps making by hand, because a lint can only report against rules that are present and switched on.

   { "tool": "ablint__rule", "arguments": { "operation": "list", "list": { "projectSlug": "checkout-cross-sell" } } }
4. 4

   Lint the spec and work through what comes back

   Send the spec as content with the project slug, then take the errors first because an error means the test cannot answer its question, and take the warnings next because a warning means the result will be hard to judge even when the test runs.

   { "tool": "ablint__lint", "arguments": { "projectSlug": "checkout-cross-sell", "content": "Hypothesis: a full-width add-to-cart button on phones increases checkout completion." } }

What the four tools do

Two tools take an operation of create, update, remove, or list and carry that operation’s arguments in the field named after it. One tool lints directly and one returns the documentation. No call names an organization, because the credential you connected with decides which organization every call works in.

{}

{
  "operation": "create",
  "create": { "name": "Checkout cross-sell" }
}

{
  "operation": "create",
  "create": {
    "projectSlug": "checkout-cross-sell",
    "ruleKey": "hypothesis/names-metric",
    "ruleTitle": "Names the metric",
    "ruleInstruction": "The hypothesis names the metric it expects to move."
  }
}

{
  "projectSlug": "checkout-cross-sell",
  "content": "Hypothesis: a full-width add-to-cart button on phones increases checkout completion."
}

Listings come back in a fixed order, projects by title and rules by creation, with 25 rows at a time unless a call asks for a limit between 1 and 100. Pass back the nextCursor each answer returns until it comes back empty. A project holds at most 50 rules, because every rule becomes a question on every lint.

Prompts that do useful work on the first try

Each prompt below names the project and the order you want the findings in, which is the detail that decides whether the reply is something you can act on or a summary you have to unpick.

• Lint one spec and explain the errors first

  Use A/BLint to lint the spec below against the checkout-cross-sell project. List the errors before the warnings, quote the sentence that breaks each rule, and say what change would satisfy it. Spec:

  Copy prompt

• Work through a backlog in rule order

  List my A/BLint projects, then lint each spec I paste against the Default project. Group the findings by rule key and finish with the rule that breaks most often, because that rule is where the backlog needs a template fix.

  Copy prompt

• Add the check the team keeps making by hand

  Add a rule to the checkout-cross-sell project with A/BLint. Use the key guardrail/revenue, the title Revenue guardrail is declared, severity warning, and the instruction that any test touching checkout declares a revenue guardrail with a number it can be compared against.

  Copy prompt

• Fix the hypothesis and lint it again

  Rewrite the hypothesis in the spec below so it names the metric, the direction it should move, and the reason to believe it, then lint the rewritten spec with A/BLint and show me what still breaks. Spec:

  Copy prompt

• Check the tool shapes before calling them

  Call ablint__docs and, from the documentation it returns, tell me which A/BLint tool adds a rule to a project and exactly which arguments that call needs.

  Copy prompt

Sign in with OAuth, or send an API key

The server accepts one bearer credential on every request, and the credential is what ties every project, rule, and lint call to a single organization, so one connection never reaches another organization’s rows.

Authorization: Bearer <api key>

Allowance, caps, and what a refusal means

Linting is the only work that spends anything, because each lint sends the spec and one question per switched-on rule to the model, while project and rule calls and the documentation call stay free.

Free allowance

An organization starts with 150 successful lint requests granted once, and the count runs over every request it has ever made, so the allowance covers the whole life of the workspace and never resets from month to month.

After the allowance

Lint requests cost $0.50 per 1,000 once credits are bought on the Billing page, and a lint that arrives with nothing left to spend is answered 402 with a message that links to that page, while a failed lint is recorded and stays off the bill.

Passing a rule

A rule passes at a probability of 0.8 or more, and below that line the break is listed under the severity the rule carries, with quality_score reporting the share of the project’s switched-on rules the spec passed.

Content size

A spec can arrive as markdown, HTML, or plain text, an image embedded as base64 is dropped before the spec is judged because the image would cost more to read than the lint itself, and content beyond the acceptable size comes back as an error before any model is called.

Plain refusals

A call that leaves out an argument it always needs names what it missed, and the refusals you are most likely to meet are a project name no project carries, a rule key the project does not hold, the Default project refusing removal, and a project with no rule switched on to lint against.

The same projects, rules, and lint work are available over REST for a script or an agent that sends HTTP, and the documentation carries every endpoint beside the OpenAPI document an agent can fetch in one request.