Skip to main content
Glama

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

TableJSON Schema
NameRequiredDescriptionDefault
nameNoA short project name of two to four words.
briefYesEverything 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.
filesNoOther 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.
imagesNoPictures 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.
templateNoA template slug from list-templates to start from instead of a blank project.
workspace_idNoThe workspace to create it in, from get-account. Leave out for the user's own workspace.
reference_urlNoA 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

TableJSON Schema
NameRequiredDescriptionDefault
kindYes
nameYes
planNo
errorNo
stageNo
stepsYes
checksNo
job_idYes
latestNo
statusYesqueued, starting, building, done, needs_input, failed or stopped
choicesNoWhen the summary ends by offering numbered options: those options, for the user to pick one
site_idYes
summaryNo
live_urlNo
open_urlYes
questionNo
compilingNoThe preview is still updating with the finished change
follow_upsYesThings the user still has to do in WebTwizz, like connecting a database or adding a key
undo_guardNoPass as only_if_latest when undoing, so newer work is never lost
preview_urlYes
confirmationNoSet while the build waits for the user to approve something; answer with confirm-action
files_changedYes
preview_readyYesWhether the draft preview is running right now
undo_point_idNoPass to restore-version to undo this change; only set while nothing has changed since
live_frame_urlNo
elapsed_secondsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already establish this is a non-read-only, non-destructive, open-world write, but the description goes well beyond them: it consumes the account's WebTwizz credits (a cost signal), the build starts immediately and is shown live on a card, the result opens in WebTwizz for visual editing, and calling again creates yet another site — an important duplicate-creation warning.

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 invocation condition and efficient across three sentences, but the third sentence bundles several distinct facts (live card, visual editing, credits, repeat creation) that could be tightened slightly.

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 create tool with a full output schema and complete parameter documentation, the description covers what an agent needs: intent trigger, what is created, immediate build behavior, credit cost, and the fact that subsequent calls spawn additional projects. Nothing material is missing.

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 seven parameters, and the baseline is 3. The description only gestures at brief, images and reference_url ('a brief, and optionally the user's pictures or a website to start from') and adds nothing about name, files, template or workspace_id.

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' that 'starts building it right away.' The closing clause 'each call makes another new site' implicitly separates it from duplicate-site and update-site, but no sibling is named explicitly, which is what a 5 would require.

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?

Explicit trigger given: 'Use this when the user wants an idea or this conversation turned into a real website or web app.' It clarifies the user-intent condition well, but offers no when-not guidance or named alternatives (e.g. editing an existing site with update-site instead).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources