Get the INTAKE questionnaire + build flow to run BEFORE creating a new site/store/page. Call this at the start of any fresh build: ask the user this one short batch (plain words, with defaults), restate the plan, get a yes, THEN build. Skip only for tiny edits, data questions, or when the user already gave the brief / says 'just do it'.

Show current connection context: which site_id, API URL, session, and account info. Call this first to confirm you're working on the right site

List all sites accessible by the current account. Use this to find a site_id before switching

Create a brand-new storefront site for the current account, then (by default) switch to it and return an EMPTY, CLEAN site (no sample products/categories) ready for element composition. The backend auto-seeds off-theme sample products + categories (and a sample blog); by default this tool DELETES that seed right after creating the site (keep the non-deletable default "All" category) so you start from a blank, on-theme store. Pass keep_seed:true to keep the sample data. The site has NO pages — after this, compose a homepage from elements: get_build_guide → new_section/new_element → build_page (type:'main', is_homepage:true). Note: free accounts are limited to 4 sites (creation fails with a quota error past that).

Switch to a different site by site_id. All subsequent tool calls will target the new site. The choice is saved to local database — next session will auto-connect to this site. Use list_my_sites first to find the site_id

Update authentication credentials. All values are saved to local database — next session auto-restores them. Get token and session_id from browser DevTools → Network tab → copy from any API request headers

Toggle update confirmation mode. Controls whether update tools ask for user confirmation before saving.

• "always_confirm" (default): Shows diff first, requires user approval before saving. Safer.

• "auto_apply": Applies changes immediately without preview. Faster but riskier. Current mode is saved to database and persists across sessions.

Call this tool when the user says things like: → "tự động xác nhận" / "auto confirm" / "không cần hỏi" / "don't ask" / "apply directly" → mode: "auto_apply" → "hỏi trước khi lưu" / "luôn hỏi" / "always ask" / "confirm before saving" / "xác nhận trước" → mode: "always_confirm"

List all CMS files (HTTP functions, cron jobs, ...) for the site

Create a new CMS file. Types: "http_function", "jobs_config", "default"

Update the code content of an existing CMS file

Get the main HTTP function file. Choose the right mode for your task:

• overview=true: function names + line ranges only, NO code body. Use for: browsing, understanding structure, finding which function to read.

• overview=false (DEFAULT): full code + collection schemas. Use for: writing new features, refactoring, understanding full context. Tip: for small fixes, use overview first then get_http_function_snippet to read just that function. Add include_guide=true on first call to get the coding guide

Read specific function(s) by name. Much more token-efficient than reading the full file

Edit the HTTP function file by function name — best for targeted changes (fix a bug, rename, add one function). For writing multiple new functions or major refactors, use update_http_function with full content instead. Actions:

• "replace_function": replace an ENTIRE function by name with new code. Server finds function boundaries automatically.

• "add": append new function code at end of file.

• "remove": remove a function by name.

• "update_imports": replace the import block (lines before first export). Returns updated function list after edit.

Write the FULL HTTP function file content. Best for: writing new features, major refactors, or changes that touch multiple functions. For small targeted edits (fix one function, add one function), use edit_http_function instead. After update, auto-deploys to the bundle service

Run a deployed HTTP function. function_name excludes method prefix. Example: "get_Products" → function_name="Products", method="GET"

Run JS code in debug mode (without deploying). Returns execution result and console logs

Save a version snapshot of a CMS file for rollback

View version history of a CMS file. Each version includes its saved content — to restore, pass that content back to update_http_function (the http_function file) or update_cms_file, or use restore_file_version.

Roll a CMS file back to a saved version in one step: reads the version's content and writes it back to the file. Omit version_id to restore the most recent snapshot. Tip: save_file_version on the current content first if you want an undo point.

Toggle debug render mode for a CMS file

List all pages of the site (metadata only, without source)

Get page source overview: section count, element type counts, and all custom CSS classes. Use this first, then use search_page_elements to find specific elements

Search/filter elements within a page source. Returns matching elements with full detail (id, type, style, text, classes, etc.). Examples:

• Find all buttons: type="button"

• Find elements with custom class: custom_class="hero"

• Find text containing "subscribe": text="subscribe"

• Find all data-bound elements: has_bind=true

• Find all elements with events: has_events=true

• Find all elements with custom CSS classes: has_custom_class=true

Create a new (empty) page. For a page with content use build_page instead. type is a KIND (main/store/member/blog/custom/error/maintain) mapped to the numeric backend type; pass seo so it doesn't publish with an empty title. ONE page per site for main (homepage) / error / maintain, and slugs are unique per site — a duplicate is refused with the existing page_id to edit instead; only 'custom' pages can be created over and over.

Update page properties (name, slug, settings, custom code)

Get custom code of the site (CSS/JS). Two modes:

• Default: returns ALL 4 code fields (full content)

• With field filter: returns only the specified field(s) — saves tokens when you only need CSS or JS Add include_guide=true on first call to get the coding guide

Update custom code (CSS/JS) for the entire site. Only sends fields you specify — others remain unchanged. IMPORTANT: Before calling, you MUST read existing code with get_site_custom_code first, then show the user what will change and get explicit confirmation. NEVER update without user approval.

• code_before_head: HTML/script inserted before

• code_before_body: HTML/script inserted before

• code_custom_css: Custom CSS (auto-wrapped in )

• code_custom_javascript: Custom JavaScript

Append or prepend code to a custom code field WITHOUT reading the existing content first. Use this when you need to ADD new CSS rules, JS code, or script tags — no need to read first. For full rewrites, use update_site_custom_code instead.

Delete a page

View version history of a page

List multi-language contents of a page

Create/update page content for a specific language. IMPORTANT: Before calling, you MUST read existing content with list_page_contents first, then show the user what will change and get explicit confirmation. NEVER update without user approval.

Get full detail of a single element by its ID (e.g. 'TEXT-3', 'BUTTON-1', 'SECTION-2'). Returns style, config, specials, events, bindings, responsive, and children IDs

Update properties of a specific element in page source. Two-step process: STEP 1: Call with dry_run=true (default) → returns diff of what will change. STEP 2: Show the diff to the user and ask for confirmation. NEVER proceed without explicit user approval. STEP 3: Only after user confirms, call again with dry_run=false to apply. IMPORTANT: You MUST show the diff to the user and get explicit "yes/ok/confirm" before calling with dry_run=false. Skipping confirmation risks data loss. Merge rules: style/config/specials = shallow merge, responsive = merge by bp key. events/bindings = REPLACE the whole array — pass the COMPLETE list (read it first with get_page_element so you don't drop the others); entries are auto-normalized (id + eventName filled in, so you can pass just { action, ...fields } / { target }).

Batch update multiple elements in one page. Two-step process: STEP 1: Call with dry_run=true (default) → returns per-element diff. STEP 2: Show all diffs to the user and ask for confirmation. NEVER proceed without explicit user approval. STEP 3: Only after user confirms, call again with dry_run=false to apply. IMPORTANT: You MUST show the diff to the user and get explicit "yes/ok/confirm" before calling with dry_run=false. Skipping confirmation risks data loss. Same merge rules: style/config/specials = shallow merge, events/bindings = replace.

Directly update the full page source JSON. IMPORTANT: Before calling this tool, you MUST:

1. Read existing source with get_page_source first

2. Show the user what will change and get explicit confirmation

3. NEVER call without user approval — this replaces the ENTIRE page source Safeguarded: blocks if new source is <50% of existing size.

List all database collections (tables) for the site. Returns collection names, table names, and field counts. Use get_collection for full schema details

Get a specific collection's details including full schema (field names, types, constraints, references) and records

Query records from a collection (custom data table) by table name. Supports paging + an optional where filter and order_by sort. (Uses the CMS api-key auth the records endpoint requires.)

Create a new collection (custom data TABLE). It starts with the system columns (id/inserted_at/updated_at/creator_id); pass columns to add custom fields. NOTE: to WRITE records into it, use an HTTP function (webcake-data: db.model(table).create({...})) — the dashboard has no direct record-insert API. See get_http_function for the SDK guide.

Add or change a collection's custom columns. Reads the current schema, then PATCHes it with the system columns + your custom columns (the PATCH replaces the whole schema, so omitting a column drops it).

Delete a collection (table) and all its records by id. Irreversible.

List blog articles (metadata only, without HTML content). Use get_article for the full content. Pass term to search by title/slug. Pass category_id to list the posts filed under one blog category — that view is the public one, so hidden posts and posts scheduled in the future are left out.

Get article details by ID (includes the full HTML content)

Create a blog article so blog/post pages (post-list, grid-blog, post-overlay) have content. Built via the dashboard command pipeline: title + optional summary, HTML content, image URLs, and category linkage. Pass category_ids from create_blog_category / list articles' categories so the post shows up under those categories (it is also auto-filed under the default category). Image URLs must be hosted (search_images / upload_images). The backend generates the id and slug.

Update a blog article. Only the fields you pass are changed — each one becomes a command in the same dashboard pipeline create_article uses. NOTE: renaming regenerates the slug, so pass slug in the SAME call if you want a custom one (it is applied after the rename).

Delete blog articles (soft delete — they disappear from the site)

List/search the site's customers (browse or segment). Pass term to search by name/phone/email. Returns name, phone, email, order_count, purchased_amount, reward_point, tags, last_order_at. Use find_customer for an exact id/phone/email lookup.

Find a customer by ID, phone number, or email

List products of the site (metadata only: id, name, slug, price, image, status). Use get_product for full details

Get full product details by ID: name, description, price, variations, images, attributes, SEO, etc.

Search products by keyword. Returns matching products with basic info

List all product categories of the site

Create a product so the storefront has real merchandise (grid-product / slider-product bindings need this). Simple use: pass name + price (+ images, category_ids). One default variation with the price/stock is created for you. Advanced use: pass attributes (e.g. Color/Size) + variations for a multi-SKU product. Images must be HOSTED URLs — get them from search_images or upload_images first. The backend generates id, slug and publishes the product.

Create a product category (so grid-category / a category page has something to show, and products can be filed under it). Returns the new category id — pass it to create_product's category_ids. Image must be a hosted URL.

Create a blog/article category. Returns the new category id — pass it to create_article's category_id so posts are grouped (post-list / blog pages bind to it). Image must be a hosted URL.

Update an existing product. Pass product_id + only the fields to change. To change price/stock, pass variations (get_product first to see the existing variation shape). Images must be hosted CDN urls (search_images cdn_url / upload_images).

Publish or unpublish one or more products quickly (without a full update).

Delete one or more products by id.

Update a product category (name, image, description, or visibility). Pass id + fields to change.

Delete one or more product categories by id.

List orders of the site (metadata only). Use get_order for full details including items

Get full order details by ID: customer info, items, payment, shipping, discounts, etc.

Get order count grouped by status. Useful for dashboard overview

Get full site information: name, domain, settings (colors, typography, layout, language, payment methods, etc.)

List all custom themes of the site. Returns theme name, colors, typographies, transitions, and which one is active

Search/list the public Webcake template marketplace (api.storecake.io). Use to match customer brief against existing templates by keyword. Returns id, name, preview_url, thumbnail, categories

Semantic search across the theme marketplace using bge-m3 embeddings (cosine similarity). Use when the brief is a natural-language description of industry + features (e.g. 'website mỹ phẩm có popup minigame và loyalty'), not just keywords. Returns top matches with theme_id, score, name, preview_url, thumbnail, description_vi/en

Create a NEW site from a marketplace TEMPLATE (the dedicated "use this template" API). Clones the template's pages, global sections, cart, popups, styles and fonts into a fresh site. Pick a template with semantic_search_themes / list_template_themes, then pass its theme_id here. Switches to the new site so you can immediately edit layout/content with update_page_element(s), colours/fonts via the site-style tools, then publish_site.

List the site's installed applications (type, status, settings). App type codes: 0=product_review, 1=articles_review, 2=automation, 3=telegram, 4=affiliates, 5=multilingual, 6=appointment, 7=send_email, 8=botcake, 9=sale_channel, 10=product_design, 11=auth_otp, 12=personal_product_design, 14=course, 15=zalo_mini_app, 16=cms, 17=recaptcha, 18=pwa.

Get one installed app by its type code (returns null if not installed). App type codes: 0=product_review, 1=articles_review, 2=automation, 3=telegram, 4=affiliates, 5=multilingual, 6=appointment, 7=send_email, 8=botcake, 9=sale_channel, 10=product_design, 11=auth_otp, 12=personal_product_design, 14=course, 15=zalo_mini_app, 16=cms, 17=recaptcha, 18=pwa. You may pass the number or the name.

Install (register) an application on the current site so its features become usable. For example, automations need the "automation" app installed first. App types: 0=product_review, 1=articles_review, 2=automation, 3=telegram, 4=affiliates, 5=multilingual, 6=appointment, 7=send_email, 8=botcake, 9=sale_channel, 10=product_design, 11=auth_otp, 12=personal_product_design, 14=course, 15=zalo_mini_app, 16=cms, 17=recaptcha, 18=pwa.

Uninstall (remove) an installed application from the current site. Pass the app's subscription id — get it from list_apps (the id field) or get_app.

Update an installed app's configuration. Pass the app subscription id and an attrs object that is merged onto the subscription — usually { settings: {...} }, optionally { status }. For the product-review app, prefer update_app_review (it also propagates shop_info).

Update the product-review app's settings (e.g. shop_info, auto-approve, display options). Pass the review app's subscription id (get_app with type "product_review") and the full settings object.

List all promotions/discounts of the site (metadata only). Use get_promotion for full details

Get full promotion details by ID: name, type, schedule, discount rules, coupon settings, items, bonus products, etc.

Get products/variations/categories attached to a promotion. Returns items with discount details (fixed_prices, level_info, coupon_item_info)

Get all currently active promotions (is_activated=true and within start_time/end_time range)

Search/filter promotions with advanced filters: by type, status (coming_soon/in_progress/finished), keyword, date range

List all combo/bundle products of the site. Use get_combo_items for combo composition details

Get items (products/variations) and bonus products that compose a combo. Returns combo_items (required items with count) and bonus_items (free gifts)

List global sources (cart, popup, etc.). Returns compact summary per source. Always provide component to filter by type — the API may not return all types without a filter.

Get all cart global sources with compact tree view. Shows full element hierarchy — no need to call get_global_source_detail separately.

Get full detail of a global source — compact tree view showing all elements. Each line: ID [type] "text" .class [events] [bindings] (children_count). Provide component for faster lookup; omit if you already called list_global_sources.

Search/filter elements within a global source. No component param needed. Examples:

• Find all buttons: type="button"

• Find by class: custom_class="hero"

• Find text: text="subscribe"

• Data-bound only: has_bind=true

• With events: has_events=true

• With custom class: has_custom_class=true

Get full detail of a single element (style, config, specials, events, bindings, responsive, children).

Update a single element within a global source. Two-step process: STEP 1: Call with dry_run=true (default) → returns diff of what will change. STEP 2: Show the diff to the user and ask for confirmation. NEVER proceed without explicit user approval. STEP 3: Only after user confirms, call again with dry_run=false to apply. IMPORTANT: You MUST show the diff to the user and get explicit "yes/ok/confirm" before calling with dry_run=false. Skipping confirmation risks data loss. Merge rules: style/config/specials = shallow merge, responsive = merge by bp key. events/bindings = REPLACE the whole array — pass the COMPLETE list (read it first); entries are auto-normalized (id + eventName filled in).

Batch update multiple elements in one global source. Two-step process: STEP 1: Call with dry_run=true (default) → returns per-element diff. STEP 2: Show all diffs to the user and ask for confirmation. NEVER proceed without explicit user approval. STEP 3: Only after user confirms, call again with dry_run=false to apply. IMPORTANT: You MUST show the diff to the user and get explicit "yes/ok/confirm" before calling with dry_run=false. Skipping confirmation risks data loss. Same merge rules: style/config/specials = shallow merge, events/bindings = replace.

Create a new global source component. Component types: "cart-droppable" (cart), "popup", or any custom type.

Replace full source of a global source. IMPORTANT: Before calling this tool, you MUST:

1. Read existing source with get_global_source_detail first

2. Show the user what will change and get explicit confirmation

3. NEVER call without user approval — this replaces the ENTIRE source Safeguarded: blocks if new source is <50% of existing size. For element-level changes, prefer update_global_source_element instead.

Delete a global source and its published version

Get multilingual contents for global sources by component type

Update multilingual contents (upsert). Each entry: global_source_id, language_code, content. IMPORTANT: Before calling, you MUST read existing contents with get_global_source_contents first, then show the user what will change and get explicit confirmation. NEVER update without user approval.

List reusable global sections (Header, Footer, shared content blocks) — SLIM summary only. Each entry: id, name, slot (header/footer/block), element count + type histogram + custom classes. The full element tree is large, so it is NOT returned here — drill in with get_global_section (compact tree), search_global_section_elements, or get_global_section_element.

Get one global section as a COMPACT tree (3-5x fewer tokens than raw JSON). Each line: ID [type] "text" .class [Nbind] [Nev] (children_count). Use this to learn how a real Header/Footer/block is composed before building your own.

Search/filter elements within a global section (Header/Footer/block) without dumping the whole tree. Filter by type, id substring, custom_class, text, or has_bind / has_events / has_custom_class.

Get full detail (style, config, specials, events, bindings, responsive bp1..bp4, children IDs) of a single element inside a global section.

Create a reusable global section (Header / Footer / shared block) the way the builder does: persists a global_section record AND embeds the same section node into page sources so it actually renders across the site (header → top of every page, footer → bottom). Build the section first with new_section (give it a real bg/padding + logo/menu/links), then pass it here. Two-step safety: dry_run=true (default) previews which pages change; dry_run=false performs the atomic save.

Delete a global section (Header/Footer/block) and remove its node from every page source. Two-step safety: dry_run=true (default) shows which pages would change; dry_run=false performs the atomic save.

Read a slice of a large cached result produced by another tool (look for "cached":true + a cache_id in its output). Page through with offset/length; the response reports next_offset + remaining_chars until done.

List the large results currently held in the session cache (id, label, size, age).

Scan all images used across page sources, global sources, and global sections. Returns a unique list of image URLs with which elements use each one. Useful for: image audit, finding broken/duplicated CDN URLs, bulk replace planning, theme migration. Scans every string field in the source tree (config.src, style.background-image, etc.) and CSS url(...) refs — wide net catches all variants.

Fetch an image URL and return its bytes for vision analysis by the AI client. Pair with scan_unique_images to inspect images already on the site.

After receiving the image, describe it (subject, style, palette, composition, mood, lighting, background, notable_details) to build an image-generation brief.

Describe the image with these fields, useful as input for new image generation:

• subject: main object / scene / person

• style: photography, illustration, 3D render, flat vector, watercolor, ...

• palette: 3–5 dominant colors (hex or names)

• composition: layout, framing, focal point

• mood: emotion or atmosphere

• lighting: natural / studio / golden hour / dramatic / soft / ...

• background: setting / environment

• notable_details: props, textures, typography, brand elements Use these as building blocks when drafting an image-gen brief.

Find all image elements across pages + global sources, with element_id, current alt, src, and the field path where alt is/should be written. Use as the first step before generating alt text via vision (read_image) and writing back with set_image_alts. Note: global_sections are read-only via the API and are not included.

Batch-write alt text for image elements across pages + global sources. Groups updates by source so each source is fetched + saved exactly once. Workflow: list_image_elements → read_image (per src) → describe → set_image_alts(items). If alt_path is omitted, it is auto-detected via the same probe used by list_image_elements (config.image.alt → config.alt → specials.alt).

One-shot helper for filling image_alt across the site. Returns image bytes + element metadata in a single response so Claude can describe everything in one pass, then call set_image_alts once.

Workflow:

1. Call this tool with scope/limit.

2. Tool returns each image inline with its element_id + source_type + source_id.

3. Claude reads images, drafts an alt for each, then calls set_image_alts(items) once with the template at the end of the response.

The pre-built "items" template at the end contains placeholders — fill in "alt" and call set_image_alts.

Batch fetch multiple image URLs in parallel. Use when comparing several references or extracting motifs across a set. Capped at 5 images per call to keep context manageable. For each image, describe subject/style/palette/composition/mood; then synthesize common themes for the brief.

Describe the image with these fields, useful as input for new image generation:

• subject: main object / scene / person

• style: photography, illustration, 3D render, flat vector, watercolor, ...

• palette: 3–5 dominant colors (hex or names)

• composition: layout, framing, focal point

• mood: emotion or atmosphere

• lighting: natural / studio / golden hour / dramatic / soft / ...

• background: setting / environment

• notable_details: props, textures, typography, brand elements Use these as building blocks when drafting an image-gen brief.

Get the BuilderX page authoring guide: page shape, the grid layout model, styling, breakpoints, forms/data, and the build workflow. Read this before building or heavily editing a page.

Get the authoritative JSON Schema (Draft 2020-12) for a page source { sections: [...] } — the structural contract for every node (id/type/specials/runtime{style,config}/children/events/bindings) in the CSS-grid model. Use it as the shape to emit; validate_page enforces the semantic rules.

List all BuilderX element/component types you can place on a page, grouped by category with a one-line summary and whether each is a container.

Get the full detail of an element type: category, container flag, summary, an ATTRIBUTES reference (the meaningful specials/config keys + their purpose/allowed values, events, and dataset binding targets), and a live skeleton node (the authoritative default shape) you can copy and edit. Read this before authoring/editing an element so you set the right keys.

List every interaction EVENT you can attach to a node: the triggers (eventName: click/hover/success/submit/…) and the actions (open_page, scroll_to, toggle, open_popup, add_to_cart, buy_now, phone_call, open_link, …) with the exact extra fields each action needs. Attach via new_element/new_section opts.events (ids are auto-minted, e.g. opts.events=[{ action:'add_to_cart', open_page:'cart' }]).

List every dynamic-data BINDING target: the datasets (product, cart_item, order, order_item, post, category, customer, customer_address, …) and their exact field names ('product::product_price', …), which page type each needs (store/member/blog), and how repeater children (grid-product, cart-items, post-list) bind per-item. Attach via new_element opts.bindings (ids auto-minted, e.g. opts.bindings=[{ target:'product::product_price' }]).

Build a single structurally-valid element node from the real builder factory. Returns the node — edit its specials/style, then place it in a section's children.

Build a complete section node with children laid out in the builder's vertical grid. Pass an array of element specs; each child is stacked top-to-bottom. Nest containers via the child's own 'children'. Example children: [{ "type":"text", "opts":{"text":"Welcome","style":{"fontSize":"40px"}} }, { "type":"button", "opts":{"text":"Shop now"} }]

Build a multi-column ROW container: children laid out SIDE BY SIDE (not stacked). This is how real pages build feature cards, category tiles, footer columns, a 2-col hero, etc. The row is RESPONSIVE — it auto-collapses to fewer columns on tablet/mobile (default tablet 2, mobile 1) so cards never become cramped slivers. Place the returned node as a child inside a section (section children still stack vertically; nest a row for horizontal layout). Example children: [{ "type":"container", "children":[{"type":"image","opts":{...}},{"type":"text","opts":{...}}] }, { ... }, { ... }]

Return an empty but valid page source: { sections: [] }. Add sections built with new_section, then save with build_page.

Validate a page source ({ sections: [...] }). Returns errors (block saving: duplicate/missing ids, missing types) and warnings (unknown types, form fields without field_name, dangling event targets) plus stats. Always run this before build_page.

Create a brand-new page AND set its full content source in one step. Two-step safety: call with dry_run=true (default) to validate and preview, then dry_run=false to actually create + save. The source must be { sections: [...] } — build sections with new_section. Validation errors block the real save. ONE page per site for type main (homepage) / error / maintain, and slugs are unique per site: a duplicate is refused (dry_run reports blocked:true) and you get the existing page_id to edit instead. Only 'custom' pages can be created over and over.

Append a section to an EXISTING page's source. Reads the current source, appends your section, validates, and (when dry_run=false) saves. The section is re-id'd to avoid collisions. Build it with new_section. Two-step safety: dry_run=true (default) previews; dry_run=false saves.

Search stock photos (Pexels) for a page/product. IMPORTANT: the storefront only renders images served from the WebCake CDN (image domains are whitelisted) — raw Pexels URLs will NOT display. By default this re-hosts each result on the WebCake CDN and returns a ready-to-use cdn_url (cached, so repeats are free). Use cdn_url for image src / product images. Requires the PEXELS_API_KEY environment variable.

Convert external image URLs, data: URIs, or LOCAL FILE PATHS into site-hosted CDN URLs by reading/downloading each image and re-uploading it to the WebCake backend. Use this whenever the user supplies their OWN images (their URLs or files from their machine), or a page is built from a reference HTML/URL. The returned CDN URLs go straight into an image element's specials.src / runtime.config.src, or a product/category image. This is REQUIRED for any external image (incl. Pexels search results) because the storefront only renders whitelisted WebCake-CDN image domains. Results are cached per site, so re-uploading the same source is free. Processes up to 20 entries per call in parallel; non jpeg/png/webp inputs are converted to JPEG. UPLOADS BY DEFAULT (dry_run defaults to FALSE — this touches no account data): returns an "images" map (original source → hosted URL). Pass dry_run:true to only preview the entries that WOULD be processed (local paths report whether the file exists + its size) without any network/filesystem upload. Local file paths are only permitted when the MCP server runs locally (stdio); on the remote HTTP transport they are rejected per-entry.

Publish the whole site live — snapshots all current page sources into the live (published) version. Note: BuilderX publishes at the SITE level, not per page; publishing makes every saved page go live. Two-step safety: dry_run=true (default) describes what will happen; dry_run=false actually publishes.

Parse reference HTML into a structural blueprint (title, headings, paragraphs, images, buttons, colour palette) you can rebuild as BuilderX sections with new_section. Not a 1:1 clone.

Fetch a public URL and parse it into a structural blueprint (see ingest_html). Note: client-rendered (React/Vue) pages may return little content.

Start a page draft (no network). Build a multi-section page safely: cache each section with add_draft_section, then commit_page_draft persists it to the backend INCREMENTALLY (resumable on timeout). Use this instead of build_page for large/multi-section pages. The draft cache is DISPOSABLE (Redis on the remote server when REDIS_URL is set, in-memory otherwise; sliding ~2h TTL) — if a draft is ever lost, just re-send the sections, never a failure. ONE page per site for type main (homepage) / error / maintain, and slugs are unique per site: the draft is refused up-front with the existing page_id to edit instead. Only 'custom' pages can be created over and over.

Append ONE section to a local page draft (NO network — this is the durable per-section cache step that can't time out). The section is re-id'd to avoid collisions and quick-validated; warnings are surfaced but never block. Build the section with new_section.

Inspect a local page draft: its meta, the section ids, total section count, and (if a commit is in progress) the page_id + committed_count.

List local page drafts for the current site (summaries only: id, name, slug, type, section count, commit progress, updated_at).

Persist a local page draft to the backend INCREMENTALLY (one section per request, 120s timeout each) so no single huge request can time out. dry_run=true (default) validates the assembled page and previews stats. dry_run=false creates the page then appends sections one at a time, saving progress after each. RESUMABLE: if a request fails mid-commit, the draft keeps its page_id + committed_count — just call commit_page_draft again to continue from where it stopped.

Delete a local page draft (does NOT delete any backend page already created from it).

List every WebCake tool group, how many tools it has, and whether it is loaded natively or reached on-demand via search_tools + invoke_tool.

Find WebCake tools by keyword across the FULL catalog — including capabilities NOT loaded natively (marketing/CRM, translations, media, appointments, affiliate, reviews, domains/SEO/shipping, brands/tags/ribbons, courses, sale channels, automation…). Returns name, group, description and JSON input schema. Then run one with invoke_tool.

Run any WebCake tool by exact name with its arguments (discover names + schemas via search_tools). Arguments are validated before running. Use this for tools that are not loaded natively.