WebTwizz

Site settings

update-site

Destructive

Use this when the user wants to rename one of their WebTwizz projects, or choose who can see the published site: anyone (public), people with a password, or only people in their WebTwizz workspace (private). Visibility applies the next time the site is published. Page titles, descriptions and other SEO live in the site itself, so change those with edit-site.

Input Schema

Name	Required	Description
`name`	No	The new project name.
`site_id`	Yes
`password`	No	For password visibility: the password visitors will need, at least 4 characters. Only send it when the user gives one.
`visibility`	No

Output Schema

Name	Required	Description
`name`	Yes
`note`	No
`site_id`	Yes
`live_url`	No
`open_url`	Yes
`visibility`	Yes
`preview_url`	Yes
`settings_url`	No	Where the user sets the password
`live_frame_url`	No
`publish_needed`	Yes	True when the live site still has the old visibility until it is published again
`password_needed`	No	True when the user still has to set the visitors' password in WebTwizz

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 26, 2026

addedOutput schema / properties / note
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / password_needed

Added value: +{
+  "description": "True when the user still has to set the visitors' password in WebTwizz",
+  "type": "boolean"
+}

addedOutput schema / properties / settings_url

Added value: +{
+  "description": "Where the user sets the password",
+  "type": "string"
+}

First observedOct 16, 2026

TDQS

A4.3/5.0

Behavior3/5

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

Annotations declare destructiveHint=true, readOnlyHint=false, but the description never explains what is destructive or irreversible about the change. It does add one genuinely useful behavioral fact not in the annotations: visibility only takes effect on the next publish. That partial disclosure earns more than the minimum but leaves the risk profile unexplained.

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 trigger condition is front-loaded and each of the three sentences carries distinct information: capability, deferred-effect caveat, and sibling routing. Slightly dense in one paragraph, but nothing is redundant.

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?

An output schema exists so return values need no explanation, and annotations cover the safety flags. For a 4-parameter mutation tool the description is nearly complete, though it could say whether renaming affects the published URL or whether a password is required when switching to password visibility.

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 only 50% (site_id and visibility have no schema descriptions), but the description compensates by explaining the three visibility values semantically — public, password-protected, and workspace-private — which is more than the bare enum conveys. The password and name params are already documented in the schema, and site_id is self-evident as the target.

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?

Names the specific resource (a WebTwizz project/site) and the two concrete mutations it performs: renaming and setting visibility. It also explicitly routes SEO/page-content changes to the sibling edit-site, so an agent can distinguish the two without opening schemas.

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?

Opens with an explicit trigger ('Use this when the user wants to rename... or choose who can see...') and names the alternative tool (edit-site) plus the condition that selects it (page titles, descriptions, SEO). Both when-to-use and when-not-to-use are stated.

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?