Create Web Page

Start Guided Page Onboarding

page_onboarding_start

Read-onlyIdempotent

Guided visual setup (category, layout, palette, primary action) that does NOT create a page. Use it ONLY when the user explicitly wants to choose the style/layout step by step; for normal requests call page_create_from_brief (asking at most one round of questions first). IMPORTANT: this flow is STATELESS — page_onboarding_update does not remember earlier calls, so each update must resend the FULL set of selections + knownFields gathered so far. As soon as you have a business name and a primary action, stop and call page_create_from_brief (you do not need to reach a 'ready' step).

Input Schema

TableJSON Schema

Name	Required	Description
`locale`	No	Preferred UI locale: en or es. If omitted, Spanish is used only when originalRequest is clearly Spanish; otherwise English. The result echoes the resolved locale — pass it on every page_onboarding_update call.
`originalRequest`	No
`suggestedSelection`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`ok`	Yes
`mode`	Yes
`locale`	Yes
`stepId`	Yes
`uiHtml`	Yes
`choices`	Yes
`selected`	Yes
`nextPrompt`	Yes
`canContinue`	Yes
`profileCopy`	Yes
`slugGuidance`	Yes
`imageGuidance`	Yes
`layoutChoices`	Yes
`missingFields`	Yes
`readyToCreate`	Yes
`layoutGuidance`	Yes
`paletteChoices`	Yes
`primaryActions`	Yes
`invalidSelection`	Yes
`qualityChecklist`	Yes
`recommendedLinks`	Yes
`recommendedBlocks`	Yes
`createFromBriefHints`	Yes
`recommendedMissingFields`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 5, 2026

changedInput schema / properties / locale / description

Previous value: -"Preferred UI locale, such as es or en."New value: +"Preferred UI locale: en or es. If omitted, Spanish is used only when originalRequest is clearly Spanish; otherwise English. The result echoes the resolved locale — pass it on every page_onboarding_update call."

addedOutput schema / properties / locale

Added value: +{
+  "enum": [
+    "en",
+    "es"
+  ],
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "ok",
-  "mode",
-  "stepId",
-  "canContinue",
-  "selected",
-  "invalidSelection",
-  "missingFields",
-  "choices",
-  "layoutChoices",
-  "paletteChoices",
-  "primaryActions",
-  "recommendedLinks",
-  "recommendedBlocks",
-  "profileCopy",
-  "slugGuidance",
-  "qualityChecklist",
-  "recommendedMissingFields",
-  "layoutGuidance",
-  "imageGuidance",
-  "readyToCreate",
-  "uiHtml",
-  "nextPrompt",
-  "createFromBriefHints"
-]New value: +[
+  "ok",
+  "mode",
+  "locale",
+  "stepId",
+  "canContinue",
+  "selected",
+  "invalidSelection",
+  "missingFields",
+  "choices",
+  "layoutChoices",
+  "paletteChoices",
+  "primaryActions",
+  "recommendedLinks",
+  "recommendedBlocks",
+  "profileCopy",
+  "slugGuidance",
+  "qualityChecklist",
+  "recommendedMissingFields",
+  "layoutGuidance",
+  "imageGuidance",
+  "readyToCreate",
+  "uiHtml",
+  "nextPrompt",
+  "createFromBriefHints"
+]

AddedSep 22, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare this as a safe, idempotent, non-destructive local read, but the description adds substantive flow behavior beyond them: the flow is STATELESS, page_onboarding_update retains nothing, and each update must resend the full selection set. This is high-value context that no annotation conveys and directly prevents incorrect call sequences.

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?

Front-loaded with the purpose, then usage, then the stateless caveat, then the stop condition — a logical progression where each sentence carries a distinct instruction. It is dense and all-caps emphasis is heavy, but no sentence is dead weight.

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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. The description supplies the missing usage and statefulness context, leaving nothing an agent needs to invoke this correctly unexplained.

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 coverage is low (33%), so the description needs to compensate but largely doesn't. It hints at what suggestedSelection should hold ('category, layout, palette, primary action' and 'resend the FULL set of selections + knownFields'), but leaves originalRequest undocumented and gives no field-level syntax. Partial compensation warrants a mid-low score.

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?

States a specific verb and resource (guided visual setup) and immediately scopes it with 'does NOT create a page,' which contrasts it against page_create_from_brief and the other page-creation siblings. An agent can distinguish this tool from its neighbors without opening any 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?

Gives explicit when/when-not guidance ('Use it ONLY when the user explicitly wants to choose the style/layout step by step') plus the alternative and its own protocol ('for normal requests call page_create_from_brief, asking at most one round of questions first'). It even names the terminating condition ('as soon as you have a business name and a primary action, stop'), so the routing decision is fully determined.

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?