Skip to main content
Glama

Add a page to a site

add_page

Add ONE new inner page to an existing site that already has a design (create_site / create_site_from_design first). Two modes, chosen by whether you pass code: • MONDOVO WRITES IT (no code): Mondovo's AI generates the page to match the site's theme, header and footer. Give a description of what the page is for. Optional nav_placement ("main" header menu — the default, "footer", or "none") and nav_label: only this page's link is added; existing menu items are never changed. Returns a job_id immediately; poll get_job every ~10s until "completed" (~45-90s). Runs server-side even if this conversation ends. Counts as an AI refinement. • YOU WROTE IT (pass code): the page you authored is added as-is — no AI, no credits, no job. Send the COMPLETE TSX (same authoring contract as update_variation_file). Nothing wraps your page in the site's chrome, so build it the way this design's existing pages are built — read_design and copy an existing page's imports (usually , and from './ThemeStyles', './Header', './Footer'). Put the page's own text in content under NEW top-level keys, conventionally one key page_ (e.g. { "page_marketing": {...} } for /marketing); the code reads them as content.page_marketing. Your code may also read keys the site already has, but content may not redefine them. Optional seo (title, description, structured_data), nav_placement ("main" header menu — the default, "footer", or "none") and nav_label. The page is validated with the same checks update_variation_file runs (content first, then code); a refusal writes NOTHING and returns the issues. A slug, file name or content key the design already has is refused — to change an EXISTING page use update_variation_file / patch_variation_content instead. On success it returns the page's slug, file and content key plus how_to_edit, and lands as one entry in version history (version; history_warning means it saved but was not recorded). Nothing is live until publish_site. To try an alternative version of an EXISTING page without touching the live one, use create_page_draft, not this tool. ON A SITE THAT STILL HOLDS SEVERAL DESIGNS this builds the site: Mondovo copies the chosen design into the working site (or reuses the copy made earlier), adds to that, and the response carries its new site_id and a build_transition — relay its tell_user and use the new site_id from then on. Pass variation_id (from list_variations) for the design the user picked; omitted, Mondovo uses the design already built or the only one edited, and otherwise answers choose_design so you can ask the user.

Input Schema

NameRequiredDescriptionDefault
seoNoWith `code`: the page's <title>, meta description and optional JSON-LD `structured_data` ({ "schemas": [ { "@type": "…", … } ] }, replacing the schema Mondovo would generate). Title defaults to "<name> | <site name>". Change later with update_page_seo.
codeNoYOU-WROTE-IT mode: the complete TSX of the page. Omit to have Mondovo's AI write the page instead.
nameYesPage name, e.g. "About", "Services", "Contact"
slugYesURL slug, e.g. "/about" (a leading slash is added if missing)
contentNoWith `code`: NEW top-level content keys the page reads, e.g. { "page_marketing": { "hero": { "headline": "…" } } }. Existing keys are refused — edit those with patch_variation_content.
site_idYesThe site to add the page to
guidanceNoOptional extra freeform direction for the page
file_nameNoWith `code`: PascalCase component/file name, e.g. "MarketingPage". Derived from `name` when omitted.
nav_labelNoMenu label. Defaults to `name`.
page_typeNoOptional explicit page type — drives section composition
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.
descriptionNoWhat the page is for — drives the sections and copy the AI generates
variation_idNoOn a site that still holds several designs: the design to build the site from (from list_variations). Mondovo copies it into the working site and adds to that. Omit on a site that is already built.
nav_placementNoLink the page from the header menu ("main", default), the footer ("footer"), or nowhere ("none"). Only this page is added; existing menu items are never changed.

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. Changed2 schema fields changed
    • changedInput schema / properties / seo / description
      Previous value: -"With `code`: the page's <title> and meta description. Defaults to \"<name> | <site name>\". Change later with update_page_seo."New value: +"With `code`: the page's <title>, meta description and optional JSON-LD `structured_data` ({ \"schemas\": [ { \"@type\": \"…\", … } ] }, replacing the schema Mondovo would generate). Title defaults to \"<name> | <site name>\". Change later with update_page_seo."
    • addedInput schema / properties / seo / properties / structured_data
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "This page's JSON-LD as { \"schemas\": [ { \"@type\": \"BlogPosting\", … }, { \"@type\": \"BreadcrumbList\", … } ] }. Replaces the schema Mondovo would otherwise generate for the page, so include every schema it should carry. \"@context\" is added when absent. Max 50 KB. null clears it (back to the generated schema).",
      +  "properties": {
      +    "schemas": {
      +      "items": {
      +        "additionalProperties": true,
      +        "properties": {
      +          "@type": {
      +            "anyOf": [
      +              {
      +                "minLength": 1,
      +                "type": "string"
      +              },
      +              {
      +                "items": {
      +                  "minLength": 1,
      +                  "type": "string"
      +                },
      +                "minItems": 1,
      +                "type": "array"
      +              }
      +            ]
      +          }
      +        },
      +        "required": [
      +          "@type"
      +        ],
      +        "type": "object"
      +      },
      +      "maxItems": 20,
      +      "minItems": 1,
      +      "type": "array"
      +    }
      +  },
      +  "required": [
      +    "schemas"
      +  ],
      +  "type": "object"
      +}
  3. Changed1 schema field changed
    • changedInput schema / properties / variation_id / description
      Previous value: -"With `code`: the design to add the page to (from list_variations). Omit for the site's chosen design."New value: +"On a site that still holds several designs: the design to build the site from (from list_variations). Mondovo copies it into the working site and adds to that. Omit on a site that is already built."
  4. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only supply readOnly=false, destructive=false, idempotent=false, openWorld=true; the description goes far beyond, disclosing credit consumption, a server-side job with a polling protocol (~10s, ~45-90s), that refusals write NOTHING, that the page isn't live until publish_site, version-history recording with `history_warning`, and the site_id/build_transition handoff on multi-design sites. Nothing contradicts 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.

Conciseness4/5

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

The purpose and mode split are front-loaded and each bullet maps to a decision the agent actually makes. It is nonetheless long (~400 words) for a single tool, and a few clauses (the TSX authoring contract recap, reading read_design for imports) could be condensed or deferred.

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 14-parameter mutation tool with nested objects and no output schema, the description covers prerequisites, async job lifecycle, return shape (slug, file, content key, how_to_edit, version), failure semantics, and the multi-design edge case. 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.

Parameters5/5

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

Schema coverage is 100%, so 3 is the baseline, but the description adds real semantics the schema can't: `code` presence toggles the whole mode, `content` must use NEW top-level keys named page_<slug> and is read as content.page_marketing, `seo.title` defaults to "<name> | <site name>", and `variation_id` selection rules. That is well above what the structured fields convey.

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 description opens with a precise verb+resource+scope ("Add ONE new inner page to an existing site that already has a design") and immediately splits behavior into two named modes. It also names the sibling tools it is not (update_variation_file, patch_variation_content, create_page_draft), so an agent can pick it apart from them without opening a 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?

It states the prerequisite (create_site / create_site_from_design first), the condition that selects each mode (pass `code` or not), and explicit exclusions — use update_variation_file/patch_variation_content to change an existing page, create_page_draft to try an alternative version. It even handles the ambiguous multi-design case with the `choose_design` fallback.

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