LiveVariant

Inspect a test

inspect_test

Read-onlyIdempotent

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 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.
`config`	No	Alias for `test`: the same value under the name build_test returns it as (`config`). Pass one or the other.

Output Schema

TableJSON Schema

Name	Required	Description
`name`	No
`slots`	Yes
`region`	Yes
`testId`	Yes
`context`	Yes
`findings`	Yes
`combinations`	Yes
`resultsReadable`	Yes	False when the config has no stats key, which is permanent.

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already mark the tool as readOnly, idempotent, and non-destructive. The description adds valuable behavioral context: it lints for campaign-time-only mistakes and accepts multiple input forms (encoded configs, LiveVariant URLs, query-parameter serve URLs). This goes well beyond the structured annotations and clarifies what the operation actually does.

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 description is compact and front-loaded: the first sentence states the core function, the second explains the linting value-add, and the closing sentence gives usage context. Every sentence earns its place with no filler.

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 two-parameter read-only tool with full schema coverage, rich annotations, and an output schema, the description covers the essential operational context: what it inspects, what it checks for, and when to invoke it. Nothing critical is missing for an agent to select and call it correctly.

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%, and the schema already documents both parameters in detail, including accepted formats and the alias relationship between test and config. The description itself adds no additional parameter-level semantics, so the baseline 3 applies.

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 uses a specific verb ('Decodes') and resource ('a test'), and clearly states what it produces: slots, variants, context, redirect-servability, and lint findings. It also distinguishes its role from siblings like build_test or get_test_status by framing it as the pre-send inspection step and the answer to 'what is this link?'.

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 explicitly says 'Use this before sending anything, and to answer "what is this link?"', giving clear situational guidance. It does not name sibling alternatives or state when not to use it, but the use-before-sending context is strong enough to guide an agent.

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.

Inspect a test

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources