Skip to main content
Glama

LiveVariant

by io.github.livevariant

Check a test's account and domain status

get_test_status
Read-onlyIdempotent

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.

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
orgYesThe claiming organization's name; null when unclaimed.
testIdYes
claimedYesWhether the test is registered to an organization.
destinationsYesEvery host this test can redirect a visitor to. verified: false means the continue screen shows before landing there.

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/destructive annotations, the description discloses important runtime behavior: unverified destinations work but show a continue screen, verified:false triggers a domain verification workflow, unclaimed tests can be claimed via the manage URL, and the stats secret is required unless included in the manage URL fragment. This materially helps an agent predict side effects and prerequisites.

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 longer than average but well-structured: first a precise statement of results, then behavioral implications and user guidance, then authentication notes. Each section earns its place, and the first sentence front-loads the core purpose.

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?

With an output schema present and annotations covering read-only/identity, the description completes the picture by covering the shared secret, the manage-URL fragment behavior, what to do about verified:false, and what unclaimed means. No required information for a correct call is 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 100%, so a baseline of 3 applies. The description adds value by explaining that statsSecret is required, can be omitted when a manage URL carries it, and that the test parameter can be an encoded config or several URL forms. This goes beyond the raw schema descriptions.

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 purpose is explicit: 'Reports what the deployment's registry knows about a test' with specific dimensions (account claim, organization, verified redirect domains). It clearly distinguishes this from sibling tools like get_stats by naming the exact kind of status being checked.

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 description gives clear context for when to call this tool: to check account claim and domain verification status. It also notes the shared stats-secret requirement with get_stats and how a manage URL fragment supplies it automatically. It does not explicitly state when not to use it, but the alternatives are not needed because the purpose is well-scoped.

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