Setting Up The Wazzi Content Connector

Path: Connectors → Wazzi Content → Configuration

What this connector does

Wazzi Content is a first-party MCP connector that exposes your storefront CMS — pages, blocks, media, sites, and property overrides — as MCP tools. It's the write surface behind the in-app content-builder chat: create pages, patch specific blocks, publish drafts, upload or generate media, and layer editorial overrides on top of Streamline-synced property data. Anything an author can do in the CMS UI, an assistant can do here.

Because Wazzi Content is first-party, there's nothing to configure and no external credentials to enter. Every request is org-scoped server-side, and the connector talks directly to your organization's CMS tables — no third-party API in the loop.

The connector exposes 24 tools grouped by domain:

• Sites (2 tools) — list_sites (discover your storefront slugs), get_site, update_site.
• Pages & versions (7 tools) — list / get / create / update / delete / publish / unpublish, plus list_page_versions for version history.
• Blocks (2 tools) — list_blocks (the block-type catalog) and patch_block for surgical single-block edits.
• Media (5 tools) — list / get / update / delete, plus create_media_from_urls for pulling images by URL and generate_media for AI-generated images.
• Content types (1 tool) — list_content_types for the entry-type catalog (page, blog, destination, faq, etc.).
• Property overrides (4 tools) — get_property (the merged customer-facing view), list_property_overrides, upsert_property_override, delete_property_override.

Before you start

For anything you author through this connector to render, your organization must also have the Commerce Center product enabled with at least one Site configured. Without a site, pages are created and stored but have no storefront to render on.

Beyond that, there's no per-user setup — just enable the connector on the user's group in Wazzi.

What this connector unlocks for your team

Once configured, members with the right MCP permissions can ask Claude / ChatGPT / Cursor things like:

• "Draft a new destination page for Sedona with a hero, three highlight cards, and a property grid. Save it as a draft on the arizona site."
• "Publish page <id> — the copy is ready to go live."
• "Rewrite the intro block on the Phoenix landing page to lean harder on family-friendly amenities."
• "Pull the current version of the Scottsdale destination page and show me the copy for the intro block."
• "Generate a hero image of Sedona at sunset with red rock cliffs and add it to the media library."
• "Show me the merged customer-facing view of unit 1042 on the arizona site — I want to see what the storefront actually renders."
• "Set a custom cancellation policy on unit 1042 for the midstays site."
• "List every property that has an editorial override on the acme site."

The exact set of available actions depends on which MCP toggles are flipped on for the user's group in Wazzi — see Managing Permissions. Write tools (create, update, publish, delete) can be restricted independently from reads so an editor group can publish while a viewer group only reads.

Steps — enabling Wazzi Content in Wazzi

1. From the Connectors catalog, click Configure on the Wazzi Content tile.

You'll land on Wazzi Content's Configuration tab:

2. Read the notice — there are no credentials to enter.

The configuration tab shows an information notice reminding you that Commerce Center must be enabled with at least one site for anything you author here to render on the storefront.

3. Click Test Connection.

Wazzi verifies the CMS tables are reachable. On success you'll see "Connected" along with a count of your configured sites.

4. Click Save Configuration.

Wazzi Content moves to the Active section of the catalog and the dot turns green.

Troubleshooting

• list_sites returns empty. Your organization doesn't have any storefront sites configured yet. Set one up under Commerce Center → Sites, then re-run — pages authored through this connector need a site to belong to.
• Pages are created but don't appear on the storefront. Two common causes: (1) the page is still in draft status — call publish_page; (2) the page's site_id doesn't match a live storefront — verify with list_sites.
• "Reserved slug" error on create_page. Certain slugs (e.g. built-in system paths) are reserved and can't be used for CMS pages. Pick a different slug.
• patch_block fails with "block not found". The block id you passed doesn't exist in the page's current version. Fetch the page first with get_page, find the block id from the response, and retry.
• upsert_property_override is written but the storefront still shows the old text. Storefronts use ISR (incremental static regeneration) — the change lands in the CMS immediately but the public page can take up to 2 minutes to pick it up. Force a hard refresh or wait for the next ISR cycle.
• generate_media returns a rate-limit error. AI image generation has a per-org quota. Wait a few minutes or use create_media_from_urls to upload existing images instead.

Best practices

• Use patch_block for surgical edits. When you want to change one block's text, don't round-trip the whole page — patch_block updates just that block's data and preserves everything else. Fewer merge conflicts, cleaner audit trail.
• Draft first, publish second. Create pages with status: draft so you can review the rendered output on staging before flipping publish_page. Every published version is retained; unpublish_page is reversible.
• Layer property overrides carefully. The overlay model is site variant → org default → synced. Use get_property to preview the merged result before you decide whether a variant needs to override the default.
• Prefer create_media_from_urls over base64 uploads. Passing URLs lets the server fetch the images directly; the batch call handles many URLs in one round-trip. Base64 in the message body is slower and hits payload limits.
• Never expose destructive tools to public / untrusted callers. delete_page, delete_media, and delete_property_override are permanent operations. Only grant those permissions to editorial staff — see Managing Permissions.

Frequently asked questions

Do I need to configure anything?
No. This is a first-party connector with no external credentials. Just enable it on the user's group in Wazzi.

Can users from another organization edit my sites?
No. Every tool call filters by organization_id — the CMS tables are all org-scoped. Cross-org edits are impossible.

What's the difference between a page and a block?
A page is a URL-addressable storefront entry (e.g. /destinations/sedona) that owns metadata (title, SEO fields, publish status) and a list of blocks. A block is a single content module inside a page — a hero, an html block, a property grid, a card list, etc. Pages compose blocks; blocks own the actual rendered content.

What's the difference between update_page and patch_block?
update_page takes a full replacement of the page's blocks array (and other page-level fields). patch_block touches a single block's data in place. For "change this one hero's copy," patch_block is the right call.

What are property overrides?
Storefront property pages start from your Streamline-synced unit data (name, description, images, amenities). A property override is an editorial layer on top of that: replace the title, rewrite the description, set a custom cancellation policy, add SEO tags, etc. Overrides can be org-wide (apply to every site) or per-site variants. See get_property for the merged result the storefront actually renders.

What content types are available?
Call list_content_types to see the current catalog — it varies by organization. Common ones include page, blog, destination, faq. Content types drive where a page lives (base path), what SEO defaults it inherits, and how it's rendered by the storefront.

What's next

• Set up your first storefront site in Commerce Center → Sites.
• Restrict who in your org can invoke Wazzi Content actions: Managing Permissions.
• Wire Wazzi Content into your AI tool: Connecting Claude or Connecting ChatGPT.