# LiveVariant (npm · @livevariant/mcp)

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

- Trust score: 83/100 (high trust)
- Change this week: +4
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-21

## Components

- remote · `livevariant.com`: 85/100, [markdown](https://verifymcp.io/servers/livevariant-livevariant/livevariant.md), [page](https://verifymcp.io/servers/livevariant-livevariant/livevariant)
- npm · `@livevariant/mcp`: 83/100 (this document), [markdown](https://verifymcp.io/servers/livevariant-livevariant/livevariant-mcp.md), [page](https://verifymcp.io/servers/livevariant-livevariant/livevariant-mcp)

## Channel facts

- Registry: `npm`
- Package: `@livevariant/mcp`
- Version: `0.1.5`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-09-21.

- **Supply Chain Security**: 98/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - No install/post-install scripts declared.
  - 31 of 97 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 45/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (AGPL-3.0).
  - Actively maintained (last published 24 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 74/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 2588 tokens (~369/item across 7 items; 6 tools + 1 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 93/100
  - Stability observed for 28 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 97/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 88% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 6 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 8 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the LiveVariant MCP server?

LiveVariant runs locally as an npm package, launched with npx -y @livevariant/mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add livevariant-livevariant -- npx -y @livevariant/mcp
```

### Cursor

```json
{
  "mcpServers": {
    "livevariant-livevariant": {
      "command": "npx",
      "args": [
        "-y",
        "@livevariant/mcp"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "livevariant-livevariant": {
      "command": "npx",
      "args": [
        "-y",
        "@livevariant/mcp"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add livevariant-livevariant -- npx -y @livevariant/mcp
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "livevariant-livevariant": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "@livevariant/mcp"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add livevariant-livevariant --command npx --arg -y --arg @livevariant/mcp
```

### Hermes

```yaml
mcp_servers:
  livevariant-livevariant:
    command: "npx"
    args: ["-y", "@livevariant/mcp"]
```

### Netclaw

```json
{
  "McpServers": {
    "livevariant-livevariant": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "@livevariant/mcp"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add livevariant-livevariant -t stdio -c npx -a -y @livevariant/mcp
```

### Other

```json
{
  "mcpServers": {
    "livevariant-livevariant": {
      "command": "npx",
      "args": [
        "-y",
        "@livevariant/mcp"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-09-21 (score 83, +1)

No change was recorded against any check on this day. Stability & Change Management went from 90 to 93. That category is still filling its 30-day observation window: 27 days of observed history at the previous scan, 28 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-19 (score 82, +1)

No change was recorded against any check on this day. Stability & Change Management went from 83 to 87. That category is still filling its 30-day observation window: 25 days of observed history at the previous scan, 26 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-17 (score 81, +1)

No change was recorded against any check on this day. Stability & Change Management went from 77 to 80. That category is still filling its 30-day observation window: 23 days of observed history at the previous scan, 24 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-15 (score 80, +1)

No change was recorded against any check on this day. Stability & Change Management went from 70 to 73. That category is still filling its 30-day observation window: 21 days of observed history at the previous scan, 22 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-13 (score 79, +1)

No change was recorded against any check on this day. Stability & Change Management went from 63 to 67. That category is still filling its 30-day observation window: 19 days of observed history at the previous scan, 20 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-11 (score 78, +1)

No change was recorded against any check on this day. Stability & Change Management went from 57 to 60. That category is still filling its 30-day observation window: 17 days of observed history at the previous scan, 18 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-09 (score 77, +1)

No change was recorded against any check on this day. Stability & Change Management went from 50 to 53. That category is still filling its 30-day observation window: 15 days of observed history at the previous scan, 16 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-06 (score 76, +1)

No change was recorded against any check on this day. Stability & Change Management went from 40 to 43. That category is still filling its 30-day observation window: 12 days of observed history at the previous scan, 13 at this one. The score rises as the window fills, whether or not the server changes.

## MCP tools (6)

### `build_test` (~689 tokens)

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.

Input parameters:

- `context` (array): Dimensions to learn a separate winner for.
- `name` (string): A label for your own reference, and the one field worth spending a merge tag on in a recurring ESP template: it is part of the test's identity, so n={{campaign_name}} mints a separate, separately rea…
- `publishableKey` (string): Registers the new test to the organization identified by a publishable key the user provides for an organization they administer. Result access stays tied to this test's stats secret. Only works on a…
- `redirectUrl` (string): Where clicks land when a variant does not say.
- `region` (string): Where the test's state lives. A placement hint (wnam, enam, sam, weur, eeur, apac, oc, afr, me) or "eu" for the EU jurisdiction (state guaranteed created and kept inside the EU). Defaults to the crea…
- `slotRedirects` (object): Where clicks on ONE element land, when elements point at different pages (a hero leading to the campaign landing page, a CTA below it to pricing). Keyed like `slots`. Falls back to `redirectUrl`; a v…
- `slots` (object): Multi-element test: variants per element, keyed by a short name like "hero" or "cta". The test serves and learns combinations.
- `variantParam` (string): Stamp the served combination into this parameter on redirect, e.g. "utm_content", so the test shows up in the customer's own analytics.
- `variants` (array): Single-element test: two or more variants. The first is the control.

Output parameters:

- `combinations` (number): How many distinct combinations the test chooses between.
- `config` (string): The encoded config: this is the test.
- `destinations` (array): Redirect destinations and whether each is a verified domain. Unverified means visitors see a 'Redirecting you to…' continue screen before landing; relay the verification warning to the user when pres…
- `emailTemplate` (object): Query-parameter spelling per slot for an ESP template: wire it once, then campaign managers fill only the merge fields. All links share one identical config string (names, ctx dims, kh and the landin…
- `region` (string|null): Where the test's state will live; null means first-request placement.
- `registeredTo` (string): The organization the test was registered to, when a publishableKey was given and accepted.
- `slotLinks` (object): Multi-slot tests only: the serve/click URL per element. The bare urls.serve returns 400 for these tests, because a serve must say which element it renders. The bare urls.click works when the destinat…
- `slots` (array): Canonical slot order with variant names, as stats reports them.
- `statsSecret` (string): Shown once. Store it now.
- `testId` (string)
- `urls` (object)
- `warnings` (array)

### `inspect_test` (~156 tokens)

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?'.

Input parameters:

- `config` (string): Alias for `test`: the same value under the name build_test returns it as (`config`). Pass one or the other.
- `test` (string): The test: an encoded config, or any LiveVariant URL containing one (serve, click, pixel, manage), or a query-parameter serve URL. Paste whatever you have.

Output parameters:

- `combinations` (number)
- `context` (array)
- `findings` (array)
- `name` (string)
- `region` (string|null)
- `resultsReadable` (boolean): False when the config has no stats key, which is permanent.
- `slots` (array)
- `testId` (string)

### `generate_priors` (~373 tokens)

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.

Input parameters:

- `beliefs` (array, required)
- `confidence`: How much your guess is worth in observations. low=5, medium=15, high=30, or give a number directly. Higher means the test trusts you for longer before the data takes over.
- `config` (string): Alias for `test`: the same value under the name build_test returns it as (`config`). Pass one or the other.
- `test` (string): The test: an encoded config, or any LiveVariant URL containing one (serve, click, pixel, manage), or a query-parameter serve URL. Paste whatever you have.
- `when` (object): Context this belief is limited to, as dimension key to value (e.g. {"color": "blauw"}). The keys must be dimensions the test declares. Omit it for a belief about every visitor.

Output parameters:

- `config` (string)
- `manageUrl` (string)
- `notes` (array)
- `priors` (array)
- `testId` (string)
- `washesOutAfter` (number): Roughly this many real visitors per variant and your guess stops mattering.

### `get_stats` (~240 tokens)

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.

Input parameters:

- `config` (string): Alias for `test`: the same value under the name build_test returns it as (`config`). Pass one or the other.
- `statsSecret` (string): Omit when passing a manage URL that carries it in the fragment.
- `test` (string): The test: an encoded config, or any LiveVariant URL containing one (serve, click, pixel, manage), or a query-parameter serve URL. Paste whatever you have.

Output parameters:

- `bySignal` (object)
- `combinations` (array)
- `contextBuckets` (number)
- `decision` (object)
- `excluded` (object)
- `slots` (object)
- `testId` (string)
- `totalAssignments` (number)

### `upload_image` (~204 tokens)

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.

Input parameters:

- `contentType` (string, required): The image's actual type; the server stores and serves it as this.
- `data` (string, required): The image bytes, base64-encoded (plain base64, not a data: URL).

Output parameters:

- `assetId` (string): sha256 of the bytes; the id inside the URL.
- `contentType` (string)
- `previewUrl` (string): Signed for one hour, to verify the upload.
- `size` (number)
- `url` (string): Use this as the variant's image/url. 403s without a signature, by design.

### `variant_brief` (~164 tokens)

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.

Input parameters:

- `audience` (string): Who sees it, if that shapes the copy.
- `channel` (string, required)
- `count` (integer)
- `format` (string, required): What each variant will be.
- `goal` (string, required): What the test should improve, e.g. 'more demo bookings'.

Output parameters:

- `goal` (string)
- `hosting` (string)
- `nextStep` (string)
- `rules` (array)
- `specs` (array)
- `variantCount` (number)

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/livevariant-livevariant/livevariant-mcp#diagnostics

## Score history

- 2026-09-21: 83
- 2026-09-20: 82
- 2026-09-19: 82
- 2026-09-18: 81
- 2026-09-17: 81
- 2026-09-16: 80
- 2026-09-15: 80
- 2026-09-14: 79
- 2026-09-13: 79
- 2026-09-12: 78
- 2026-09-11: 78
- 2026-09-10: 77
- 2026-09-09: 77
- 2026-09-08: 76
- 2026-09-07: 76
- 2026-09-06: 76
- 2026-09-05: 75
- 2026-09-04: 75
- 2026-09-03: 74
- 2026-09-02: 74
- 2026-09-01: 73
- 2026-08-31: 73
- 2026-08-30: 72
- 2026-08-29: 72
- 2026-08-28: 71
- 2026-08-27: 56
- 2026-08-26: 60
- 2026-08-25: 68
- 2026-08-24: 68

## Common questions

### What is the LiveVariant MCP server?

LiveVariant is an MCP server listed in the public MCP registry as io.github.livevariant/livevariant. Build, inspect and read adaptive A/B tests. Config travels in the URL; no account or API key needed. This page covers its npm package (@livevariant/mcp).

### Is the LiveVariant MCP server safe to use?

LiveVariant scores 83 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 21 September 2026. It declares no install or post-install scripts. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the LiveVariant MCP server expose?

LiveVariant exposes 6 tools: build_test, inspect_test, generate_priors, get_stats, upload_image, variant_brief. Their descriptions and schemas cost roughly 1,826 tokens of context every time the server is loaded.

### Is the LiveVariant MCP server still maintained?

LiveVariant is still listed as active in the MCP registry. We last reached this channel on 21 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the LiveVariant MCP server under?

LiveVariant declares the AGPL-3.0 licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- npm package: https://www.npmjs.com/package/@livevariant/mcp
- Socket report: https://socket.dev/npm/package/@livevariant/mcp
- Repository: https://github.com/livevariant/livevariant
- Website: https://livevariant.com/
- Changelog RSS feed: https://verifymcp.io/servers/livevariant-livevariant/livevariant-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/livevariant-livevariant/livevariant-mcp.json
- HTML version of this page: https://verifymcp.io/servers/livevariant-livevariant/livevariant-mcp