WebTwizz

New site

create-site

Use this when the user wants an idea or this conversation turned into a real website or web app with WebTwizz. Creates a new WebTwizz project from a brief, and optionally the user's pictures or a website to start from, and starts building it right away. The card shows the build live; the site opens in WebTwizz for visual editing. Uses the account's WebTwizz credits, and each call makes another new site.

Input Schema

Name	Required	Description
`name`	No	A short project name of two to four words.
`brief`	Yes	Everything WebTwizz needs to build the site, written from the conversation: what it is, who it is for, the pages and features, and any look, copy or brand details the user gave.
`files`	No	Other files from this conversation the site should use: SVG logos, or documents like a menu, price list or notes (PDF, Word or text), which WebTwizz reads for their content.
`images`	No	Pictures for the site: photos or a logo the user shared, images made in this conversation, or a screenshot of a design to match.
`template`	No	A template slug from list-templates to start from instead of a blank project.
`workspace_id`	No	The workspace to create it in, from get-account. Leave out for the user's own workspace.
`reference_url`	No	A website to work from: the user's current site to redesign, or a site they want theirs to look like. WebTwizz opens it and builds from it.

Output Schema

Name	Required	Description
`kind`	Yes
`name`	Yes
`plan`	No
`error`	No
`stage`	No
`steps`	Yes
`checks`	No
`job_id`	Yes
`latest`	No
`status`	Yes	queued, starting, building, done, needs_input, failed or stopped
`choices`	No	When the summary ends by offering numbered options: those options, for the user to pick one
`site_id`	Yes
`summary`	No
`live_url`	No
`open_url`	Yes
`question`	No
`compiling`	No	The preview is still updating with the finished change
`follow_ups`	Yes	Things the user still has to do in WebTwizz, like connecting a database or adding a key
`undo_guard`	No	Pass as only_if_latest when undoing, so newer work is never lost
`preview_url`	Yes
`confirmation`	No	Set while the build waits for the user to approve something; answer with confirm-action
`files_changed`	Yes
`preview_ready`	Yes	Whether the draft preview is running right now
`undo_point_id`	No	Pass to restore-version to undo this change; only set while nothing has changed since
`live_frame_url`	No
`elapsed_seconds`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 26, 2026

changedInput schema / properties / images / description

Previous value: -"Pictures for the site, each as a link WebTwizz can download: photos or a logo the user shared, or a screenshot of a design to match."New value: +"Pictures for the site: photos or a logo the user shared, images made in this conversation, or a screenshot of a design to match."

First observedOct 16, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Adds meaningful behavioral context beyond the annotations: it builds immediately, the card shows a live build, the site opens in WebTwizz for visual editing, it consumes account credits, and each call creates another new site (warning about unintended duplication). It does not cover authentication or rate limits, but the disclosed behavior is substantial for a creation tool.

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?

Four sentences, front-loaded with the usage trigger, then creation behavior, live build process, and cost/idempotency warning. Each sentence contributes useful information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema and rich annotations, the description covers when to use the tool, what it does, its live build behavior, credit consumption, and non-idempotency. It leaves out explicit sibling alternatives and edge cases like build failure, but is otherwise complete for calling the tool correctly.

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 parameter meanings are already fully documented in the schema. The description only summarizes optional inputs ('pictures or a website to start from') without adding syntax or constraints beyond what the schema provides, making the baseline of 3 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?

States a specific verb and resource: 'Creates a new WebTwizz project from a brief' and 'starts building it right away.' The purpose is immediately clear, though it does not explicitly name a sibling alternative to distinguish it from, for example, duplicate-site or update-site.

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?

Provides a clear usage trigger: 'Use this when the user wants an idea or this conversation turned into a real website or web app with WebTwizz.' It does not explicitly state when not to use it or name alternative tools, but the context is sufficiently clear for an agent to select it.

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

All WebTwizz tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?