LiveVariant

io.github.livevariantPublished by GitHub account livevariantv0.1.5Updated Oct 24, 2026

Build, inspect and read adaptive A/B tests. Config travels in the URL; no account or API key needed.

VerifiedStreamable HTTPWeb executableData & AnalyticsBusiness & Commerce

Overview

AI-generated overview

LiveVariant lets an assistant build, inspect and read adaptive A/B tests, with config carried in the URL and no account needed on the hosted service.

What you can do
Create tests with one variant or several slots, returning run URLs and a stats secret, and get the constraints for writing variants against them (build_test, variant_brief). Decode and lint an existing test for slots, variants, context and serving problems before a campaign goes out (inspect_test). Turn your own performance estimates into model priors so a test does not start from scratch (generate_priors). Fetch results with the probability each combination is best and the expected cost of stopping now (get_stats). Check whether a test is claimed by an account and whether redirect destinations are verified domains, and list tests for the signed-in account (get_test_status, list_tests). Attt
When to use it
Use it when you want an assistant to draft, sanity-check or interpret A/B tests for email or web campaigns, especially when comparing several elements at once or deciding whether to stop a test. The hosted endpoint suits quick use without setup; self-hosting suits teams running their own deployment.
Requirements
Either the hosted remote endpoint or the npm package run locally with Node.js via npx. No account or API key is needed for the hosted service. For a self-hosted deployment, set LIVEVARIANT_SERVER_URL and, if endpoints are gated, LIVEVARIANT_API_TOKEN and LIVEVARIANT_ASSET_UPLOAD_TOKEN.
Before you install
Tests are created and registered, and images uploaded, so the server writes data on the deployment. build_test returns a freshly generated stats secret and register_test needs a stats secret plus a publishable key; treat these as credentials. Uploaded assets are only served with short-lived signatures. Pointing it at a self-hosted URL sends requests there.

Installation

In SourceWeft

  1. Open LiveVariant in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.

Use with an agent

Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.

Read https://sourceweft.com/mcp/io.github.livevariant%2Flivevariant/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.

Read the install guide the agent follows

Other MCP clients

Add this to your client's mcpServers config.

{
  "mcpServers": {
    "livevariant": {
      "type": "http",
      "url": "https://livevariant.com/mcp"
    }
  }
}

README

@livevariant/mcp

MCP server for LiveVariant: build, inspect and read adaptive A/B tests from Claude, ChatGPT, Copilot or any MCP client.

bash
npx -y @livevariant/mcp

Set runtime environment variables before starting the MCP server when you point it at a self-hosted deployment:

  • LIVEVARIANT_SERVER_URL: the deployment origin to call.
  • LIVEVARIANT_API_TOKEN: the deployment's LV_API_TOKEN, when /mcp or /api/v1/* is gated.
  • LIVEVARIANT_ASSET_UPLOAD_TOKEN: the deployment's LV_ASSET_UPLOAD_TOKEN, when /assets is gated.

The hosted endpoint at https://livevariant.com/mcp offers the same tools with nothing installed.

Part of livevariant/livevariant; the repository README covers the whole system. AGPL-3.0.

Source: packages/mcp/README.md at commit b30beb4

Tools

9

build_test

Build a test

Creates a LiveVariant test and returns every URL needed to run it, plus a freshly generated stats secret. Pass `variants` to test one element, or `slots` to test several at once (hero image AND call-to-action, say). With slots the test optimizes the COMBINATION: one model learns how the elements interact, which two separate tests structurally cannot see. There is no algorithm to pick either way; every test runs the same joint model, sized from its shape. By default, nothing is registered anywhere: the config IS the test, encoded into the URLs, and the test's identity is a hash of it. Pass `publishableKey` on an account-enabled deployment to also register the new test to that key's organization, so it appears under My tests; the config and URLs are still the test, and registration failure is returned as a warning rather than failing the build. Editing a variant later produces a DIFFERENT test with its own empty history, which is usually what you want per campaign but is worth saying out loud to whoever you are building this for. The stats secret is returned once and never again. Only its hash goes into the config, so nobody, including this service, can recover it. Give it to the person who will read the results.

ParametersnameslotsregioncontextvariantsredirectUrlvariantParamslotRedirectspublishableKey

inspect_test

Inspect a test

Decodes a test and describes it: slots, variants, context, and whether it can be served by redirect. Also lints it for the mistakes that only show up once a campaign is out, such as an email test whose context comes from geo (which a mail proxy answers about itself). Use this before sending anything, and to answer 'what is this link?'.

Parameterstestconfig

generate_priors

Add warm-start priors

Takes YOUR estimate of how each variant will perform and converts it into the prior the model starts from, so a test does not spend its first visitors rediscovering what you already suspect. You supply the guess; this does the arithmetic and the capping. That capping is the point: a prior is expressed as pseudo-observations, and it is deliberately held weak enough that real data overrides it quickly. The response says exactly how many real visitors per variant it takes to wash your guess out, so you can judge whether you have been too confident. Being wrong here costs a little early traffic, not the test. Priors are outside the identity hash, so the test keeps its id, its URLs and any history it already has. Pass `when` to make the belief hold for ONE segment only ("image B is the one for the blue segment"). Without it the belief is about every visitor, which is a different and much stronger claim.

Parameterstestwhenconfigbeliefsrequiredconfidence

get_stats

Read a test's results

Fetches a test's results and works out what they mean. Alongside the raw counts it returns the probability that each combination is genuinely best and the expected cost of stopping now and keeping the leader. Use those rather than comparing conversion rates by eye: a variant ahead 2/10 to 1/10 looks twice as good and is very close to a coin flip, and that mistake is the single most common way an A/B test gets called wrong. Multi-slot tests also report per-slot marginals: how each variant did across every combination it appeared in. Needs the stats secret. If you have the manage URL, its #fragment IS the secret and it will be used automatically.

ParameterstestconfigstatsSecret

get_test_status

Check a test's account and domain status

Reports what the deployment's registry knows about a test: whether it is claimed into an account (and by which organization), and whether each redirect destination is a verified domain. Unverified destinations work, but visitors see a 'Redirecting you to…' continue screen first. When you see verified: false, tell the user to verify the domain under Settings on the dashboard; the three ways are a DNS TXT record, serving the well-known file, or having the SDK tag with their publishable key live in the site's source. If the test is unclaimed, remind them the manage URL claims it in one click when opened signed in. Requires the test's stats secret, the same as get_stats. A manage URL's #fragment is used automatically.

ParameterstestconfigstatsSecret

list_tests

List my tests

Lists tests registered to the signed-in account, newest first, with cursor pagination and an optional case-insensitive name filter. Only exists on deployments with accounts, and only answers for an identified caller: unlike every other tool, WHOSE tests these are cannot be expressed as an argument. Each entry carries the encoded config, which inspect_test and get_stats accept directly.

Parametersqlimitcursor

register_test

Register a test to an account

Registers a test you built earlier to the organization a publishable key belongs to, so it shows under My tests and its stats are readable from the dashboard without the secret. Use this only when the user provides both the test's stats secret and a publishable key for an organization they administer. The stats secret must match the hash inside the config, and the publishable key identifies the organization to register into. Prefer passing publishableKey to build_test directly: it registers at creation in one step. Keyless tests cannot be registered this way (nothing to prove with); they register through the tag on a verified domain. The organization can remove a listing from its dashboard (the test itself keeps serving).

ParametersconfigrequiredstatsSecretrequiredpublishableKeyrequired

upload_image

Upload an image

Uploads an image to the deployment's asset store and returns its URL, for use as a variant's `image` (email tests) or `url`. The returned URL is deliberately not fetchable on its own: assets are only served with a short-lived signature that the serve endpoints mint per request, so uploading here does not create free static hosting. Use `previewUrl` (valid for an hour) to check what was stored. Storage is content-addressed: the id is the sha256 of the bytes, so uploading the same image twice is harmless and returns the same URL. Raster images only; SVG is refused because it can carry scripts. Not every deployment enables asset hosting, and this tool says so plainly when yours does not.

ParametersdatarequiredcontentTyperequired

variant_brief

Brief for writing variants

Returns the constraints to write or generate test variants against, for email or web, plus the rules that decide whether a test can be read at all once it runs. The one that matters most: one idea per slot. To vary two elements, give the test two slots and let it learn the combination, rather than bundling both changes into one variant and never learning which half worked. Ask for this before drafting variants, then produce them yourself against what it returns.

Parametersgoalrequiredcountformatrequiredchannelrequiredaudience

Version history

1
  1. v0.1.5LatestSep 16, 2026

Score

100% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 daysRequired25 pts
  • Auth declaredRequired10 pts
  • Tools listedRequired15 pts
  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts