Mondovo

Create site

create_site

Create a professional website — Mondovo generates the design (do NOT write HTML/React yourself). ONE call produces THREE competing homepage designs (D1/D2/D3) for the user to choose between: see them with list_variations, select one with switch_variation, then add inner pages with add_page/add_pages and publish only when requested with publish_site. Output quality scales with how RICH and OPINIONATED your brief is about the BUSINESS, so do not send a thin brief: business name (required), industry, location, services/offerings, target_audience, unique_selling_points, business.tone_of_voice (put the voice spec here, not in the description — it drives the copy voice directly); and a goal — the site's primary conversion objective ("free trial signups from agencies", "book a consultation") which drives the conversion narrative, section flow, and CTAs. All of that helps all three designs equally. The DESIGN inputs are a deliberate TRADEOFF, because they bind all three lanes to the same look: a stated design.color_palette fixes the colors for every design, a heavily-specified mood/creative direction fixes the whole aesthetic, and content you supply (headline, tagline, per-section copy) is used as written in all three — so the three come back differing only in layout and typography. Send them when the user wants ONE look executed well; leave color_palette and mood open, and omit sections/pages/per-section content, when the user wants genuinely different alternatives to compare (Mondovo's strategist then plans the section arc and page architecture around your goal, and each design picks its own palette and voice). Whatever you do send should be concrete, never generic placeholder text — reference real design styles if the user has a taste (e.g. "editorial serif, warm cream + terracotta, generous whitespace, Aesop-like"). To CLONE or closely reference a live site, set design.source_url to its HTTPS URL — Mondovo scrapes the page (screenshot + structure) and adopts its visual design (use design.source_copy: "preserve" to also keep its wording, default "rewrite"); this is stronger than describing it in design.references text. When source_url is set, do NOT send design.color_palette — the scraped design drives the colors and an explicit palette is ignored. To recreate from a design SCREENSHOT you already have (not a live URL), pass its HTTPS image URL(s) in design.reference_images and set design.reference_fidelity: "replicate" reproduces the reference faithfully (its section structure/order and imagery), "inspire" (default) honors its palette/typography/mood while adapting the structure to your business. Returns a site_id; poll get_site every 10s — it reports "generating" for the whole round (typically 3-15 min) and "ready" only when every design has landed. Then call list_variations to see the three homepage designs. (For a design YOU author end-to-end, use create_site_from_design instead.) To set up a READY-MADE BUSINESS rather than generate a site — a directory, for instance, that arrives with its listings, its submission and claim flows and its pages already working — call list_packs, then pass that pack's pack_slug here with its questions answered in pack_intake. That path COPIES a curated design instead of generating one, so it costs no generation credits, finishes in about two minutes, and ignores business/design/content/pages/goal entirely.

Input Schema

Name	Required	Description
`goal`	No
`name`	Yes
`pages`	No
`design`	No
`content`	No
`brand_id`	No	Optional existing Brand Studio brand to link explicitly. The brand must belong to the API organization. Omit it to create the normal unlinked website; this never creates a brand or applies one implicitly.
`business`	No
`pack_slug`	No	Slug of a ready-made business to set up instead of generating a site from scratch (see list_packs). The design is COPIED, not generated, so this returns a finished, working site in about two minutes and costs no generation credits — and `business`, `design`, `content`, `pages` and `goal` are all ignored. Pair it with `pack_intake`.
`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.
`pack_intake`	No	Answers to the questions the chosen pack asks, keyed by question id (list_packs returns them, with which are required). Ignored unless pack_slug is set.
`idempotency_key`	No	Optional stable key for this creation attempt. If you retry a create_site call that timed out, send the SAME value and you get back the site the first attempt created instead of a duplicate site and a second generation. Use a fresh value (e.g. a UUID) for each genuinely new site; omit it and every call creates a new site.
`assistant_intake`	No
`platform_gallery_use`	No	Explicit permission to use real Mondovo template-gallery captures. Omit or set declined to keep gallery sourcing off.

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.7/5.0

Behavior5/5

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

Annotations only declare the mutation/open-world profile; the description adds the operationally critical facts on top: generation returns a site_id, requires polling get_site every 10s, stays 'generating' for typically 3-15 min, and only reports 'ready' when all designs land. It also pre-empts a serious failure mode — when design.source_url is set an explicit color_palette is silently ignored — and discloses that the pack path costs no generation credits and finishes in ~2 minutes. The opt-in idempotency_key semantics do not contradict idempotentHint=false, since default behavior still creates a new site.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and the D1/D2/D3 workflow are front-loaded correctly, but the body is a single dense block of stacked parentheticals, ALL-CAPS emphasis, and nested conditionals that is hard to scan. Nearly every sentence carries information, but the tradeoff explanation and the scraping/screenshot rules could be split and tightened without losing content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-parameter, deeply nested creation tool with no output schema, this covers the full lifecycle: inputs, expected generation time, the site_id return, the polling contract, and the variation/publish follow-ups. What it omits is secondary — assistant_intake has no explanation anywhere, and brand_id / user_goal / platform_gallery_use rely entirely on their own schema descriptions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 46% schema description coverage, the description carries the load and does so with real semantics rather than restating field names: it explains that business.tone_of_voice (not the description text) drives copy voice, that goal drives conversion narrative/section flow/CTAs, and that design inputs are a deliberate TRADEOFF binding all three lanes to one look, versus leaving them open to force divergence. It also specifies source_copy 'preserve' vs default 'rewrite', reference_fidelity 'replicate' vs 'inspire', and notes references text is weaker than source_url. Minor gaps remain for assistant_intake, brand_id, and platform_gallery_use, which the prose never touches.

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+resource ('Create a professional website') and immediately quantifies the output: ONE call produces THREE competing homepage designs (D1/D2/D3). It explicitly separates itself from create_site_from_design ('For a design YOU author end-to-end') and from the pack path (spin_up_pack/list_packs), so an agent can pick the right tool 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-send vs when-to-omit rules: send design.color_palette/mood/content when the user wants one look executed; leave them open and omit sections/pages when they want genuinely different alternatives. It also names the alternatives and their selecting conditions (create_site_from_design for authored designs, pack_slug for ready-made businesses), plus the full downstream sequence list_variations → switch_variation → add_page/add_pages → publish_site.

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?