LiveVariant

Add warm-start priors

generate_priors

Read-onlyIdempotent

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 Schema

TableJSON Schema

Name	Required	Description	Default
`test`	No	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`	No	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.
`config`	No	Alias for `test`: the same value under the name build_test returns it as (`config`). Pass one or the other.
`beliefs`	Yes
`confidence`	No	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.	medium

Output Schema

TableJSON Schema

Name	Required	Description
`notes`	Yes
`config`	Yes
`priors`	Yes
`testId`	Yes
`manageUrl`	Yes
`washesOutAfter`	Yes	Roughly this many real visitors per variant and your guess stops mattering.

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, the description discloses the capping, pseudo-observations, the response's washout count, the fact that priors sit outside the identity hash, and the stronger claim of an every-visitor belief. This is substantial behavioral context and is consistent with the read-only/idempotent annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The most important idea is in the first sentence, and each following paragraph adds necessary behavior that is not in the schema or annotations. It is a bit long, but every sentence earns its place for a nuanced operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter tool with an output schema and rich annotations, the description covers why, when, segment scope, risk, and persistence behavior. Nothing essential for an agent to select and call it correctly appears missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is high (80%), so the baseline is 3, but the description adds real meaning: it explains `when` as a one-segment limitation and contrasts it with the 'much stronger' every-visitor claim, and explains that `beliefs` are guesses converted via arithmetic and capping. This justifies above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: it 'takes YOUR estimate ... and converts it into the prior the model starts from,' and later clarifies the capping and washout behavior. It does not explicitly distinguish this from siblings like build_test or variant_brief, but the function is clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The context is clear: use it when you already have an estimate and want to avoid spending early visitors rediscovering it, and the `when` paragraph tells when the one-segment variant applies. No alternatives are named and there is no explicit when-not-to-use, so it stops short of 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All LiveVariant tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0

Disambiguation4/5

Each tool targets a distinct phase of the test lifecycle—building, priors, stats, registry status, inspection, listing, registration, asset upload, and briefing—so an agent can usually select correctly. The only mild overlap is between get_test_status and inspect_test, and between build_test with registration versus register_test, but the descriptions draw clear boundaries.

Naming Consistency4/5

Almost all tools follow a consistent snake_case verb_noun pattern: build_test, get_stats, register_test, upload_image. The single outlier is variant_brief, which is a noun phrase rather than an action verb, making the set slightly less predictable.

Tool Count5/5

Nine tools is well within the ideal range for a focused A/B testing server. Each tool earns its place and there is no obvious redundancy or bloat.

Completeness4/5

The core workflow is well covered: get constraints, build a test, optionally register it, set priors, inspect it, check status, and fetch stats. Minor gaps exist—there is no explicit stop/archive/delete test operation and domain verification is dashboard-only—but these are workaroundable given the immutable-test design.

Add warm-start priors

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources