Create Web Page

Create Landing Page From Brief

page.create_from_brief

Create a hosted landing page draft from a structured brief. Accepts business name, category, layout, palette, primary action, explicit final-audience publicSections, and optional hero image. Planning fields such as audience, offer, primaryGoal, location, businessType, style, and mustInclude are context only and are not rendered as public body copy. Draft previews are customer-facing: do not pass owner instructions, section-planning labels, or placeholder copy as public content. Keep sparse briefs sparse: use only facts supplied by the user or imported public sources, plus light wording polish; do not invent menus, services, hours, facilities, locations, testimonials, guarantees, staff details, prices, or operational claims. Prefer one short section or no extra section when the prompt is minimal. If a requested CTA lacks its real destination, ask for it before creation or provide fallbackLeadForm with public copy. Returns a preview URL, edit token, and next-step hints. This tool intentionally creates a draft only and does not return a publish action. After calling it, stop and show the preview URL. Do not call page.publish in the same turn unless the user's current message explicitly asks to publish, make the page live, or get a public share link. Anonymous pages expire unless claimed via page.claim.

Input Schema

TableJSON Schema

Name	Required	Description
`bio`	No	Optional short bio for the header.
`offer`	No	Planning context only. Not rendered directly as public page copy; use bio and publicSections for final-audience copy.
`style`	No	Planning context only. Not rendered directly as public page copy.
`layout`	No	Defaults to 'link_in_bio'.
`locale`	No
`preset`	No	Style preset id, or 'auto' to infer deterministically. Defaults to 'auto'.
`audience`	No	Planning context only. Not rendered directly as public page copy.
`location`	No	Public business address or service area intended for map/address actions, not direct body copy and not the user's private/current location.
`sourceUrl`	No	Provenance reference only.
`mustInclude`	No	Planning checklist only. Do not put section names, CTA labels, owner instructions, or private notes here; not rendered directly.
`primaryGoal`	No	Planning context only. Not rendered directly as public page copy.
`publicPhone`	No	Public business phone number explicitly supplied by the user or a public source. Do not use the user's private/account phone.
`businessName`	Yes
`businessType`	No	Planning context only. Not rendered directly as public page copy.
`heroImageUrl`	No	Explicit user-provided image URL for featured-photo or full-image styles.
`sourceHandle`	No
`initialPrompt`	No
`preferredSlug`	No	Desired URL path. Ask the user for it near the end of onboarding. Use normal letters, numbers, and hyphens; the server normalizes and makes it unique.
`publicSections`	No	Final-audience text sections to render on the public page. Write in the target language with correct spelling/accents. Only include facts the user supplied or that came from an imported public source; for sparse prompts, keep this short and avoid invented service lists, hours, benefits, testimonials, prices, or operational details.
`publicWhatsapp`	No	Public WhatsApp phone number explicitly supplied by the user or a public source. Do not use the user's account phone or invent placeholder numbers.
`primaryActionId`	No
`fallbackLeadForm`	No	Public fallback contact/interest form to use when the requested primary action lacks a real destination. All copy must be final-audience copy in the page's target language.
`onboardingLayout`	No	Layout style: background_color (minimalist), full (featured photo), or background_image (full image background).
`primaryActionUrl`	No	Real destination URL for the primary action when explicitly supplied by the user or imported public source, such as a booking link. Do not invent booking/order URLs; if missing, ask for it or use fallbackLeadForm.
`onboardingPalette`	No	Palette id returned by page.onboarding.* paletteChoices, for example atom_dark_plum.
`primaryActionLabel`	No	Public label for the primary action in the page's target language.
`publicBusinessEmail`	No	Public business contact email explicitly supplied by the user or a public source. Do not use the user's ChatGPT/account email.
`onboardingSubCategory`	No	Validated atom.bio subcategory id, for example health.
`onboardingMainCategory`	No	Validated atom.bio category id from page.onboarding.*, for example physical-business or online-business.

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes
`slug`	Yes
`title`	Yes
`pageId`	Yes
`status`	Yes
`actions`	Yes
`content`	No
`claimUrl`	Yes
`editToken`	Yes
`expiresAt`	Yes
`isClaimed`	Yes
`nextSteps`	No	Enrichment hints to present to the user. Address 'required' items before publishing.
`canPublish`	Yes
`previewUrl`	Yes
`isPublished`	Yes
`publishedUrl`	Yes
`missingFields`	No
`publishPolicy`	No	For edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing.
`liveUpdateMessage`	No	Plain-language instruction explaining that an edit to an already-published page is draft-only and must not be published until a later explicit user request.
`liveUpdateRequired`	No	True after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision.

TDQS

A4.8/5.0

Behavior5/5

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

Annotations provide no behavioral hints (all false), so the description carries the full burden. It discloses that previews are customer-facing, that planning fields are not rendered, that sparse briefs should stay sparse, that it creates only a draft, and that anonymous pages expire. These are significant behavioral traits beyond schema 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 description is long but front-loaded with a clear one-line summary. Every sentence adds operational guidance; though some could be tightened, the length is justified by the tool's complexity (29 params, nested objects, content safety rules).

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?

Despite having 29 params and nested objects, the description covers the critical context: what it returns (preview URL, edit token), what it does not do (no publish action), post-call behavior (stop and show URL), and expiration flow. The output schema covers return details, so no further explanation needed.

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 83%, so most parameters are documented. The description adds cross-cutting semantics: it groups planning-only fields, warns against passing owner instructions/placeholders, and clarifies fallbackLeadForm usage when a CTA lacks a destination. It doesn't fully cover all 29 params but the schema handles most.

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 specific verb+resource: 'Create a hosted landing page draft from a structured brief.' It lists accepted inputs and explicitly distinguishes this draft-only tool from page.publish and page.claim, clarifying its role among siblings.

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?

Explicitly instructs when to stop after calling, not to call page.publish unless the user asks, and to use page.claim for anonymous page expiration. It also provides decision guidance for missing CTA destinations (ask or use fallbackLeadForm).

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

All Create Web Page 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.1/5.0

Disambiguation4/5

Most tools target distinct resources and actions (blocks, accounts, pages), but page.create and page.create_from_brief both create pages, and page.intake.start vs page.onboarding.start/update are overlapping planning helpers. The detailed descriptions help disambiguate, though an agent might still pause on choosing between them.

Naming Consistency5/5

All tool names follow a consistent lowercase dot-separated resource.action pattern (e.g., block.add, page.publish, account.whoami). Nested resources like page.header.update and page.onboarding.update extend the same rule without mixing conventions.

Tool Count3/5

At 23 tools, the count sits in the borderline 16-25 range. Many tools are specific and justified, but the planning helpers (intake/onboarding) and multiple page creation variants add bulk that could be consolidated.

Completeness3/5

The server covers create, read, update, block management, and publish/unpublish, but misses a page.delete operation, leaving a lifecycle dead-end. Account tools are also minimal, limited to reading/listing without management capabilities.

Resources

Need Help?