Skip to main content
Glama

sitectrl

by ai.sitectrl
OverviewDiscussionsAdmin

Create a new site

create_site

Build a brand-new hosted website from a plain-language description. RETURNS IMMEDIATELY with status 'building' — the site takes about 2-3 minutes and is NOT ready when this returns. Tell the user where it will be (expected_url / live_url) and poll get_build_status — with the returned slug when signed in, with the returned claim_token for a guest build. NEVER call create_site a second time for the same site: each call builds another one. Works WITHOUT signing in: an unauthenticated call builds a guest site and returns a claim_url — the user signs up free (no card) at that link to keep it; unclaimed guest sites are deleted after 72 hours. Signed in, the site lands directly on the connected account (free tier: one site, no card).

Input Schema

NameRequiredDescriptionDefault
templateNoOptional override of the starting template. Omit it and the template is chosen from the description.
site_nameYesShort human name for the site, e.g. 'Whitney Apparel'.
descriptionYesWhat the site is for. MINIMUM 12 CHARACTERS — a bare 'bike shop' is rejected. Say what the business is, where it is, and what the site should include; the AI builds directly from this, so more detail means a better first result. Good: 'Oak Barrel Coffee, a small-batch roaster in Turlock CA — our story, three coffees with tasting notes and prices, and a contact form.' If the user was vague, ask them one question before calling this rather than sending two words.
contact_emailNoOptional, guest builds only: the user's email — we send the site link and a reminder before the unclaimed site expires.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / template / description
      Previous value: -"Starting template (guest builds; default local-services)."New value: +"Optional override of the starting template. Omit it and the template is chosen from the description."
  2. Changed1 schema field changed
    • changedInput schema / properties / template / enum
      Previous value: -[
-  "local-services",
-  "blank",
-  "restaurant",
-  "brewery",
-  "shop",
-  "portfolio"
-]New value: +[
+  "local-services",
+  "restaurant",
+  "shop",
+  "portfolio",
+  "classes",
+  "community"
+]
  3. Changed2 schema fields changed
    • changedInput schema / properties / description / description
      Previous value: -"What the site is for — business, tone, sections wanted. The AI builds directly from this."New value: +"What the site is for. MINIMUM 12 CHARACTERS — a bare 'bike shop' is rejected. Say what the business is, where it is, and what the site should include; the AI builds directly from this, so more detail means a better first result. Good: 'Oak Barrel Coffee, a small-batch roaster in Turlock CA — our story, three coffees with tasting notes and prices, and a contact form.' If the user was vague, ask them one question before calling this rather than sending two words."
    • addedInput schema / properties / description / minLength
      Added value: +12
  4. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only say it is not read-only and not destructive; the description adds the critical async behavior (returns immediately with status 'building', ~2-3 minutes), the duplicate-build side effect, the 72-hour deletion window for unclaimed guest sites, and the free-tier one-site limit. These are exactly the traits an agent cannot infer from the structured fields.

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 'RETURNS IMMEDIATELY' warning before any auth detail, and nearly every sentence carries operational consequence. It is dense, packing auth modes, polling instructions, and claim mechanics into long parenthetical sentences, which slightly hurts scanability but not substance.

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?

There is no output schema, and the description compensates by naming the fields returned (status, slug, claim_token, claim_url, expected_url / live_url) and what to do with each. Combined with the guest-claim and free-tier rules, an agent has everything needed to call this and handle the response 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 site_name, description, template, and contact_email are already fully documented with examples and constraints in the schema itself. The description reinforces intent ('plain-language description', guest-only claim flow) but adds no parameter-level syntax or format detail beyond what the schema states, which is the correct baseline.

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 ('Build a brand-new hosted website from a plain-language description') and implicitly separates itself from edit_site and get_build_status by making clear this creates a new artifact each time. An agent can pick this over the siblings 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 Guidelines5/5

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

Explicitly covers when to call (new site from a description), when NOT to call again ('NEVER call create_site a second time for the same site: each call builds another one'), and which sibling to use next (get_build_status, with slug vs claim_token depending on auth state). It also states the guest and signed-in paths so the agent knows the call is valid without authentication.

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

All sitectrl toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources