Cactal

Create a website

websites_create

Creates a website in the organization. Provide either a name (trimmed, 1–200 characters) or a creation prompt; a prompt returns immediately with the temporary name Untitled site, which the built-in naming request attempts to replace on its next run together with a matching available slug and platform hostname. The hostname receives a short suffix when the clean hostname is unavailable. An omitted slug is allocated from the initial name; an explicit slug must be lowercase, URL-safe, unreserved, and unique among active websites in the organization. The website starts as an unpublished draft at headVersion 1. Send an idempotencyKey to make retries return the same website. Edit its source through the Source code operations, then publish with websiteSourceCode.head.publish.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "organizationId": "<organizationId>"
    },
    "name": "websites_create"
  }
}

Input Schema

Name	Required	Description
`name`	No
`slug`	No
`prompt`	No
`idempotencyKey`	No	Caller-generated key, such as a UUID, that makes creation safe to retry. Send the same key on every retry of one creation attempt: when this organization already has a website created with the key, that website is returned and no second website is created. A key whose website is in the trash returns a 409 with `idempotencyKeyStatus: "deleted"`; retry with a new key.
`organizationId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations (which only say non-read-only, non-destructive, open-world false) by disclosing prompt-path side effects: an immediate return with the placeholder name "Untitled site", a deferred renaming run, hostname suffixing on collision, and draft state at headVersion 1. It also explains the retry contract around idempotencyKey, including the stale-key case, which the idempotentHint=false annotation leaves ambiguous.

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 action and the name/prompt choice, then progresses through slug, hostname, draft state, idempotency, and next steps in a logical order with no filler. The slug sentence is a long multi-clause run-on that could be split for scanability.

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?

For a 5-parameter mutation tool with no output schema, it covers creation modes, defaults, naming/hostname resolution, initial draft state, and safe retry. The one gap is what the created object contains on return (identifiers, slug/hostname fields an agent would need for follow-up calls) — implied by "returns the same website" but not spelled out.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 20% (idempotencyKey alone is documented), so the description must compensate and does: name trimming and length, slug character rules (lowercase, URL-safe, unreserved, org-unique among active sites), and default slug allocation from the initial name. It also defines the prompt parameter's asynchronous naming behavior and the 1-200 bound, adding meaning the bare schema does not carry.

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 ("Creates a website in the organization") and immediately scopes it against the other website tools by describing creation only, with editing/publishing routed elsewhere. An agent can distinguish it from websites_get, websites_list, websites_rename, and websiteSourceCode_* 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete selection guidance between the two creation paths ("Provide either a `name` ... or a creation `prompt`") and tells the agent the follow-on path: edit source via Source code operations, then publish with websiteSourceCode.head.publish. It stops short of explicit when-not-to-use conditions (e.g., cloning or duplicating an existing site), so not a 5.

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

All Cactal tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?