Sitelas

Stand up a new collection on an existing site in one call: append a `collections[]` entry (with `contentType`, `pathPrefix`, `template`, and optional `items[]`), optionally create the index page that hosts the matching `<collection-list>`, and seed initial items into the `content_items` table. After this call: - `/{path_prefix}/{slug}` resolves each item via Mustache substitution - the index page's `<collection-list>` iterates the seeded items - `add_content_item` / `edit_content_item` / `delete_content_item` manage rows afterward. Use this when the user asks 'add a blog to my site', 'set up case studies', 'add a careers section', etc. Schemas are per-site — pick a `contentType` slug that's unique within the site (call list_content_types to see what's already declared) and ship the `fields[]` schema inline. Writes a new draft version; call publish_site to push live.

create_collection

Permanently delete a site — its subdomain row, all version snapshots, all content_items, all submissions, the alias history, attached custom domains (removed from Vercel), any active billing for the site (cancelled), and any media in the storage bucket. IRREVERSIBLE. Use this when the user explicitly asks to scrap a site (e.g. 'delete my-portfolio-3947, I don't want it' or 'I created the wrong template, throw it away'). Requires `confirm: true` to be deliberate. Do NOT call this on user-said-something-vague — ask 'are you sure you want to delete {subdomain} permanently?' first and only call after explicit yes. There is no undo. If the billing cancellation fails, the entire delete is aborted so the user is never charged for a deleted site.

delete_site

Delete a content item by id. Ownership is verified via the parent site's user_id. Returns the deleted item's slug and content_type for confirmation.

delete_content_item

Delete a page from a site. Cannot delete the home page ('/'). By default also prunes nav-link entries (header / footer / pageLayout / page bodies) that point at the deleted slug so the deletion leaves no broken nav links — set prune_nav_links:false to keep them. A nav-link is kept (with a warning) if removing it would empty its nav-links container. Writes the change into the draft slot — call publish_site to push the deletion live. Returns the preview URL.

delete_page

Delete many nodes from a site in ONE call, batched into one new draft version. Locate each node_id across pages, siteElements and collection detail templates, and splice it out of its parent's children array. Use this for structural subtraction — dropping a testimonials section, removing a nav link, cutting one card from a grid, removing a header/footer column — whenever the brief calls for the template's layout minus something. Safe alternative to patch_fixture's JSON-Patch 'remove' ops for the same purpose: no hand-constructed paths, validated against the actual tree, and rejects root-node removal so you can't nuke a whole page. If a node id isn't found, the whole batch is rejected (fix and retry). Up to 50 removals per call.

remove_nodes

Compare two slots of the three-state snapshot model (live / draft / previous) and return a structured summary of what changed: pages added or removed, pages whose top-level section count changed (and by how much), whether the theme changed, and whether the shared header/footer changed. Common pairings: from=live to=draft (what would publish do), from=previous to=live (what did the last publish do).

get_version_diff

Returns the original form submission plus a structured reply template (subject, greeting, body, sign-off) for you to adapt into a tailored response. This tool composes a TEMPLATE only — it does not send anything. Use list_submissions to find the submission_id first. Read-only: it neither sends the reply nor marks the submission as read — read_submission is the tool that does that, which is exactly why that one is not read-only and this one is.

draft_reply_to_submission

Render a collection's DETAIL template against one specific draft item and return the resulting text + links + any problems — WITHOUT a browser and WITHOUT publishing. Use it right after add_content_item / editing a template to catch silent-success bugs before they go live: unresolved {{placeholders}}, and links that still contain braces. Complements get_site_tree (structure) and read_rendered_page (live SSR text). Read-only.

preview_collection_item

Clone an existing page to a new slug. Deep-copies the source page's full tree (regenerating every node id so the copy is independent) and creates a new page with the same nav group and enabled state. Use for 'clone the pricing page for a new tier' / 'make a second case-study page like this one'. The copy lands as a draft; edit it with patch_nodes and publish when ready. Fails if new_slug already exists or is reserved.

duplicate_page

Enqueue a DURABLE 'create this collection item (and take the site live)' job instead of writing it over this connection. Use this for UNATTENDED / scheduled runs (e.g. a daily auto-published blog post): a server-side worker performs the insert with retries + slug-idempotency, so a connector drop can't lose the post or double-post it. The payload is validated NOW (collection must exist, content must match the schema) so mistakes fail fast here rather than silently in the worker. Returns a job_id you can track with list_scheduled_jobs. For interactive edits you're watching, use add_content_item directly instead.

schedule_content_publish

Update fields on an existing content item. Identify it by `item_id`, OR — when you only know its name — by `site_id` + `content_type` + (`slug` | `title`); `title` resolves fuzzily (exact then contains) and errors with the available titles when there's no unique match. `patch` may include `content` (shallow-merged into existing content JSON), `slug` (rename), and/or `visibility`. At least one field is required. When `content` is patched, the MERGED result is validated against the content_type schema (lenient: required present + declared types; extra fields allowed) and rejected with paths if it would leave the item missing a required field. An `image`-typed field holds an OBJECT { "url": "…", "alt": "…" } — a bare URL string is accepted and stored as { url }. `content` is SHALLOW-merged, so patching an image field replaces the whole object: re-send `alt` alongside `url` or it is dropped. Ownership is verified via the parent site's user_id. Throws on slug collision.

edit_content_item

Explain the design choices of a site or a specific node. With node_id, returns layout role, color/typography choices, semantic intent, and related theme tokens. Without node_id, summarizes the site's overall design language. No LLM call and no writes — pure structural analysis, read-only.

explain_design

Search a curated stock photography library (Pexels) for real imagery to use in a site. Call this BEFORE composing any section that needs imagery — hero, feature-grid with visuals, testimonial cards with portraits, gallery sections, media-and-text sections. Returns large-size URLs, thumbnails, dimensions, average color, and suggested attribution. Chain with upload_image_from_url to persist the chosen image to the site's storage namespace (recommended — external URLs can rot). Be specific with queries; 'brooklyn bakery sourdough on wooden counter' returns much better results than 'bakery'. Rate-limited to 30 searches per minute per user. Read-only: it queries Pexels and returns results. Nothing reaches the site until you call upload_image_from_url with a URL from them.

find_images

Return complete example fixtures in the shape Sitelas expects — a Rosetta Stone for which fields are required vs optional, how responsiveStyle nests, what a real siteElements.header tree looks like, what shape data.items/data.tiers/etc actually take in practice. Study one for shape; compose your own for content. Pass minimal: true when you only need the structural skeleton (saves ~70-80% of token weight). The fastest path to a correct first call on an unfamiliar category is calling this once with that category, reading the skeleton, then composing from list_primitives + design principles — not avoiding examples on principle. The goal is never to replicate the reference; it's to get the shape right on call #1.

get_example_fixtures

Return the full prop schema for a single primitive: types, defaults, options, required fields, allowed children, and `styleStrip` — a map of {style prop: actionable hint} for any inline-style props this primitive's renderer intentionally drops (e.g. on `section`, layout props like `display`/`flexDirection` are stripped because Section is a semantic wrapper; use a Stack/Grid child instead). Read styleStrip BEFORE setting style on a node — eliminates the silent-drop trial-and-error.

get_primitive_schema

Fetch details of a single site: pages (slug/title/order/edit URL), theme summary, publish status, and URLs. Share `url` — it always resolves. `live_url` is null when the site has never been published: it has no public address yet, so say so and offer publish_site rather than handing over a link. Does NOT return the node tree (use get_site_tree) or version history (use list_site_versions). By default returns a slim theme (slug + palette tokens + font families) to keep the response compact; pass include_theme_config=true if you need the complete theme config object.

get_site

Fetch pageview and unique-visitor analytics for a site over a date range. Returns totals, a daily timeseries, top paths, and top referrers. Default range is trailing 28 days ending today. Use `range_days` for a trailing window, or `since` + `until` for explicit bounds.

get_analytics

Read the durable design brief for a site — vibe, category, brand voice, palette name, fonts, tagline, audience, the last 20 design decisions, AND a `design_system` block auto-extracted from the latest fixture (theme colors, typography pair, spacing scale, dominant section padding, icon density, section shape variety). Use this at the START of any editing session to recover context — it tells you what the site's design language already is so subsequent edits stay consistent. Returns has_brief=false when no brief has been saved yet.

get_site_brief

Compact diff between a named snapshot (live or previous) and the current draft. Lists added/removed pages, pages whose tree changed, and whether the theme or shared header/footer changed. Use this to summarize what's pending publish (since='live') or everything that's happened including the last publish (since='previous'), instead of dumping full snapshots.

get_site_changes_since

Fetch a single contact record for a site by email. Returns activity totals, tags, subscription status. Use `list_contact_activity` to get their interaction timeline.

get_contact

Abstracted site map — pages, collection items, theme tokens, per-page section types and headlines — without dumping the full primitive tree. Also reports PUBLISH STATE: the `publish` digest (is_live, shell state, per-kind live/edited/draft counts, has_unpublished_changes) plus a `state` ('live'|'edited'|'draft') on every page and collection item — use it to answer "what's live?" / "is anything unpublished?". SCOPE: this is the orientation + publish-state tool. Its `editable_nodes` is a capped, flat PREVIEW of text-bearing nodes — it does NOT show form fields, data-borne copy (accordion items, banner link labels, form success messages), collection items, detail-template copy, or slots, so it is the wrong surface for a copy pass: call get_site_manifest for that. For the full nested node tree (ids + nesting, minus props), call get_site_tree.

get_site_overview

Return a link to the site owner's own visual editor, optionally opening straight to one page or collection item. Give this to the person whenever the next step is theirs rather than yours: - They want to use THEIR OWN image. This is the dividing line for every image on the site, sections and collection items alike: you source pictures with `find_images`, `replace_images_from_search` and `upload_image_from_url` and place them yourself, but a file that exists only on their device — their logo, their team photo, their product shots — comes in through the editor. Point them at the exact page or item (`page_slug` takes 'blog/my-post' as happily as 'about') rather than the site root. - They want to make a change themselves, or asked where to edit something. - They asked to see their site, or seem unaware there is a visual builder at all — many people who connect this connector never find out. The link opens their editor signed in as them. Do not promise they are already signed in: the session cookie may not exist on the device they open it from, in which case they are sent to sign in first and land in the editor afterwards. `share_with_user` is worded for that. This returns nothing secret — it is an ordinary product URL, authenticated by the person's own account. Safe to paste into the conversation.

get_editor_link

Insert a bespoke node subtree (provided as a JSON string) under an existing parent, as one new draft version. The editor-chat escape hatch for structure that add_section's flat archetypes can't express — layered hero stacks, two-tone headline row-stacks, asymmetric columns, custom nesting. Runs the same validation as insert_nodes (unique ids, primitive data-shape, parent must accept children) and rejects without saving if the subtree is malformed. For standard sections, use add_section instead — it's simpler and less error-prone. Use list_primitives + get_primitive_schema to shape node data correctly.

insert_tree

Return EXACTLY what you can interpolate in a collection's row/detail template ({{…}} placeholders): every declared content field PLUS the auto-exposed route tokens `{{slug}}` (the item's slug) and `{{url}}` (the full detail path, pathPrefix + slug). Call this before writing a collection template so you don't guess a token that silently resolves to empty — the classic dead-link bug is writing href="/blog/{{slug}}" without knowing slug is a valid token. Read-only.

get_collection_tokens

List the images in a site's library, newest first, with their public URLs. Two main uses: collecting what arrived after you sent someone to the editor with `get_editor_link` (pass `since` with the moment you sent it, then place the results with `patch_nodes`), and checking what a site already has before uploading something it may already hold. Returns storage paths and byte sizes alongside the URLs. Place what you find with `patch_nodes`, never `patch_fixture` or `update_site_from_fixture`. If the image arrived because you sent someone a `get_editor_link`, they may still be in the editor right now; the full-replace tools overwrite the entire draft with no conflict check and would discard their work silently. `patch_nodes` re-applies onto concurrent edits instead.

list_site_images

Chronological list of a contact's interactions with the site — form submissions they made, newsletter subscribe/unsubscribe events. Most recent first. Useful for 'tell me everything we know about Sarah'.

list_contact_activity

List content items (e.g. blog posts, projects) for a site filtered by content_type slug. Optionally filter by visibility ('public' | 'private' | 'all'; default 'all'), with limit/offset paging. Returns each item's id, slug, full content JSON, visibility, and timestamps. Use add_content_item / edit_content_item / delete_content_item to mutate the collection.

list_content_items

List every content collection declared on a site, with its per-item field schema (`fields[]`). Schemas are per-site — there is no platform-wide catalog. Each entry includes the collection's `contentType` slug, its `pathPrefix`, whether it's enabled, and the typed `fields[]` (each with `key`, `type`, optional `required`, `label`, `description`, `options` for select fields), PLUS `observed_fields` — keys that actually appear on the collection's items but aren't in the declared schema (the schema is open, so include these when adding an item so it matches the existing ones). Call this before `add_content_item` to discover which fields a collection supports — or before `create_collection` to confirm a contentType isn't already taken. WHAT EACH `type` HOLDS, because the name does not say: text / textarea / rich-text (HTML) / url / date / select -> string; number -> number; boolean -> boolean; tags -> string[]; **image -> an object { "url": "…", "alt": "…" }, NOT a bare string** (a plain URL is accepted on write and stored as { url }; send `alt` when you have it). That last one is the one that gets guessed wrong.

list_content_types

List custom domains attached to a Sitelas site. Each entry includes the hostname, whether DNS verification has succeeded, the verification token (when one exists), and when the domain was attached. Use `set_custom_domain` to attach a new domain and `verify_custom_domain` to re-check verification.

list_custom_domains

List form submissions for a site. Returns summaries (name, email, form_type, `source` — which page/form the submission came from, e.g. a specific job position — is_read, preview of message, and `attachments` — any uploaded files as {field, name, url} with DURABLE download links safe to paste into an exported Google Sheet / CSV) plus a `lifetime_counter` block (used / limit / over_limit / locked / plan). The allowance is LIFETIME, not monthly, and nothing resets. Capture is NEVER gated on any plan: every submission is stored and forwarded to the site's webhook regardless of the count. What the allowance controls is READING. On Free, submissions past the allowance come back with `locked: true` — created_at and form_type only, with name, email, description and attachments withheld; say plainly that the submission arrived and was kept. Do NOT imply anything was lost or dropped, and do not pitch a plan change on the back of it, and do not try to recover a locked submission through read_submission, draft_reply_to_submission or the contact tools — they withhold it too. Pro never locks. Filter by form_type, unread_only, or since-timestamp. `form_type` is free-form text set by whoever built the form — the built-in presets are contact, waitlist, newsletter, rsvp, quote, application and custom, but templates ship their own (e.g. booking, tour-request, commission-enquiry), so read the form_type values off an unfiltered call before filtering on one. Use `read_submission` to fetch the full payload of one.

list_submissions

Return every primitive available in the Sitelas renderer plus tree-level constraints. Each primitive entry includes `style_strip` (when present) — a map of style props the primitive's renderer intentionally drops, paired with the actionable alternative. Response also surfaces `max_tree_depth` — the nesting ceiling the tree-validator enforces (children deeper than this are truncated). Read this BEFORE composing fixtures; saves trial-and-error from setting layout props on a Section that strips them, or from nesting too deeply for a bento layout. For full prop schemas, call get_primitive_schema(type) on a specific type.

list_primitives

List scheduled jobs for a site. Filter by status (pending/running/done/failed/cancelled), kind, or run_at range. Defaults to every job ordered by run_at ascending (next up first).

list_scheduled_jobs

Return section archetypes (hero, menu-grid, testimonials, contact-cta, etc.) recommended for a given site category. Each archetype includes when to use it and a description you can adapt when composing a Fixture.

list_section_archetypes

List contacts who have interacted with a site (filled a form, subscribed to newsletter). Filter by text, tags, or activity thresholds (min_submissions, subscribed_only, since). Ordered by most recent activity.

list_contacts

Three-state snapshot model: returns the live slot (currently published), the draft slot (current working copy), and the previous-live slot (one-step undo target, if any). Use revert_site to roll back to the previous-live snapshot.

list_site_versions

List all websites owned by the current user. Returns subdomain, publish status, plan tier, creation date, and URLs for each. Share `url` — it always resolves. `live_url` is null for a site that has never been published: that site has no public address yet, so say so and offer publish_site rather than handing over a link. Use get_site for per-site detail.

list_sites

Capture a JPEG when the question is genuinely VISUAL — layout, spacing, hierarchy, whether the hero reads as designed, whether the mobile breakpoint collapses cleanly (pass viewport). Returns the page's `text` and `title` alongside the image, fetched concurrently at no extra wall-clock, so you get what the page SAYS as well as how it LOOKS from one call — READ that text, because leftover template copy is the most common way a site ships wrong and it is invisible in an image. Still runs a real browser at ~5s, so when the question is only about wording prefer read_rendered_page at ~357ms. Always captures via the preview URL (preview-{slug}.{rootDomain}), which renders the current draft (or 302s to live when in sync). Read-only.

screenshot_page

Build a sitemap.xml from a site's currently published version. Walks enabled pages and emits one <url> entry per page using the site's live URL (custom domain when verified, otherwise the *.sitelas subdomain). Returns the raw XML plus a parsed entries array. Read-only — does not mutate the site. Sitelas may already auto-serve a sitemap; use this tool to inspect or copy the generated XML.

generate_sitemap

Set SEO metadata for a site or a specific page. Per-page mode (with `page_slug`) writes into the page's `metadata.seo` and ships as a new draft version — call `publish_site` to push live. Site-wide mode (no `page_slug`) writes into `subdomains.metadata.seo` and applies immediately to pages that don't set their own values. Supported fields: title, description, og_image_url, robots (index|noindex).

update_seo

Score every available template against a parsed brief and return the top matches with reasoning. Call this BEFORE create_site_from_template when the user has a real brief — it picks the best archetype using structured metadata (audience, register, conversion goal, integrations) instead of prose-matching. The output explains WHY each template ranked where it did so you can confidently pick the top result. CHECK `match_quality` before trusting the winner: 'corroborated' means the brief's own words appear in that template's useCases; 'structural' means it won on audience/conversion taxonomy alone and NONE of the brief's keywords appeared in its useCases (a top-level `advisory` says so, and score_pct is capped at 60 to stop an unverified neighbour reading as a designed fit). Structural means uncorroborated, NOT unsuitable — useCases list examples rather than every trade, so read the winner's brief before judging it. Usually still create from it, and tell the user it is a starting point and push harder on brand_overrides, imagery and copy. Pass `keywords` whenever you can: corroboration is computed from them, and without them every match reports as corroborated by default. Use list_site_templates instead when the user is browsing without a clear brief, or when they ask 'what other options are there.' Read-only: it scores and ranks, and creates nothing — create_site_from_template is what actually persists a site.

select_template_for_brief