Website Builder and branding MCP guide

Use MCP to edit Website Builder tables, layouts, section visibility and settings, inspect saved page history, or import website configuration and organization branding. Organization branding imports can also affect emails and forms.

Start with Connect an AI assistant with MCP for connection setup, credential scopes, conversation context and the prepare/apply workflow. Browse the action and tool catalogue for concise capability descriptions and inputs.

Website history and import tools are top-level MCP tools. Table, layout and section operations are discovered through get_website_design_tools in a workspace opened with begin_website_design; they are not separate tools/list entries. Stage them with operate_website_design, or use supported typed final edits in prepare_website_design.section_edits. Prepare the exact draft and call apply_assistant_draft to save it. Current permissions, credential scope and stale-version checks remain authoritative.

Native website tables

MCP server 1.1.0 uses the same native website design workspace as the Website assistant. With a full-access token and website editing permission, begin the workspace, then use get_website_design_tools to discover the exact read_native_table, set_native_table and convert_native_table inputs. Stage operations with operate_website_design, prepare the immutable draft, then apply it through the standard MCP workflow.

Table values are separate English and French string matrices, with column headings in the first row. Conversion accepts one plain HTML table and preserves adjacent headings and notes in its section. Merged cells, formatting or links inside cells, nested tables and multiple tables are refused to avoid losing content. See native table editing and preview guidance.

Check post-save quality verification separately from the saved receipt. Existing connection permissions remain unchanged; refresh tool discovery or reconnect if your client has cached older instructions.

Page history and layout editing

MCP server 1.2.0 adds get_website_page_history and compare_website_page_versions. Both are available with read-only or full-catalogue credentials when the connected user has the current website permissions. They require no conversation context for a standalone read and never restore, change or publish a page.

History takes page_id, optional exclusive before_version and limit (10 by default, 20 maximum). Use the returned page-local version numbers for comparison: page_id, from_version, to_version, optional section_ids (five maximum), offset and limit. Follow next_before_version or next_offset for the remaining results. Read comparison_complete and the limitations: this is bounded saved editorial evidence, not a rendered comparison or a comparison of unsaved drafts. Image/link fingerprints show reference equality; private bindings and raw URL payloads are omitted.

For a layout change, full-catalogue clients use the typed edit_native_layout edit in prepare_website_design.section_edits or operate_website_design. Read the current blocks and target layout slots first. Supply every existing block ID exactly once, in the desired order and slot. Null width, separate-row and alignment controls preserve their values. The server retains original bilingual formatted content, links, media, tables, supported form references and section/block identities. Normal preparation, application, stale-version checks and post-save QA still apply. Read the layout and history guidance.

Refresh tool discovery or reconnect a client that has cached the earlier schemas. Existing credential scopes remain unchanged.

Section visibility

MCP server 1.2.1 exposes is_publicly_visible in section reads and in the existing general edit_section contract. With a full-catalogue credential and website permissions, use an update edit for the observed section ID and exact type/template: is_publicly_visible:true shows it, false hides it, and null preserves it. For a visibility-only update, use empty content and settings arrays and items:null. Use the normal immutable preparation/application workflow and check the saved verification result.

The field controls only the section. Showing a section never publishes a draft page or changes navigation. Existing content, blocks, style and position remain intact; protected sections and stale edits retain their normal restrictions. Read-only credentials can inspect visibility through permitted reads but cannot change it. Refresh discovery for the updated nested schema; no new top-level tool is added. Read the visibility workflow.

General section settings

MCP server 1.3.0 preserves the actual saved section visibility when opening a workspace. If an older workspace has no visibility value, reads return null (unknown); open a fresh workspace before claiming a section is visible or hidden. Page publication remains a separate state.

Use describe_template or read_section_contracts to discover the exact supported settings entries, then edit them through the existing typed edit_section or bulk contract. Supported controls include background_type:gradient, gradient_from, gradient_to, gradient_direction, border position/width/style/color, and show_eyebrow, show_title, show_subtitle where the template has those text fields. heading_width is available only on supported editorial templates. Omitted or null settings preserve existing values; explicit heading flags override automatic flags during a simultaneous copy edit. Hiding a heading retains both languages of its copy.

anchor_id can assign a valid, page-unique anchor when the section has none. Duplicate anchors and renaming an existing anchor are rejected to preserve links and managed styles; use the native editor to rename an anchor. is_shared and public_visibility_changed_at are read-only metadata. The timestamp describes the last saved visibility transition, not a staged change. Protected sections keep their existing restrictions.

No new top-level tool or credential scope is added. Refresh discovery for the current contract, prepare/apply the exact draft, and check saved verification. Read the section settings guide.

Import website configuration or organization branding

These preparation tools require a full-catalogue token and current branding permission. Website-only import also requires website editing permission; full branding import requires it when a website is included.

Website only: prepare_website_configuration_import takes a confirmed public url and an observed website_id. It proposes supported fonts, colors, design defaults, navigation, spacing, language settings, effects and favicon while preserving the organization logo and email/form branding. Review the website setup workflow.
Organization branding: prepare_website_branding_import takes a confirmed public url and optional observed website_id (primary website if omitted). It can also change the organization logo, colors and button corners used by emails/forms. Review the branding workflow.

Offer the saved organization website or ask for another URL. Website design defaults are shared across the organization’s websites. Missing or unclear evidence preserves current values. Neither import migrates page content or publishes pages.