Croisa

Define a generated-ID CMS collection for public website data. First reason about existing generated models with list_data_models or resolve_data_model. Reuse a collection when it is the right source of truth for the user's requested data; create a distinct collection when the user needs separate schema, lifecycle, audience, source of truth, or content scope. If this tool reports similar existing collections, retry with createIntent="confirmed_new_distinct_model" and createReason only when the new collection is genuinely distinct. Collections can back public forms (backendActions write target), public page rendering (dataBindings read binding), manual/agent-authored entries, or any combination — inspect describe_data_model usage for existing formWrite and read bindings before creating another model. Public form scalar targets must be nonlocalized string/richText/url/number/boolean. For uploads, use a nonlocalized asset field for one stable {assetId} reference or list with items.type="asset" for multiple values. Every asset field requires normalized assetPolicy: kinds image/video/file/audio, optional allowedMimeTypes and maxBytes, and exposure private (default) or publicWhenEntryVisible. The collection policy is an upper bound that a form action cannot broaden. Asset exposure, collection entry visibility, and page dataBindings are separate controls. displayName/description and field label/helpText are stored as localized UI metadata. Field objects require fieldKey and type. Supported types: string, richText, number, boolean, url, money, asset, image, video, object, list. Existing image/video fields remain compatible with src/url objects and may also carry managed assetId references. Never store S3 bucket/key data or public rendition URLs as an authored collection value; those resolve from the asset record. localized=true is allowed only on string/richText. For object/list values, put localized=true only on nested string/richText leaves. Media fields cannot be localized; use localized sibling fields for alt/caption/title. Templates must use stable fieldKey/schema paths, never labels/helpText.

Define a generated-ID CMS singleton for one-off public website data. First reason about existing generated models with list_data_models or resolve_data_model. Reuse a singleton when it is the right source of truth for the user's requested data; create a distinct singleton when the user needs separate schema, lifecycle, audience, source of truth, or content scope. If this tool reports similar existing singletons, retry with createIntent="confirmed_new_distinct_model" and createReason only when the new singleton is genuinely distinct. displayName/description and field label/helpText are stored as localized UI metadata for the provided locale, then flattened in tool/API responses. Field objects require fieldKey and type. fieldKey must start with a letter or underscore and use only letters, numbers, and underscores. Supported types: string, richText, number, boolean, url, money, image, video, object, list. Use string for normal text. Use richText when the content value itself needs limited formatting, inline links, or markup that must translate as one unit; richText is sanitized on read and should render with standard Handlebars triple braces only when HTML output is intended. Use url for href/link fields; values may be external URLs or internal Croisa page tokens like page:<pageId>. URL/page tokens are resolved on read and must not set localized=true; pair url fields with localized string/richText labels when link text changes by locale. Use money values as {amountMinor, currency}; image/video values as objects with src or url. localized=true means auto-translate and is allowed only on string/richText fields. For object/list values, define nested fields/items and put localized=true only on nested string/richText leaf fields. Media fields cannot be localized; use localized sibling fields for alt/caption/title. Templates must use stable fieldKey/schema paths, never labels/helpText.

Use this tool to retrieve the full HTML/CSS/JS payload, dataBindings, and backendActions for a specific `CustomSection` on the current page. Pass the same `websiteId`, `pageId`, and `locale` you used with preview_website_page, and provide `componentId` exactly as it appears in the section's `config.id`. After reviewing the payload, edit source with `patch_custom_section_code(...)` and edit description/dataBindings/backendActions with `edit_preview_page`. Form-backed sections expose backendActions and target.collectionId; read submitted rows with query_data_entries(collectionId, includeHidden=true). The response includes per-field hashes; pass the relevant hash back as `expectedHash` so stale edits fail safely instead of overwriting newer changes.

Describe one generated CMS collection or singleton by dataId. Returns schema fields, template fields, allowed operations, counts, and CustomSection dataBinding references so agents can safely decide whether to edit values, add optional fields, reorder entries, or update templates. References are published-only unless currentPageId and currentLocale are passed; with both, results also include actual draft references plus effective current-page references for the scoped editing surface.

Describe the declarative wallet pass template capabilities, supported pass categories, and platform rules.

Use this tool to inspect the allowed configuration knobs for any schema-driven component (Hero, Navbar, Services, etc.). Call it silently before editing `/meta/pageSchema/.../config/variantConfig/*` so you know the valid enum strings, boolean switches, and numeric ranges the frontend accepts. Pass the `componentName` exactly as it appears in the `preview_website_page` response (the `/meta/pageSchema/sections[].component` string, e.g., `"Navbar"`). Likewise, use the variant literal from `/meta/pageSchema/sections[].config.variant` if you pass `variantName`. Schema-driven components are intentionally bounded: their configs are the only supported way to influence layout, spacing, typography, and micro-interactions. Many components inherit color/typography from the global business theme, while others expose local style/color controls. Treat the returned `fields` as the source of truth for what this variant supports. Use the component knobs (and alternate variants) to hit the user’s requested look first, but if the request clearly calls for brand-wide palette or font changes, adjust `/business/theme/...` via `describe_theme_presets()` instead of forcing ad-hoc styling. Always try to satisfy the user’s request via these knobs first—iterate with them, tweak fields, or even switch to another built-in variant if it better expresses their intent and is available. Only when you’ve exhausted the available variants/fields and the user still needs something fundamentally different should you offer to replace (or augment) the section with a `CustomSection`, which gives full HTML/CSS control. - When you already know the user wants to tweak the variant currently rendered in `pageSchema`, pass its exact `variantName` so you immediately get the knobs for that variant. - If the user hints at a bigger layout/style change (or you simply want to explore alternatives), omit `variantName` (or pass a different one) to inspect the other options surfaced in `availableVariants`. Use the returned list to decide whether to switch variants or stick with the current one and adjust its fields. Typical flow: 1. Identify the component type you need to adjust (e.g., componentName `"Navbar"` with variant `"DynamicNavbar"`). 2. Call `describe_static_component_presets(componentName, variantName)` to inspect that variant’s knobs, or omit `variantName` to browse the other variants listed in `availableVariants`. 3. Review the `fields` array to see each field's allowed values and whether it is required. 4. Apply the change via `edit_preview_page`, targeting `/meta/pageSchema/.../config/variantConfig/<field>`.

Use this tool for theme editing decisions. Use this silently before changing `/business/theme/...` to match user intent. When a user requests stylistic website changes (e.g., "make it more serious," "I want something playful," "warmer colors"), call this tool to review the palette and font options. Base your decision primarily on the `primaryHsl`, `secondaryHsl`, and `accentHsl` triplets—use hue to judge warmth/coolness, saturation for intensity, and lightness for how bright or moody the palette will feel. Treat the preset `name` as an identifier, not a style guarantee. Font pairings are returned as strings in the format `display_font_name-body_font_name` (e.g., `libre_baskerville-source_sans_3`); so you can align typography with the user's request based on your knowledge of the fonts available. You do not need to show the user this list or ask them to pick—just use your judgment to select the preset that fits their request, then apply it via `edit_preview_page` by replacing any/all of these as needed: - `/business/theme/colorPairingId`: Use a preset ID OR set to `"custom"` and provide `customPairing`. - `/business/theme/fontPairingId` - `/business/theme/borderStyle` - `/business/theme/customPairing`: Required if colorPairingId is "custom". Must be `{ "primaryHsl": "0 0% 0%", "secondaryHsl": "...", "accentHsl": "..." }`. The user will see the result in the live preview and can refine/publish from there with you in the conversation. Example workflow: - User: "I want my website to look more serious" - You: Call preview_website_page if not already called/in-context of current conversation to load the page draft and see the current theme - You: Call `describe_theme_presets()` → notice `cool-grays` has cooler, lower-saturation HSL values (`210 22% 49%`, `213 27% 35%`) and the `libre_baskerville-source_sans_3` pairing is a balanced serif/sans combo suitable for professional brands - You: Patch `/business/theme/colorPairingId` to "cool-grays" and `/business/theme/fontPairingId` to "libre_baskerville-source_sans_3" - User sees the preview and can request further tweaks if needed The user can also request specific colors in which case you can use them to patch `/business/theme/customPairing` as needed.

Use this tool to make edits to EXISTING content on a website page. Changes persist in draft state and display live to users. After edits, ask if user wants to publish (publish_preview_changes) or continue editing. The platform is based on a modular approach consisting of config controlled and custom (html,css,js) components. For new AI-built sections that need editable repeatable or singleton data, use generic data tools plus CustomSection dataBindings. For public forms that collect visitor input, persist to a collection via CustomSection backendActions (formSubmission) — inspect existing collections first with list_data_models or resolve_data_model; do not assume a new collection is needed. Keep the three publication controls separate: submissionPolicy controls whether new entries are moderated or automatically visible, assetPolicy.exposure controls whether eligible bytes may receive a public rendition when an entry is visible, and dataBindings independently control whether any page reads that collection. autoPublish never creates or chooses a page. USER CONTEXT: Assume a busy, non-technical user unless stated otherwise. You're the expert—apply sensible changes for vague requests, explain your reasoning, and iterate as needed. MANDATORY TECHNICAL GUIDELINES: - LOCALE COPY RULE: Author user-facing copy in the specified locale. Separate supported locales represent localized versions; do not combine languages within one locale unless the user explicitly requests bilingual or mixed-language copy. - LOCALE PROPAGATION RULE: Treat this as authoring in ONE working locale only. For normal content and structural edits (copy, SEO, sections, pageSchema, business data), edit only the current locale draft. Do NOT duplicate the same change across other locales as the platform handles localization/propagation after publish. Separate per-locale edits are only for explicit locale-specific overrides requested by the user, or for localizedUrlSlug edits which are always locale-scoped. - NEW CUSTOM SECTIONS: Use create_custom_section() to add new sections with HTML/CSS. - Internal page navigation links MUST use `page:<pageId>` href tokens (example: `page:page-1772128355479`). Do NOT hardcode locale/slug paths like `/services` or `/es/servicios`. - URL EXPLANATIONS: Each locale has its own slug; do not tell users the platform auto-adds /es/ or removes /en/. Prefer plain paths (/welcome, /bienvenido). Slug patches apply only to the current locale—use preview_website_page for another locale before quoting or editing its URL. - NESTED SLUGS: Slash-separated paths are supported (services/consulting stays nested). - Theme changes: call describe_theme_presets() FIRST, then patch /business/theme/* - Site favicon: patch `/business/faviconImage/src` with the uploaded image URL; use an empty string to clear it. This is sitewide, while `/meta/pageSchema/socialImage/src` is per-page. Changes stay in draft until publish_preview_changes. - Component configs: call describe_static_component_presets() BEFORE patching /meta/pageSchema/.../config/variantConfig/* - CustomSection edits: html/css/js source edits are blocked here; call describe_custom_component() first, then patch_custom_section_code() for source changes. edit_preview_page supports CustomSection description/dataBindings/backendActions edits plus structural move/remove/reorder operations. For dataBindings, use generated collection/singleton/entry IDs and data.alias... template paths. For backendActions, use kind="formSubmission", purpose for the business intent, required target={collectionId:"col_..."}, and submissionPolicy="moderated" (default) or "autoPublish". Asset-backed fields use type asset/image/video/file/audio and an assetPolicy that cannot broaden the target collection asset policy; maxBytes cannot exceed 5 GiB. Uploads are private by default and collection values carry stable assetId references, never S3 keys. The declaration is the server-enforced contract; the section owns 100% of the form UX. Submit from the section JS with croisa.submitAction("<actionId>", { form }) (or { fields }), which uploads files first and then submits asset references. Render your own loading/success/error states from SECTION_COPY. Do NOT write a raw fetch. publish_preview_changes before live public submission works. Read stored submissions with query_data_entries(target.collectionId, includeHidden=true), and use review_form_asset(websiteId, assetId) to inspect private uploads in chat before approving an entry. I18N RULE: Never hardcode dynamic text in JS; put translatable text in HTML data-* attrs with copy tokens, or read SECTION_COPY/SECTION_DATA/SECTION_RUNTIME in JS. - Section structure: Whole-section move/remove/reorder targets /meta/pageSchema/sections/{index} (page body), /meta/pageSchema/layout/beforeChildren/{index} (header), or /meta/pageSchema/layout/afterChildren/{index} (footer). This is separate from copy/config field edits. For reordering, prefer move (e.g. {"op":"move","from":"/meta/pageSchema/sections/0","path":"/meta/pageSchema/sections/1"}) over replace — it preserves the full section object, including CustomSection html/css/js, without re-fetching it. Nested field move/copy is rejected; duplicate sections with create_custom_section(), not copy ops. On pages with layoutSource="sitewide", set layoutEditScope before moving/removing header/footer sections or editing layout-owned /page/copy/* (navbar, footer, etc.). - Business address updates: `/business/formattedAddress` is a special validated path. Send it as a standalone single-operation patch only. Do NOT patch `/business/addressComponents`, `/business/lat`, `/business/lng`, `/business/location`, or `/business/googleMapsUrl` directly; those are managed by the validated address flow. Do NOT patch `/business/placeId` or `/business/googlePlaceId` directly either; those are internal read-only identifiers, not normal address-edit fields. - Immediate business fields: `/business/phone`, `/business/openingHours`, `/business/showHours`, and `/business/timeFormat` are applied immediately to live business metadata. Send those `/business/*` edits as a standalone request only, and do not expect `publish_preview_changes()` to apply them later from draft state. - Business phone updates: `/business/phone` must include an international country code (for example `+1 555 123 4567`). If the user gives a local-only phone number, ask for the country code before calling this tool. - GBP-linked clear confirmation: if clearing `/business/formattedAddress`, `/business/phone`, or `/business/openingHours` for a site linked to Google Business Profile, first tell the user this will save locally and attempt to clear the same value on Google too. Only retry with `confirmGbpClear=true` after the user confirms. - Hours edits (business.openingHours): • Schema: array of periods {open: {day: 0-6, time: "HHMM"}, close?: {day: 0-6, time: "HHMM"}}. • Closed day: omit periods for that day. Entirely closed: use []. • 24/7: single period with open day=0, time="0000" and no close. • Split/overnight: multiple periods allowed; use next-day close for overnight (e.g., open day=2 time="1600", close day=3 time="0100"). • Do not remove openingHours; use [] instead. Empty strings are invalid; times must be 4-digit HHMM. Response includes _draftStatus, _draftTouchedPaths, _draftCurrentVersion for state tracking. Layout ownership: Pages can use a sitewide layout (`pageSchema.layoutSource="sitewide"`) or a page-local layout (`"page"`). `layoutSource` is a strict contract: only `"sitewide"` and `"page"` are valid; values like `"website"` are invalid and will be rejected. When editing layout-owned paths on a sitewide page, set: - layoutEditScope='sitewide' to edit the shared sitewide layout - layoutEditScope='detach' to fork the current effective layout into this page first - layoutEditScope='auto' (default) rejects ambiguous layout edits

Find CustomSection dataBindings that reference generated CMS data. Use before hiding a directly bound entry or changing a model schema. For an entry, pass collectionId and entryId. For a model, pass dataId or collectionId/singletonId. References are published-only unless currentPageId and currentLocale are passed; with both, results also include actual draft references plus effective current-page references for the scoped editing surface.

Generate a private visitor preview link for a private website. It supports normal visitor interactions, including forms, but does not grant editing or ownership.

Read one generated CMS collection entry. Defaults to visible entries; pass includeHidden=true to read a hidden entry for restore/edit flows or to inspect unpublished form submissions. item is the locale-resolved render shape exposed to CustomSection templates and may include provenance {source, actionId, purpose, submittedLocale} for form-created rows. editableItem is the authoring shape for patch_data_entry: fieldKey values only, page links still stored as page:<pageId>, and no computed fields. missingOptionalFields lists optional dotted schema paths absent from editableItem; convert them to JSON Pointer paths before initializing with JSON Patch add operations, e.g. details.caption -> /details/caption.

Read a generated CMS singleton. item is the locale-resolved render shape exposed to CustomSection templates, including resolved page links and computed display helpers such as money.formatted. editableItem is the authoring shape for patch_data_singleton: fieldKey values only, page links still stored as page:<pageId>, and no computed fields. missingOptionalFields lists optional dotted schema paths absent from editableItem; convert them to JSON Pointer paths before initializing with JSON Patch add operations, e.g. details.caption -> /details/caption. Use baseRevision with patch_data_singleton to avoid stale writes.

Read the selected website's merchant payment (Stripe Connect) and customer membership program setup.

Get a declarative pass template by ID with locale scaffolding and missing translation paths.

Hide one collection entry from public collection rendering. Use for user requests like remove/take down/hide this card/team member/product. This is reversible with show_data_entry and does not delete content. If the entry is directly bound by a CustomSection, the tool blocks unless force=true and returns affected references. If this returns a baseRevision mismatch, call get_data_entry for the same entry and retry with the fresh baseRevision before reporting success.

Import a public web page from an external URL into an existing Croisa page. Captures the rendered DOM and CSS in a real browser, stores it as one imported CustomSection, replaces the target page body, and detaches the page from the shared sitewide layout so imported header/footer visuals do not affect other pages. Use for "mirror this URL onto this page" requests after choosing the target website, existing pageId, and locale. The result is a fidelity-first visual snapshot that can later be edited like any CustomSection; read structuredContent._considerations (and _detectedForms when present) for snapshot-specific follow-up discovered during import. For language-sensitive migrations, call capture_page_reference first when the user has not specified the target locale; if the source language is not enabled, use manage_languages before importing.

Inspect a public URL so the agent can understand an external resource. Use this before rebuilding, copying, comparing, or referencing external pages, images, PDFs, or text resources. The tool returns MCP content blocks for model-visible data, including image content when the URL is an image small enough to return directly.

Use this tool to list all pages for a website. Returns a flat, agent-friendly canonical page index with localized variants and preview args.

List generated CMS collections and singletons for a website. Use this when deciding whether to reuse, edit, bind, or create data models. Results include human displayName/description next to generated IDs, visible/hidden entry counts, template fields, and CustomSection usage summaries so agents can reason about the right source of truth. Usage is published-only unless currentPageId and currentLocale are passed; with both, results also include actual draft references plus effective current-page references for the scoped editing surface. Call describe_data_model for full schema and reference details.

Use this tool to inspect draft history for undo/redo planning. By default (`scope='auto'`) it returns merged action history across the page, shared-layout, and website-settings streams. Pass `scope='page'`, `scope='sitewide'`, or `scope='website'` to inspect one raw history stream directly. This tool returns metadata only (not renderable page content), so bare error responses are acceptable.

List membership purchases or incomplete checkouts for one program. Do not merge records by person; memberCount is the page's record count.

List recent customer redemptions for one owned membership program.

List all declarative pass templates authored for this website.

Use this tool to access up to 100 websites owned by a user. This is the entry point to the platform tools as most operations require a websiteId to be selected first. Supports optional pagination: provide `limit` (<=100) and a base64-encoded `lastEvaluatedKey` to continue when `hasMore` is true.

Business and menu websites only (siteMode business, menu, or grandfathered records without siteMode). Opens the built-in Carousel/Gallery management UI for template-flow sites; blocked on siteMode=custom agent-built sites which have no legacy gallery CMS store. This does not let you directly upload/remove/reorder images in chat—it opens the human management UI. Use when the user asks to manage images in an existing visible built-in Carousel/Gallery component on a business/menu site. For custom sites or new AI-built galleries, use generic data tools plus CustomSection dataBindings instead. Use for upload/remove/reorder of carousel or gallery images (not hero/about/etc.), large reusable photo sets, or when the user points at the legacy gallery section. IMPORTANT: NOT for replacing a single page-level image (hero, about, etc.)—use request_image_upload for a given contentId instead.

Use this when the user wants to manage the domains of a website: connect a custom domain, configure DNS or SSL, verify domain ownership, or rename the included Croisa website address. Returns a navigation-only UI widget that opens the domain management page on croisa.com; the user completes all changes on that page. DOMAIN MANAGEMENT OPERATIONS (on croisa.com via the opened page): - Add custom domain to route traffic to the website - Remove custom domain from the website - Update domain DNS records and settings - Verify domain ownership - Manage SSL/TLS certificates for domains - Configure domain forwarding and redirects - Rename the included/free vanity website address Workflow: 1. Call list_websites() to select a website if none selected yet 2. Call manage_domains(websiteId, locale) to display the UI 3. User interacts with the UI widget to manage domains 4. Domain changes are saved through the UI interface

Use this to display an interactive UI widget which allows the user to add new languages to their website. When a new language is added, the platform automatically translates the homepage and sitewide layout. Other pages are not backfilled until edited/created and published.

Business and menu websites only (siteMode business, menu, or grandfathered records without siteMode). Opens the built-in customer reviews management UI for template-flow sites; blocked on siteMode=custom agent-built sites which have no Reviews CMS store. This does not let you directly create/update/delete reviews in chat—it opens the human management UI. Use when the user asks to CRUD review data in an existing visible built-in Reviews component on a business/menu site. For custom sites or new testimonial sections, use generic data tools plus CustomSection dataBindings instead.

Business and menu websites only (siteMode business, menu, or grandfathered records without siteMode). Opens the built-in Services/menu management UI. This does not let you directly create/update/delete services in chat—it opens the human management UI. Use when the user asks to CRUD service data in an existing visible built-in Services component or menu manager on a business/menu site. For custom sites or new AI-built catalog sections, use generic data tools plus CustomSection dataBindings instead. Use when user wants to add/edit/delete service items, update names/descriptions/prices, organize categories, or manage availability in the legacy Services/menu UI.

Move one collection entry before or after another entry. Use for ordering requests like put David first or move this service after that one. Ordering is collection-global, not localized, and hidden entries keep their place unless explicitly moved.

Move one schema field before/after another field in the same parent object/list. Schema paths use returned field paths like bio, hero.ctaLabel, or faqItems[].question. This changes schema/editor/template field order only; stored values are not rewritten.

Open Stripe payment settings for the selected website. Use this when the user asks to connect Stripe, continue onboarding, manage Stripe payments, or open their Stripe Dashboard. The modal adapts to the current account state: incomplete accounts continue Stripe-hosted onboarding, while ready accounts can open their full Stripe Dashboard.

Canonical source-edit tool for CustomSection `html`, `css`, and `js`. Call describe_custom_component(...) first to retrieve current source and hashes, then send one or more atomic edits. sectionCopy is flat and exposed as {{copy.key}}. New user-facing text must use normal copy tokens with matching /page/copy values. Copy values may contain supported links and formatting; the platform automatically normalizes rich copy in HTML text nodes, so special brace syntax is not required. Attribute tokens remain escaped. Do not hardcode translatable labels in HTML. Legacy flat and triple-brace templates remain compatible. For JavaScript, send real line breaks and keep translatable UI text in HTML data attributes. Backend forms must use declared backendActions and croisa.submitAction rather than raw fetch calls. Normalized edits that are byte-identical to the current source return a no-op without creating a draft version or touched path. In a multi-field batch, only fields whose final hashes changed are persisted. VIDEO HTML: type is not a <video> attribute and will be removed. For one unverified source, usually omit type. Preserve accurate type attributes on nested <source> elements when intentionally distinguishing multiple fallback formats. A container MIME such as video/quicktime does not verify codec compatibility. Allowed operations inside each edit: - replace_once: Requires {"op": "replace_once", "find": "string to find", "replace": "new string"}. - insert_before: Requires {"op": "insert_before", "find": "anchor string", "replace": "new string to insert"}. - insert_after: Requires {"op": "insert_after", "find": "anchor string", "replace": "new string to insert"}. - delete_once: Requires {"op": "delete_once", "find": "string to remove"}. - replace_field: Requires {"op": "replace_field", "replace": "the entire new content for the field"}. CRITICAL: For replace_once, insert_before, insert_after, and replace_field, use the key `replace` for the new content. All operations except replace_field require a `find` key to locate the target string. Example edits payload: [ { "field": "html", "expectedHash": "...", "operations": [ { "op": "replace_once", "find": "<h1>Old Title</h1>", "replace": "<h1>New Title</h1>" } ] } ] If your HTML introduces new {{tokens}}, update /page/copy/<componentId>/... via edit_preview_page before retrying. Hardcoded external http(s) image/asset URLs are non-blockingly lint-checked after save; prefer exact media URLs returned by request_image_upload or process_image, or call inspect_resource() before embedding third-party links. Do not manually transform image URLs for optimization, resizing, format conversion, or CDN variants; the platform automatically optimizes and caches supported raster images on the fly at render time.

Patch one generated CMS collection entry using RFC 6902 JSON Patch against get_data_entry.editableItem. The patch root is the entry's semantic item object, not query_data_entries.items and not data binding aliases; use fieldKey paths such as /bio, /price, or /faqs/1/answer. money/image/video fields are atomic object-shaped scalar fields, so replace the whole field instead of patching sub-properties such as /price/amountMinor. Pass baseRevision from get_data_entry/create_data_entry to prevent stale writes. Visibility is not patchable here; use hide_data_entry/show_data_entry. Pass includeHidden=true only when intentionally editing a hidden entry.

Patch a generated CMS singleton using RFC 6902 JSON Patch against get_data_singleton.editableItem. The patch root is the singleton's semantic value object; use fieldKey paths such as /headline, /cta/href, or /faqs/1/answer. Pass baseRevision from get_data_singleton/set_data_singleton to prevent stale writes. remove is a logical deletion across localized values, and embedded list structure changes keep localized fragments aligned across locales.

Generate visual SVG card face previews for Apple Wallet and Google Wallet passes.

Use this tool to view a page before any edit/revert/publish operation happens in a conversation. This tool mounts the content you inspect into the user's real-time UI. It creates a saved working draft if none exists; it does not publish the page. User requests akin to "see", "open", or "change language" for a page you believe is already visible should be honored. Call this tool again to ensure the UI is synchronized, as it may be out of sync with your view. Do not refuse, as this tool is idempotent. Unlike write tools where you should avoid duplication, this tool is safe to call repeatedly to refresh the UI and data. WORKFLOW: 1. preview_website_page() - Load page and check draft status (clean=synced, dirty=has unpublished edits) 2. edit_preview_page() - Apply edits via JSON Patch (see its docstring for what's editable vs what needs management tools) 3. revert_preview_page_version() / redo_preview_page_version() / list_draft_versions() - Navigate ordered draft history (merged page + shared actions on sitewide pages) 4. publish_preview_changes() - Push draft to production and trigger translations RETURNED DATA: - structuredContent: Page data organized by /page, /meta, /business - _draftStatus: 'clean' or 'dirty' - indicates if there are unpublished changes - _draftTouchedPaths: List of modified paths since last publish - _draftCurrentVersion, _draftCurrentVersionNumber, _draftLatestVersionNumber: Version tracking

Use this tool to publish the current draft for a page to production. Typical workflow: 1. Call preview_website_page() to load or create the working draft 2. Apply one or more edit_preview_page() calls to modify copy, meta, or business data 3. Check that _draftStatus is 'dirty' (indicates unpublished changes) 4. When the user explicitly confirms they want the changes live, call publish_preview_changes() Important notes for the model: - ONLY call this when the user has clearly requested a publish/deploy action. Do not publish automatically after edits. - ALWAYS check _draftStatus before calling: should be 'dirty' (has unpublished changes). If 'clean', there's nothing to publish. - An existing live page can publish shared drafts even if it has no page draft yet; its clean page baseline is initialized from live content. - If _draftStatus is 'clean' and _draftTouchedPaths is empty, the tool will return a no-op response (nothing to publish). - Publishing marks the draft as clean, copies its data to the production items for the specified website/page/language, and triggers translation tasks for other locales if localized body/meta content changed. - If a localizedUrlSlug was claimed by another page/locale after the draft was edited, publish returns a slug conflict and leaves the draft dirty so you can choose a new slug and retry. - DEFAULT MULTILINGUAL RULE: For normal content and structure changes, author once in the active locale and publish once. Do NOT manually repeat the same edit/create flow across locales; the platform handles localization/propagation for you. - IMPORTANT: To protect SEO, publishing localizedUrlSlug changes NEVER automatically translates or propagates slugs to other locales. If a slug edit must be global, you MUST manually edit/publish the slug for each remaining locale. - For other content (copy, SEO meta, sections, page structure), do not manually repeat edit/publish per locale unless the user explicitly asks for locale-specific manual overrides; otherwise the platform handles this automatically. - The tool returns a success message plus metadata indicating whether translation follow-up is needed. Link to the published page when reporting success; primaryDomain is only the site's hostname, not a page-specific link. - When shareUrl is present, use it for a link that selects the visitor's browser language when a translation exists. To link to the exact published language, use the same URL without the croisa_lang=auto query parameter. These links show published content. - After publishing, additional edits require calling edit_preview_page again; the draft will start in a clean state. - Immediate business fields like `/business/phone`, `/business/openingHours`, `/business/showHours`, and `/business/timeFormat` are not published from draft state. They must already have been applied via the standalone immediate business edit flow. - Structured content includes `_draftStatus`, `_draftCurrentVersion`, and `_draftCurrentVersionNumber` to confirm the published state.

Read locale-resolved entries from a generated CMS collection by generated collectionId. Defaults to visible entries. Pass includeHidden=true to read hidden rows such as unpublished form submissions created by CustomSection backendActions; form-created items include provenance {source, actionId, purpose, submittedLocale} when present. Do not patch /items/0/... from this paginated result; select a specific entryId, call get_data_entry, then patch_data_entry against editableItem.

Use this tool to step forward to the next draft snapshot when the user requests a redo. Only call this after preview_website_page() has populated the draft. If no draft exists, reload it first. Always call list_draft_versions() first to satisfy the prerequisite check and avoid a no-op. The default list call returns merged page, shared-layout, and website-settings action history. Without `versionId`, the tool advances the pointer by one. Provide `versionId` to jump to a specific newer snapshot (e.g., one listed in structuredContent). If the pointer is already at the latest version, report that there is nothing to redo. Structured content includes `_draftStatus`, `_draftTouchedPaths`, `_draftCurrentVersion`, `_draftCurrentVersionNumber`, and `_draftLatestVersionNumber` for planning follow-up actions.