Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

LiveVariant

REMOTE · LIVEVARIANT.COM · 2 COMPONENTS · SCANNED SEP 21

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

+3 this week 85 Trust /100
Trust breakdown (7 categories)

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →

Endpoint Security77
Transport & Reachability100
Schema Quality & AI Usability75
  • 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
  • AI-judged instruction clarity (excellent).Pass
  • Context-footprint check failed: tool/resource definitions use about 3174 tokens (~317/item across 10 items; 9 tools + 1 resources), over budget; trim descriptions and params. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management93
  • Stability observed for 28 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage97
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 89% of tool parameters carry a description.Partial
  • Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • We read all 9 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
  • An AI judge read all 11 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
  • Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Install

How do I install the LiveVariant MCP server?

LiveVariant is a hosted endpoint at https://livevariant.com/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

remote · livevariant.com

# add to Claude Code
claude mcp add --transport http livevariant-livevariant 'https://livevariant.com/mcp'
// .cursor/mcp.json
{
  "mcpServers": {
    "livevariant-livevariant": {
      "url": "https://livevariant.com/mcp"
    }
  }
}
// .vscode/mcp.json
{
  "servers": {
    "livevariant-livevariant": {
      "type": "http",
      "url": "https://livevariant.com/mcp"
    }
  }
}
# ~/.codex/config.toml
[mcp_servers.livevariant-livevariant]
url = "https://livevariant.com/mcp"
// opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "livevariant-livevariant": {
      "type": "remote",
      "url": "https://livevariant.com/mcp",
      "enabled": true
    }
  }
}
# add to OpenClaw
openclaw mcp add livevariant-livevariant --url 'https://livevariant.com/mcp' --transport streamable-http
# ~/.hermes/config.yaml
mcp_servers:
  livevariant-livevariant:
    url: "https://livevariant.com/mcp"
// ~/.netclaw/config/netclaw.json
{
  "McpServers": {
    "livevariant-livevariant": {
      "Transport": "http",
      "Url": "https://livevariant.com/mcp"
    }
  }
}
# add to Vellum
assistant mcp add livevariant-livevariant -t streamable-http -u 'https://livevariant.com/mcp'
// mcp.json
{
  "mcpServers": {
    "livevariant-livevariant": {
      "type": "http",
      "url": "https://livevariant.com/mcp"
    }
  }
}

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 20 Sept 26 +1

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

  • 18 Sept 26 +1

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

  • 16 Sept 26 +1

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

  • 14 Sept 26 +1

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

  • 12 Sept 26 +5
    • HTTPS: unverified → pass security
  • 10 Sept 26 +1

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

  • 8 Sept 26 +1

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

  • 6 Sept 26 +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.

Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 21 Sept 2026 · Probed https://livevariant.com/mcp

TLS valid

Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .

Subject Issuer Valid from Valid until Key Signature Serial
CN=livevariant.com CN=WE1,O=Google Trust Services,C=US 2 Aug 2026 31 Oct 2026 ECDSA 256 ECDSA-SHA256 9c5f279ab03e4a020e94c04ef81072ed
SANs: livevariant.com, *.livevariant.com
CN=WE1,O=Google Trust Services,C=US (CA) CN=GTS Root R4,O=Google Trust Services LLC,C=US 13 Dec 2023 20 Feb 2029 ECDSA 256 ECDSA-SHA384 7ff31977972c224a76155d13b6d685e3
CN=GTS Root R4,O=Google Trust Services LLC,C=US (CA) CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE 15 Nov 2023 28 Jan 2028 ECDSA 384 SHA256-RSA 7fe530bf331343bedd821610493d8a1b

Background: What to check on a remote MCP endpoint →

DNSSEC secure

Validation of livevariant.com. Secure

Zone DS Keys Algorithms Outcome
. trust_anchor 20326, 38696 8, 8 Verified
com. present 19718 13 Verified
livevariant.com. present 2371 13 Verified
livevariant.com. Verified address RRset verified with the apex keys
Authentication No authorisation required

The endpoint answered without asking for a token. Anyone who knows the URL can reach it.

Result No authorisation required
HTTP status 200

Background: How OAuth 2.1 works in the 2026 MCP spec →

Transports 2 probes
Transport URL Outcome Status Location
streamable-http https://livevariant.com/mcp Verified 200
http (plaintext) http://livevariant.com/mcp HTTPS enforced 301 https://livevariant.com/mcp
MCP tools · 9 exposed · ~2,412 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
build_test ~689

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.

NameTypeReqDescription
contextarrayDimensions to learn a separate winner for.
namestringA 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…
publishableKeystringRegisters 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…
redirectUrlstringWhere clicks land when a variant does not say.
regionstringWhere 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…
slotRedirectsobjectWhere 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…
slotsobjectMulti-element test: variants per element, keyed by a short name like "hero" or "cta". The test serves and learns combinations.
variantParamstringStamp the served combination into this parameter on redirect, e.g. "utm_content", so the test shows up in the customer's own analytics.
variantsarraySingle-element test: two or more variants. The first is the control.
NameTypeReqDescription
combinationsnumberyesHow many distinct combinations the test chooses between.
configstringyesThe encoded config: this is the test.
destinationsarrayRedirect 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…
emailTemplateobjectQuery-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…
regionyesWhere the test's state will live; null means first-request placement.
registeredTostringThe organization the test was registered to, when a publishableKey was given and accepted.
slotLinksobjectMulti-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…
slotsarrayyesCanonical slot order with variant names, as stats reports them.
statsSecretstringyesShown once. Store it now.
testIdstringyes
urlsobjectyes
warningsarrayyes

No examples provided.

generate_priors ~373

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.

NameTypeReqDescription
beliefsarrayyes
confidenceHow 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.
configstringAlias for `test`: the same value under the name build_test returns it as (`config`). Pass one or the other.
teststringThe test: an encoded config, or any LiveVariant URL containing one (serve, click, pixel, manage), or a query-parameter serve URL. Paste whatever you have.
whenobjectContext 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.
NameTypeReqDescription
configstringyes
manageUrlstringyes
notesarrayyes
priorsarrayyes
testIdstringyes
washesOutAfternumberyesRoughly this many real visitors per variant and your guess stops mattering.

No examples provided.

get_stats ~240

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.

NameTypeReqDescription
configstringAlias for `test`: the same value under the name build_test returns it as (`config`). Pass one or the other.
statsSecretstringOmit when passing a manage URL that carries it in the fragment.
teststringThe test: an encoded config, or any LiveVariant URL containing one (serve, click, pixel, manage), or a query-parameter serve URL. Paste whatever you have.
NameTypeReqDescription
bySignalobjectyes
combinationsarrayyes
contextBucketsnumberyes
decisionobjectyes
excludedobjectyes
slotsobjectyes
testIdstringyes
totalAssignmentsnumberyes

No examples provided.

get_test_status ~253

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.

NameTypeReqDescription
configstringAlias for `test`: the same value under the name build_test returns it as (`config`). Pass one or the other.
statsSecretstringOmit when passing a manage URL that carries it in the fragment.
teststringThe test: an encoded config, or any LiveVariant URL containing one (serve, click, pixel, manage), or a query-parameter serve URL. Paste whatever you have.
NameTypeReqDescription
claimedbooleanyesWhether the test is registered to an organization.
destinationsarrayyesEvery host this test can redirect a visitor to. verified: false means the continue screen shows before landing there.
orgyesThe claiming organization's name; null when unclaimed.
testIdstringyes

No examples provided.

inspect_test ~156

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

NameTypeReqDescription
configstringAlias for `test`: the same value under the name build_test returns it as (`config`). Pass one or the other.
teststringThe test: an encoded config, or any LiveVariant URL containing one (serve, click, pixel, manage), or a query-parameter serve URL. Paste whatever you have.
NameTypeReqDescription
combinationsnumberyes
contextarrayyes
findingsarrayyes
namestring
regionyes
resultsReadablebooleanyesFalse when the config has no stats key, which is permanent.
slotsarrayyes
testIdstringyes

No examples provided.

list_tests ~120

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.

NameTypeReqDescription
cursorstringOpaque cursor from a previous page's nextCursor
limitinteger
qstringCase-insensitive substring filter on the test name
NameTypeReqDescription
nextCursoryes
testsarrayyes

No examples provided.

register_test ~213

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).

NameTypeReqDescription
configstringyesThe encoded test config (from build_test or any test URL).
publishableKeystringyesA publishable key for the target organization, provided by a user authorized to register tests there.
statsSecretstringyesThe test's stats secret, exactly as build_test returned it.
NameTypeReqDescription
orgstringyesThe organization that now owns the test.
registeredbooleanyes
testIdstringyes

No examples provided.

upload_image ~204

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.

NameTypeReqDescription
contentTypestringyesThe image's actual type; the server stores and serves it as this.
datastringyesThe image bytes, base64-encoded (plain base64, not a data: URL).
NameTypeReqDescription
assetIdstringyessha256 of the bytes; the id inside the URL.
contentTypestringyes
previewUrlstringyesSigned for one hour, to verify the upload.
sizenumberyes
urlstringyesUse this as the variant's image/url. 403s without a signature, by design.

No examples provided.

variant_brief ~164

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.

NameTypeReqDescription
audiencestringWho sees it, if that shapes the copy.
channelstringyes
countinteger
formatstringyesWhat each variant will be.
goalstringyesWhat the test should improve, e.g. 'more demo bookings'.
NameTypeReqDescription
goalstringyes
hostingstringyes
nextStepstringyes
rulesarrayyes
specsarrayyes
variantCountnumberyes

No examples provided.

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 hosted endpoint (https://livevariant.com/mcp).

Is the LiveVariant MCP server safe to use?

LiveVariant scores 85 out of 100 on VerifyMCP. 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 9 tools: build_test, inspect_test, generate_priors, get_stats, get_test_status, and 4 more. Their descriptions and schemas cost roughly 2,412 tokens of context every time the server is loaded.

Does the LiveVariant MCP server require authentication?

No. We connected to LiveVariant without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

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.