Create Web Page

Create Landing Page From Brief

page_create_from_brief

The main tool for creating a page. Call it directly when the request already has the business/page name and the main visitor action with its real destination (WhatsApp number with country code, booking/order link, phone, address or email); if the request is vague, ask at most one round of questions first (page_intake_start lists them). Creates a private draft and returns previewUrl, pageId, editToken (anonymous pages), claimUrl and expiresAt. Planning fields (audience, offer, primaryGoal, location, businessType, style, 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; never invent menus, services, hours, facilities, locations, testimonials, guarantees, staff details, prices, or operational claims. If a requested action lacks its real destination, ask for it, or use fallbackLeadForm with destinationEmail (ask the user which email should receive enquiries — without it the form cannot deliver anything and cannot be the page's only action at publish). Personal, gift or event pages (birthday, invitation, tribute, a poem) need no contact form and no action at all: a page with real text (bio + publicSections) can be published as is; add a link (primaryActionUrl, e.g. RSVP, gift list or playlist) only if the user has one, never primaryActionId 'lead'. After calling it, show the preview URL and stop; call page_publish only when the user explicitly asks to publish, make it live, or get a public link. Anonymous pages are deleted after expiresAt unless the user claims them via claimUrl. Passing onboardingMainCategory picks the matching template. The draft also seeds the preset's starter blocks (empty placeholder links, social row, save-contact) — they never block publishing and are pruned if left empty. Use the returned previewUrl directly (no need for page_preview). nextSteps marked recommended/optional (bio, photo, social links) are improvements to offer after the user has seen the preview; only 'required' ones block publishing.

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 subcategory id from page_onboarding_*, for example health.
`onboardingMainCategory`	No	Validated 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	Improvement hints. Only 'required' items block publishing (they mirror the publish guard); 'recommended' and 'optional' are suggestions to offer after the user has seen the preview, never prerequisites.
`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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 5, 2026

addedInput schema / properties / fallbackLeadForm / properties / destinationEmail

Added value: +{
+  "description": "Private email that receives the form's enquiries (never shown on the page). Ask the user which email should receive them; without it the form cannot deliver anything and cannot be the page's only action at publish.",
+  "format": "email",
+  "type": "string"
+}

changedInput schema / properties / onboardingMainCategory / description

Previous value: -"Validated atom.bio category id from page_onboarding_*, for example physical-business or online-business."New value: +"Validated category id from page_onboarding_*, for example physical-business or online-business."

changedInput schema / properties / onboardingSubCategory / description

Previous value: -"Validated atom.bio subcategory id, for example health."New value: +"Validated subcategory id from page_onboarding_*, for example health."

changedOutput schema / properties / nextSteps / description

Previous value: -"Enrichment hints to present to the user. Address 'required' items before publishing."New value: +"Improvement hints. Only 'required' items block publishing (they mirror the publish guard); 'recommended' and 'optional' are suggestions to offer after the user has seen the preview, never prerequisites."

AddedSep 22, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only declare a non-read-only, non-destructive, non-idempotent, closed-world write. The description adds substantial behavioral context: it creates a private draft, returns previewUrl/pageId/editToken/claimUrl/expiresAt, anonymous pages are deleted after expiresAt unless claimed, starter blocks are seeded and pruned, and nextSteps severity controls publishing. This far exceeds the annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The core purpose is front-loaded, but the body is a dense multi-clause run-on with many conditional branches (actions, fallback forms, personal pages, claiming, nextSteps) that is hard to parse. The content is largely relevant, yet the structure is a wall of text rather than scannable guidance.

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 29-parameter tool with nested objects, this is thorough: it explains the draft lifecycle, return values, publish gating, anonymous-page expiry, fallback-form constraints, and sparse-brief handling. An agent has enough to invoke and follow up correctly.

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 high (83%) and already documents most parameters, but the description adds real meaning: which fields are planning-only and never rendered as body copy, that onboardingMainCategory selects a template, and that fallbackLeadForm requires destinationEmail to deliver. It compensates for the gaps rather than repeating the schema.

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?

States a specific verb and resource ('The main tool for creating a page') and describes the brief-to-draft flow in detail. However, it never explicitly distinguishes itself from the sibling page_create, so an agent must infer which of the two creation tools applies.

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?

Gives explicit when-to-use conditions ('call it directly when the request already has the business/page name and the main visitor action with its real destination'), the vague-request branch pointing to page_intake_start, and clear routing rules to page_publish and page_preview. Alternatives and exclusions are named.

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

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?