Skip to main content
Glama

Create an event website (organizers only)

site_create
Idempotent

Serves "Build a site for ", "make an event website" and "start a site from " (the url gives layout only), not the host's own page tools. Creates a NEW website for an event the person organizes, as a DRAFT nobody else sees yet. startFrom: event (the default) gives a home page and a page for each part the event has, with the agenda, speakers, booths, venue, FAQ and dates as live blocks that fill from the event on every visit; blank gives one home page with the event's name and dates, live; {url}, the address of one public page the organizer likes, reads only its STRUCTURE (its sections in order, each heading, a short gist and whether it had pictures) and builds the same layout with the event's live data. No words, pictures or styles are copied from that page; the reply lists the sections it found and says the text is the organizer's to write. title names the site. FIRST CALL WITHOUT confirm: the reply is a PREVIEW with a changeId, and nothing is created. Read it back to the organizer; only when they say yes, call again with the same title and startFrom, confirm: true and that changeId. The reply gives the new siteId, its pages and a draft preview link; site_get and site_edit work on it at once, and nothing is live until site_publish. An event holds at most 20 sites. Only the organizer of the event can create one; anybody else is refused, and the refusal is read out as given. It needs a personal connector token. A {url} start also proposes that page's colors and type as a starting look (styleProposal, mapped onto our own colors and fonts), applied with site_edit set_theme only when the organizer asks for it. Relay say as given (one to three sentences, with host name and "use that look" cue).

Input Schema

NameRequiredDescriptionDefault
titleNoOptional site name.
confirmNoAbsent previews only; true creates the previewed site.
changeIdNoThe preview id; required with confirm.
startFromNoOptional: event (default), blank, or {url}.
eventIdOrNameYesThe event id or name as the organizer spells it.

Output Schema

NameRequiredDescriptionDefault
okNo
codeNo
nameNo
errorNo
pagesNo
siteIdNo
appliedNo
messageNo
outlineNo
previewNo
changeIdNo
servedByNo
duplicateNo
startFromNo
structureNo
builderLinkNo
styleProposalNo
draftPreviewLinkNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / changeId / description
      Previous value: -"The id of a preview; required when confirm is true."New value: +"The preview id; required with confirm."
    • changedInput schema / properties / confirm / description
      Previous value: -"True creates a previewed site; absent, the site is only previewed and nothing is created."New value: +"Absent previews only; true creates the previewed site."
    • changedInput schema / properties / eventIdOrName / description
      Previous value: -"The event id or the event name as the organizer spells it."New value: +"The event id or name as the organizer spells it."
    • changedInput schema / properties / startFrom / description
      Previous value: -"OPTIONAL. event (the default): a page for each part the event has, every fact live; blank: one home page; {url}: the layout of that public page, rebuilt with the event's live data."New value: +"Optional: event (default), blank, or {url}."
    • changedInput schema / properties / title / description
      Previous value: -"OPTIONAL. The new site's name, plain words."New value: +"Optional site name."
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare non-read-only, idempotent, open-world, non-destructive, but the description goes well beyond: the two-call preview/confirm protocol with changeId, the 20-site-per-event cap, the personal connector token requirement, and the organizer-only refusal behavior. It also discloses that no text, images or styles are copied from a source url — a genuinely non-obvious behavioral trait.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Intent-matching phrases are front-loaded, which is good, but the body is a dense run-on with nested backticks and long comma-spliced sentences that hurt scanability. Most content earns its place, yet it could be split into clear bullets for the flow, limits and auth.

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 mutating, open-world tool with an output schema, the description still covers the full lifecycle an agent needs: preview before mutation, required confirm/changeId, immediate availability to site_get/site_edit, draft-until-publish status, quotas and authorization. Nothing needed to call it correctly is missing.

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 100%, so the baseline is 3, but the description substantially enriches startFrom (what event/blank/{url} actually produce, including live blocks vs. structure-only extraction) and explains the confirm/changeId pairing beyond the schema's terse wording. Only `title` is left as a bare restatement ('names the site').

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 — creating a NEW event website as a draft — and explicitly separates it from adjacent tools ('not the host's own page tools', publishing handled by site_publish). The three startFrom modes are each defined, so an agent can tell exactly what this tool produces.

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?

Enumerates the phrasings that should trigger it ('build a site for <event>', 'start a site from <url>') and gives the decisional rule for picking a mode, including that url input is layout-only. It also states the alternative path (site_edit/site_publish) and the organizer-only precondition, leaving little to inference.

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