Skip to main content
Glama

LiveVariant

by io.github.livevariant

Upload an image

upload_image

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYesThe image bytes, base64-encoded (plain base64, not a data: URL).
contentTypeYesThe image's actual type; the server stores and serves it as this.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesUse this as the variant's image/url. 403s without a signature, by design.
sizeYes
assetIdYessha256 of the bytes; the id inside the URL.
previewUrlYesSigned for one hour, to verify the upload.
contentTypeYes

TDQS

A3.7/5.0
Behavior1/5

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

The description is rich in behavioral disclosure: the returned URL is not directly fetchable, assets use short-lived signatures, storage is content-addressed, SVG is refused, and asset hosting may be unavailable. However, it explicitly states that uploading the same image twice is harmless and returns the same URL, which implies idempotent behavior, while the annotations declare idempotentHint=false. This is an annotation contradiction, so the score must be 1 per the rubric.

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 front-loaded with the core purpose, then layers constraints and caveats in compact, purposeful sentences. Every sentence adds meaningful behavior or usage context, and nothing feels redundant or padding.

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 tool with two fully documented parameters, a rich output schema, and detailed annotations, the description covers return value usage, URL fetchability caveats, content-addressing behavior, format restrictions, and the deployment-dependent asset-hosting failure mode. Nothing essential for invoking the tool correctly 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 coverage is 100%, and the schema already documents data as base64-encoded bytes (not a data URL, maxLength 8000000) and contentType as an enum of raster formats. The description adds useful context about content addressing and raster-only enforcement, but it does not materially expand parameter-level semantics beyond the schema, so the baseline 3 is appropriate.

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 opens with a specific verb and resource: 'Uploads an image to the deployment's asset store and returns its URL.' It also explains the intended consumption context ('for use as a variant's image (email tests) or url'), which makes the purpose unmistakable and distinct from the sibling tool set.

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 clearly states when the tool is relevant: when an image URL is needed for a variant's image or url field. It does not explicitly name alternatives or exclusions, but none of the sibling tools are alternative uploaders, so the context is sufficient for an agent to select it.

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