WebTwizz

Site preview

show-preview

Read-only

Use this when the user wants to see or look at one of their WebTwizz sites ("show me my bakery site"), or a page of one, for example after a change. Shows the latest draft in a card where they can also click things to change them; pass live to show the published site instead. site_id can be the site's name.

Input Schema

Name	Required	Description
`live`	No	Show the published site instead of the latest draft. Only when the user asks for the live version.
`path`	No	Page to open, like /menu. Defaults to the home page.
`site_id`	Yes

Output Schema

Name	Required	Description	Default
`name`	Yes
`note`	No
`path`	Yes
`view`	Yes
`pages`	No
`site_id`	Yes
`live_url`	No
`open_url`	Yes
`frame_url`	Yes
`show_live`	Yes
`preview_url`	Yes
`preview_ready`	Yes
`live_frame_url`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 26, 2026

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

addedOutput schema / properties / pages

Added value: +{
+  "items": {
+    "properties": {
+      "name": {
+        "type": "string"
+      },
+      "path": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "name",
+      "path"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

First observedOct 16, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint/non-destructive, so the description's job is to add beyond that — and it does: the result is a rendered card, it shows the latest draft by default, and it is interactive. Note that 'click things to change them' describes user-driven UI editing rather than tool side effects, which is worth flagging but does not contradict the read-only hint for this call itself.

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 usage trigger, then behavior, then the live override — a sensible order with fairly tight phrasing. It is somewhat conversational and runs long in a single paragraph, but no sentence is pure filler.

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 not be described; combined with annotations and the 67% schema coverage, the description supplies the remaining pieces an agent needs: when to call it, draft-vs-live default, and the flexible site_id form.

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 67% and site_id has no schema description at all, so the description earns credit for documenting that 'site_id can be the site's name.' It also reinforces live (published site) and implies path targeting, though it does not illustrate the path format the way the schema does.

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+resource ('shows the latest draft' of a WebTwizz site/page) and adds a distinguishing trait versus screenshot-site: it renders in an interactive card where elements can be clicked and edited. It never names screenshot-site, so the differentiation is implicit rather than explicit.

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?

'Use this when the user wants to see or look at one of their sites... for example after a change' gives a concrete trigger context. It also specifies the live-vs-draft selection rule, but offers no exclusion guidance against sibling tools like screenshot-site or get-site.

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?