Skip to main content
Glama

Create a landing page

create_page

Generate a new landing page from a description. Creates a real page in the workspace (HTML with copy, layout, and imagery), saved as a draft you can open in the editor or publish. Returns the page id, a shareable preview URL to view the result, and its edit URL. Publishing is a separate step.

Input Schema

NameRequiredDescriptionDefault
nameNoOptional page name shown in the dashboard. Defaults to a title derived from the description.
outlineNoOptional explicit section outline (markdown or plain text). When omitted, the page is structured from the description.
descriptionYesWhat the page is for: the business/offer, audience, key sections, and the primary call to action. The richer this is, the better the page.
workspace_idNoWhich workspace to act in. Only meaningful when this connection can access more than one workspace: omit it and you get an error listing the available workspace ids (also available from list_sites) to choose from. On a single-workspace connection, omit it or pass that workspace's own id; a different id is rejected.

Output Schema

NameRequiredDescriptionDefault
nameYes
noteYesHuman-readable summary of what to do next.
pageIdYesUUID of the new page.
statusYes
editUrlYes
finalizedYesFalse when the page generated and saved but its dashboard record didn't finish updating. The page itself is fine; the list may lag.
truncatedYesTrue if generation hit the output cap and may be cut short.
previewUrlYesShareable link. When previewCurrent is false it may not show the new page for a moment.
imagesFailedYes
previewCurrentNoWhether previewUrl already serves the new page. False means it is saved but the preview may lag a moment; editUrl shows it now. Absent on pages built by the older engine, which serve it at once.
imagesGeneratedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedOutput schema / properties / previewCurrent
      Added value: +{
      +  "description": "Whether previewUrl already serves the new page. False means it is saved but the preview may lag a moment; editUrl shows it now. Absent on pages built by the older engine, which serve it at once.",
      +  "type": "boolean"
      +}
    • changedOutput schema / properties / previewUrl / description
      Previous value: -"Shareable link that works immediately."New value: +"Shareable link. When previewCurrent is false it may not show the new page for a moment."
  2. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations only state that this is not read-only, while the description adds meaningful behavioral context: it creates a real page in the workspace, saves it as a draft, allows opening/publishing later, and returns preview and edit URLs. This goes well beyond the annotation and clearly indicates mutation and draft-state behavior.

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 concise and front-loaded: the first sentence states the action, subsequent sentences explain output, draft state, and the separate publishing step. Every sentence adds useful information without repetition or 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?

Given the output schema and full parameter schema coverage, the description is complete enough for an agent to call the tool correctly. It also adds the important context that creation results in a draft rather than a published page, which is not captured by the minimal annotations.

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

Parameters3/5

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

Schema description coverage is 100%, so all four parameters are already documented in the input schema, including name, outline, description, and workspace_id semantics. The description adds only a high-level reference to generating from a description and does not add parameter-specific detail beyond the schema, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: generate/create a new landing page from a description, and it clarifies that a real workspace page is produced. It does not explicitly differentiate itself from sibling tools such as add_page_to_site or create_site, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for creating a new landing page and notes that publishing is a separate step, which gives some usage context. However, it does not explicitly say when to use this tool versus add_page_to_site, create_site, or edit_page, leaving alternatives to inference.

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