AI workers for Wix

What is an AI worker for Wix?

An AI worker for Wix is an AI agent scoped to one job on your Wix sites — drafting the week's blog post, refreshing product data, keeping a CMS collection in step with the system it mirrors, or reporting what changed. It works through your own Wix connection to Wix's official MCP server, and every tool it may call, reading or writing, is granted individually when the worker is set up. Nothing is available to it by default.

What these workers do

Keep the blog on its cadence

A draft post arrives in Wix Blog on schedule, written to the brief in the worker's instruction, ready for a person to review and publish — or for a publishing worker to put live at the hour you chose.

Keep the catalog current

Product names, descriptions, prices and stock flags get refreshed from the source of truth on a schedule, product by product, with every change logged.

Tend the SEO metadata

Page and item titles and meta descriptions get read, checked against what the page actually says, and updated where they have drifted.

Keep a CMS collection in step

A Wix data collection stays synchronized with the operational system it mirrors, without anyone re-keying rows or noticing too late that nobody did.

Report on the site's content

What changed this week, what is missing a description, which drafts never published — a written report on a schedule, from a worker whose instruction confines it to reading.

How an AI worker runs in Wix

Every tool is a separate grant

Narrow tools for the common jobs, broad tools when you need them

What updates over API — and what doesn't

What Wix workers are actually for

Wix questions, answered.

Can a worker edit our site's pages?

It can edit the site's content, not its design. Wix exposes blog posts, CMS collections, store products, bookings, SEO settings and media over its APIs, and a worker with the right tools can keep all of that current. The drag-and-drop editor canvas has no public API, so layout, sections and styling are not reachable by any tool here — that work stays with a person in the Wix editor, and an honest Wix worker is a content worker, not a designer.

Which sites can a worker reach?

The connection acts as the Wix login that made it, and Wix's consent is account-wide, so the connection can reach every site that login can edit. Each worker is then pointed at one site in its instructions — the site is an argument on every call, and each call is logged with it. If your Wix login manages client sites as an agency does, connect an account whose site list matches what workers should ever touch, and keep one worker to one site.

Can a worker publish to the live site?

Only through tools you bound to it. Blog work runs draft-first: creating and editing drafts is one thing, publishing a draft is a separate call, so a drafting worker can prepare everything and put nothing live. Publishing a site's pending changes is a different, account-level tool again, worth reserving for the rare worker whose whole job is publishing. The recurring shape that works: workers draft on schedule, a person publishes.

The API tools look broad — what keeps a worker in bounds?

Three things. The binding: a worker holds only the tools you granted, and the broad API tools are grants like any other. The job: a Wix worker's instruction names its site, its content type and its endpoints, which is what makes an unattended run predictable. The record: every call is logged with the worker, the tool and the time, and Wix keeps its own revision history for posts and products alongside, so any change traces to the run that made it.

Is there a record of what a worker did?

Yes, twice over. Every call a worker makes through this connection is logged with the worker, the tool, the site and the time, reads and writes alike. Wix keeps its own history too — blog revisions, product and order activity — showing the worker's changes next to everything people did. When something looks off, the two together answer both questions: what the worker did, and whether it was the worker at all.

What AI workers can do in Wix

The tools a worker can be granted in Wix once you connect it. A kit grants only the ones its job needs, and you can narrow them further on the worker.

CallWixSiteAPI

Make one Wix REST call against a chosen site: create, read, update or delete blog drafts, CMS items, store products, bookings, contacts, SEO tags and more. General-purpose — the endpoint, verb and body are supplied per call, so anything Wix's REST API can do to that site, this tool can.

Create blog draft

Create a draft blog post on one Wix site. The body carries a draftPost object: title (max 200 chars), richContent, optional excerpt, category and tag ids. Nothing goes live — publishing is a separate tool.

ExecuteWixAPI

Run a short script that chains or paginates several Wix REST calls in one step — bulk price updates, list-then-edit content jobs, cross-site reports. Wix's recommended path for Stores, Bookings and CMS work; it can fan out across every site the account holds, so the worker's instructions must pin the site.

GetSiteContext

Resolve one site by name into its site id, properties and installed Wix apps (Stores, Blog, Bookings, CMS) — what a worker checks before deciding which APIs apply.

Insert cms item

Insert one new row into a CMS data collection. Create-only by design: it fails rather than overwrites if the item id already exists.

ListWixSites

List every site the connected Wix account can manage, with the site ids other tools need. The usual first call of any site-scoped job.

ManageWixSite

Account-level site lifecycle: create a site, update its settings, or publish it. It cannot read or write business data inside a site — the two API tools do that.

Publish blog draft

Publish one draft blog post, making it live on the site's blog immediately. The one blog tool here that changes what visitors see — bind it only where publishing is the job.

Query cms items

Query rows from a CMS data collection with filters, sorting and paging. Read-only by construction: the query endpoint is pinned server-side, so this tool cannot modify anything.

Update blog draft

Change an existing draft blog post — title, content, excerpt, categories — by its draft post id. Edits stay in draft; publishing is a separate tool.

Update cms item

Replace one CMS row's data by its item id. Full replacement, per Wix's API: fields left out of the payload are removed from the item, so send the complete row.

UploadImageToWixSite

Upload one or more images into a site's Media Manager, ready to reference from posts, products and pages.