Mondovo

List a site's design variations

list_variations

Read-onlyIdempotent

List the design variations that exist for a site — each with its index, a short label/style name, whether it is the active (live) design, and lightweight metadata (file count, size, summary). Returns metadata ONLY (no code), and ATTACHES a thumbnail of each design that HAS a stored render, in index order, so you can actually see the options rather than guessing from labels. Renders are captured in the background, so a design listed moments after generation may not have one yet: the thumbnails field in the response says exactly what to expect (ready | partial | pending | unavailable) and whether a capture run was queued — when it says pending/partial, show the available preview links and explain that screenshots are still rendering. In hosts with an interactive design card, that card refreshes screenshots itself: do not call list_variations again just to poll thumbnails or reopen the same card. Without an interactive card, a later metadata refresh is appropriate. Each design carries a variation_id — the stable UUID, and the ONLY identifier safe to store or pass to another call, because index/slot/variation_number renumber or gap when a design is deleted. Pass it to publish_site to say which design to publish. Use this to compare the alternatives before re-activating one with switch_variation or building on one with generate_design_variation.

Input Schema

Name	Required	Description
`site_id`	Yes	The site whose design variations to list
`user_goal`	No	Optional: the user's goal behind this call, in one short sentence of plain words (e.g. "add a page so customers can book tables"). No names, emails or other personal details.
`include_thumbnails`	No	Attach a screenshot of each design (default true). Set false for a metadata-only listing.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026

addedInput schema / properties / user_goal

Added value: +{
+  "description": "Optional: the user's goal behind this call, in one short sentence of plain words (e.g. \"add a page so customers can book tables\"). No names, emails or other personal details.",
+  "type": "string"
+}

First observedOct 19, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent safety, but the description adds substantial behavioral context beyond them: thumbnails are captured asynchronously, the `thumbnails` field can be ready|partial|pending|unavailable, a capture run may be queued, and polling behavior differs by host. It also warns that index/slot/variation_number renumber or gap when designs are deleted, while variation_id is the only stable identifier.

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 most important information is front-loaded: what is returned, that it is metadata-only with thumbnails, and how thumbnail readiness works. It is dense but somewhat long, with repeated thumbnail/polling guidance, though nearly every sentence carries operational value.

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 no output schema, the description fully specifies the response shape: per-design index/label/active/metadata, thumbnail attachment behavior, the `thumbnails` status values, and the stable `variation_id`. It also covers the key operational caveats (async renders, polling rules, ID stability) an agent needs to call and interpret this 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%, so all three parameters are already documented in the schema. The description does not add per-parameter meaning beyond the schema (site_id and user_goal are not elaborated), though it does explain response-side fields like variation_id and thumbnails. Baseline 3 is appropriate when the schema carries parameter semantics.

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?

Opens with a specific verb+resource ('List the design variations that exist for a site') and enumerates what each entry includes (index, label, active flag, metadata). It is clearly distinct from siblings like switch_variation, generate_design_variation, and publish_site, which it explicitly names.

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

Usage Guidelines5/5

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

Gives explicit routing: use this to compare alternatives before re-activating with switch_variation or building with generate_design_variation, and pass variation_id to publish_site. It also gives a clear when-NOT-to-call rule: do not re-call just to poll thumbnails when an interactive design card exists, but do refresh later without one.

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

All Mondovo tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?