Mondovo

Start a draft of a page

create_page_draft

Make a private copy of ONE page — any page, including the home page ("/") — to experiment on without changing the live page. THIS is the tool for "try a different version of the homepage/about page", "show me an alternative hero", "let's experiment before we change it": create a draft, edit the draft, and call promote_page_draft only when the user approves. Do NOT use import_design_variation for that — it adds a whole-site design, which drops every inner-page edit made meanwhile when it is switched in. The draft gets its own copy of the page's text (content_key), so editing it never changes what visitors see. Shared blocks — header, footer, theme — stay shared: editing those changes every page. Returns the draft's slug and the exact calls that edit it (how_to_edit): patch_variation_content under content_key for copy, update_variation_file with file = the draft slug for code, or refine_site with page = the draft slug. Up to 4 drafts per page. If Mondovo cannot keep a copy separate from the live page it refuses and says why in message — pass that sentence to the user as it is. Recorded in version history.

Input Schema

Name	Required	Description
`name`	No	What to call the draft, e.g. "Shorter version". Defaults to "Version N".
`site_id`	Yes	The site the page belongs to
`page_slug`	Yes	The live page to copy, e.g. "/about", or "/" for the home page.
`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	Design the draft belongs to, from list_variations. Defaults to the active design.
`from_draft_slug`	No	Copy an existing draft of this page instead of the live page.

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?

Beyond the annotations, it discloses that the draft is private, that text lives under its own content_key, that shared blocks such as header/footer/theme remain shared, that there is a limit of 4 drafts per page, and that refusals are reported in message to pass through. It also states the tool is recorded in version history, adding important behavioral context without contradicting the annotations.

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 action and scope, then moves through usage rules, behavior, and return values. Although dense, every sentence contributes distinct guidance, with no 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 a 6-parameter mutation tool with no output schema, it explains the key return values (slug, how_to_edit), the follow-up editing calls, sharing constraints, draft limits, and refusal behavior. An agent has enough information to invoke it correctly and route the subsequent edits.

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 the baseline is 3. The description adds useful semantics: page_slug can be any page including '/', the returned draft slug is what edit tools use, and content_key identifies the draft's own text copy; it does not explain every parameter such as from_draft_slug or variation_id, but the schema already covers those.

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?

It states a specific verb and resource: 'Make a private copy of ONE page', including the home page, to experiment without changing the live page. It also distinguishes itself from the sibling import_design_variation by explaining the different scope of that tool.

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?

It names explicit user intents ('try a different version of the homepage/about page', 'show me an alternative hero') and gives the full workflow: create draft, edit draft, promote only on approval. It also includes an explicit do-not-use rule for import_design_variation with the reason.

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?