Skip to main content
Glama

Have Mondovo generate an alternative design

generate_design_variation

Ask MONDOVO to generate an ADDITIONAL design variation for an existing site — an alternative layout the user can compare and switch to. This APPENDS a new variation (never overwrites the current design). Use this when the user wants "another option" but does NOT want you to author it; to author the alternative yourself instead, use import_design_variation. It is a WHOLE-SITE design — to try another version of ONE page (the home page included), use create_page_draft instead. TWO MODES. Omit clone_index and Mondovo generates a design deliberately DIFFERENT from every existing one (the user is collecting options to compare). Pass clone_index and Mondovo builds a SIBLING of that specific design instead — same style personality, palette and type, varying layout and composition. THIS IS THE RIGHT TOOL FOR "make another one like design N" or "same look, different layout". You do not need to read a design's source to build on it: name its index here and Mondovo generates from it server-side. Call get_render_diagnostics first if you want to SEE the design you are building on. Returns 202; poll get_site until status is "ready".

Input Schema

NameRequiredDescriptionDefault
site_idYesThe existing site to add a Mondovo-generated variation to
guidanceNoWhat should differ in this variation, e.g. "same look but swap the objections section for a tighter 3-item ledger". Most useful together with clone_index.
user_goalNoOptional: 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.
clone_indexNoVariation index (from list_variations) to build a sibling of. Omit for a deliberately different design.
reference_image_urlNoA design reference image for Mondovo to work from — an https URL or a data:image/... URI. Mondovo reads it and takes its palette, typography, spacing and composition as controlled inspiration; it does not copy the image into the page. Omit to generate without one. When you pass clone_index and the design you are cloning was itself built from a reference, that reference carries over automatically, so you only need this to introduce a NEW one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • 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"
      +}
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Adds real context beyond the annotations: the call is additive-only, returns HTTP 202, and requires polling get_site until status is 'ready'. It also explains that clone_index resolves server-side so no source read is needed. It doesn't cover costs/credits or what happens on failure, which keeps it below a 5 given destructiveHint/openWorldHint are already declared.

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?

Long but dense and front-loaded: purpose, exclusions, modes, workflow, in that order. The heavy ALL-CAPS emphasis ('ADDITIONAL', 'APPENDS', 'TWO MODES') is slightly noisy but each sentence carries actionable content rather than 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 an async generation tool with no output schema, it supplies everything needed: the 202 return, the polling target (get_site), the non-destructive guarantee, and the two mode branches. Nothing an agent needs to call it correctly 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 baseline is 3, but the description adds genuine meaning: the two-mode behavior of clone_index (omitted = deliberately different, passed = sibling with same style personality) and how that interacts with guidance and reference_image_url inheritance. That semantic layer is not in the schema.

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?

States a specific verb and resource ('generate an ADDITIONAL design variation for an existing site') and pins down the semantics (appends, never overwrites). It explicitly distinguishes itself from import_design_variation and create_page_draft, so an agent can route correctly without opening any schema.

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 when-to-use ('user wants another option but does not want you to author it'), names the alternatives and the condition selecting each (import_design_variation for self-authoring, create_page_draft for one page). It even resolves the mode choice: omit clone_index for a different design, pass it for a sibling.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources