simplepages

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

TableJSON Schema

Name	Required	Description
`name`	No	Optional page name shown in the dashboard. Defaults to a title derived from the description.
`outline`	No	Optional explicit section outline (markdown or plain text). When omitted, the page is structured from the description.
`description`	Yes	What 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_id`	No	Which 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

TableJSON Schema

Name	Required	Description
`name`	Yes
`note`	Yes	Human-readable summary of what to do next.
`pageId`	Yes	UUID of the new page.
`status`	Yes
`editUrl`	Yes
`finalized`	Yes	False when the page generated and saved but its dashboard record didn't finish updating. The page itself is fine; the list may lag.
`truncated`	Yes	True if generation hit the output cap and may be cut short.
`previewUrl`	Yes	Shareable link that works immediately.
`imagesFailed`	Yes
`imagesGenerated`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only indicate readOnlyHint=false, and the description goes well beyond that by disclosing that a real page is created in the workspace, saved as a draft, can be opened/published later, and returns specific URLs. This gives the agent a strong sense of side effects and result shape.

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?

Three concise, front-loaded sentences: first states the core action, second explains what gets created and its draft state, third lists returned values and the publishing workflow. No filler or redundant restatement of the title.

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 rich input schema and presence of an output schema, the description supplies the remaining workflow context: draft status, editor availability, and the separation of publishing. This is complete for a creation tool and needs no further elaboration.

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 the schema already documents all four parameters thoroughly. The description reinforces the centrality of the 'description' parameter but adds no parameter-level details beyond what the schema provides, matching the baseline for high coverage.

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?

Description uses specific verbs 'Generate' and 'Creates' with the resource 'landing page' and clearly differentiates from siblings by emphasizing creation of a new page as a draft, with publishing as a separate step. It also states concrete outputs (page id, preview URL, edit URL), making the tool's role unmistakable.

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

Usage Guidelines4/5

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

Clear context is provided: use this to create a landing page from a description, and publishing is explicitly called out as a separate step. However, it does not explicitly name alternatives like edit_page for modifications or get_page for retrieval, so it stops short of full when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All simplepages tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation5/5

Each tool has a distinct purpose, with clear differentiation between creating standalone pages vs. adding to sites, and separate analytics for pages, sites, and workspaces.

Naming Consistency4/5

Mostly follows verb_noun pattern, but uses both 'add' and 'create' for similar actions, and 'delete' vs 'remove' inconsistently.

Tool Count4/5

20 tools cover a broad range of functionality (pages, sites, redirects, scripts, webhooks, analytics, leads), which is reasonable but slightly on the higher side.

Completeness3/5

Covers CRUD for most entities, but lacks delete operations for pages, sites, scripts, and webhooks (except redirects), leaving notable gaps.

Resources

Need Help?