Mondovo

Publish site

publish_site

Idempotent

Publish a site to make it live on the web at its platform address (the deployment_url in the response is the exact live URL — report that, never guess a host). Choose a subdomain matching the business name (lowercase, hyphens). IF THE SITE STILL HOLDS SEVERAL DESIGNS you MUST pass variation_id — the design to publish, taken from list_variations (a UUID, not an index). Do not choose for the user: list_variations attaches a thumbnail of each design, so show them and let the user pick. Publishing a design turns it into its own site: Mondovo builds the chosen design into a new site and publishes THAT, so the response carries a different site_id — use that id from then on (the original id stays the design draft, and get_site on it will keep saying unpublished). Calling publish twice reuses the same built site rather than creating another. Sites that already have one design ignore variation_id. A design only has its home page, but its menu links to the rest of the site: when it does, publish_site first BUILDS those pages and then publishes automatically — it returns status "building" with pages_being_built, a job_id and the new site_id. Before publishing a design, tell the user which pages its menu links to and that they will be built. On "building", tell the user which pages are being built, poll get_job with the job_id until "completed" (failed lists pages that could not be built — their menu links are removed; publish says whether the site went live), then poll get_site until "published". Do not call publish_site again meanwhile. If a response carries missing_pages, those menu links have no page and 404 on the live site: tell the user and offer add_pages for them. This tool RETURNS IMMEDIATELY with status "publishing" once the site is accepted for deployment — it does NOT wait for the deploy. Compiling and deploying takes 1-3 minutes and continues server-side even if this conversation ends. Poll get_site (with the returned site_id) every ~15s until status is "published" to get the live URL — or "publish_held", which means the new build crashed in a browser check before going live and was not published (tell the user its publish_message). NEVER call publish_site a second time to check on or hurry along a publish you already started: while one is in flight the publish lock rejects the call, and a transport timeout on this tool does NOT mean the publish failed — it is almost always still running, so poll get_site before concluding anything. If the response is contact_info_needs_confirmation, its reason says why: "placeholders" means contact details that look AI-invented (listed in placeholders) — refine them to the real values first, or (if they are already correct) call again with confirm_contact_info: true; "missing_details" means nothing was invented but the email or phone in missing_fields is absent — ask the user for it, or call again with confirm_contact_info: true if the site should go live without it. Never make up a contact detail. Retrying with the same arguments will NOT clear that warning. Success responses carry after_publish (plan, custom domain, editor link): once get_site reports "published", relay its tell_user to the user.

Input Schema

Name	Required	Description
`site_id`	Yes	The site ID to publish
`subdomain`	No
`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.
`variation_id`	No	variation_id of the design to publish (from list_variations). Required for sites that still hold multiple designs.
`confirm_contact_info`	No

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

Behavior5/5

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

Far beyond the annotations: it discloses that the call returns immediately with status "publishing", that compiling takes 1-3 minutes server-side, the publish lock behavior, "building"/"publish_held" states, and the `contact_info_needs_confirmation` reasons. The idempotentHint=true annotation is corroborated by the note that calling twice reuses the same built site rather than creating another.

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?

Purpose and URL guidance are front-loaded and nearly every sentence carries operational information, but the block is dense and repeats the "do not call twice" warning in three separate forms. A wall-of-text single paragraph with ALL-CAPS emphasis makes the critical variation_id rule compete with secondary edge cases.

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, side-effectful tool with no output schema, it covers the full lifecycle: response statuses, the job_id/site_id handoff, polling cadence (~15s), failure modes (`failed`, `publish_held`, `missing_pages`), and the `after_publish` follow-up. Nothing an agent needs to invoke and then correctly handle the result is missing.

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?

Schema coverage is only 60%, and the description compensates heavily: variation_id is explained as a UUID from list_variations that is mandatory for multi-design sites and ignored otherwise, subdomain is constrained to lowercase/hyphens matching the business name, and confirm_contact_info is tied to concrete `reason` values. Only user_goal goes unmentioned, and the schema already documents it well.

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 opening sentence names a specific verb and resource plus the outcome ("make it live on the web at its platform address") and pins the exact live URL source (`deployment_url`). It is unambiguously distinguishable from siblings like get_site, list_variations and create_site_from_design, which are all referenced by name in their proper roles.

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?

Explicit routing: use list_variations to pick a design, pass variation_id when multiple designs exist, never choose for the user, poll get_job then get_site, and offer add_pages when `missing_pages` appears. It also states when NOT to call it — never twice while a publish is in flight, and a timeout is not a failure.

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?