Skip to main content
Glama

LiveVariant

by io.github.livevariant

Read a test's results

get_stats
Read-onlyIdempotent

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 Schema

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

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
slotsYes
testIdYes
bySignalYes
decisionYes
excludedYes
combinationsYes
contextBucketsYes
totalAssignmentsYes

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds substantial behavioral context beyond that: it requires the stats secret, explains that the manage URL fragment automatically supplies it, and details the statistical outputs including probabilities and expected stopping cost. It also discloses multi-slot per-slot marginals. This is a thorough and honest behavioral picture with no contradiction.

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

Conciseness4/5

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

The description is front-loaded with the core purpose and organized into clear blocks: output interpretation, multi-slot behavior, and authentication. The middle section is slightly wordy—the 2/10-vs-1/10 example and 'most common mistake' phrasing reinforce the warning but are somewhat redundant. Overall, each major idea earns its place, but there is minor rhetorical fat.

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 read-only stats tool with a rich output schema and strong annotations, the description covers input flexibility, output semantics, multi-slot extras, and the secret/auth nuance. An agent has everything it needs to select and invoke the tool correctly without guessing. The output schema excuses the description from listing return fields, and nothing important is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds a little useful context about the stats secret and fragment handling, and it explains the high-level purpose of the test parameter through the tool's behavior. But it does not substantially extend the parameter meanings beyond what the schema already documents. It meets the baseline without exceeding it.

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

Purpose5/5

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

The description leads with a specific verb and resource ('Fetches a test's results') and adds the interpretive scope ('works out what they mean'), which clearly defines the tool's purpose. This separates it from siblings like list_tests, get_test_status, and inspect_test without needing to name them. The opening sentence is unambiguous and specific.

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

Usage Guidelines3/5

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

The description implies when to use the tool—when you need statistical interpretation of test results—and warns against eyeballing conversion rates. However, it never explicitly states when to prefer this tool over siblings like get_test_status or inspect_test, nor does it offer any exclusions or alternative routing. The context is enough to infer usage but not enough to fully guide tool selection.

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

All LiveVariant toolsInspect
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.

Resources