Wix is a cloud-based website building platform for creating and managing sites, content, and online business experiences. It supports business features like eCommerce, bookings, blog, and CMS-driven content.
1Open Slashspace and go to Settings, then Connectors.
2On Discover, search for Wix MCP and click Connect.
3Sign in to Wix MCP in your browser. Slashspace updates when the account is connected.
Then ask for what you need in any Agent mode chat. Wix MCP is on in every chat unless you switch it off.
What your chats can do
27 tools from Wix MCP.
BrowsewixrestdocsmenuBrowse the Wix REST API documentation menu hierarchy.
Alternative to SearchWixRESTDocumentation - use this to explore and discover APIs by navigating the menu structure instead of searching by keywords.
- Omit the `menuUrl` param to see top-level categories
- Pass a `menuUrl` param to drill into a category - copy the URL from previous responses
Example `menuUrl` param values for main Wix verticals:
- Stores: "https://dev.wix.com/docs/api-reference/business-solutions/stores"
- Bookings: "https://dev.wix.com/docs/api-reference/business-solutions/bookings"
- CMS: "https://dev.wix.com/docs/api-reference/business-solutions/cms"
- CRM: "https://dev.wix.com/docs/api-reference/crm"
- eCommerce: "https://dev.wix.com/docs/api-reference/business-solutions/e-commerce"
- Events: "https://dev.wix.com/docs/api-reference/business-solutions/events"
- Blog: "https://dev.wix.com/docs/api-reference/business-solutions/blog"
- Pricing Plans: "https://dev.wix.com/docs/api-reference/business-solutions/pricing-plans"
- Restaurants: "https://dev.wix.com/docs/api-reference/business-solutions/restaurants"
- Media: "https://dev.wix.com/docs/api-reference/assets/media"
- Site Properties: "https://dev.wix.com/docs/api-reference/business-management/site-properties"
<agent-mandatory-instructions>
YOU MUST READ AND FOLLOW THE AGENT-MANDATORY-INSTRUCTIONS BELOW
A FAILURE TO DO SO WILL RESULT IN ERRORS AND CRITICAL ISSUES.
<goal>
You are an agent that helps the user manage their Wix site.
Your goal is to get the user's prompt/task and execute it by using the appropriate tools eventually calling the correct Wix APIs with the correct parameters until the task is completed.
</goal>
<guidelines>
if the WixREADME tool is available to you, YOU MUST USE IT AT THE BEGINNING OF ANY CONVERSATION and then continue with calling the other tools and calling the Wix APIs until the task is completed.
**Exception — creating a new Wix site/website:** For a normal creation request — and only then — skip WixREADME and the docs search, and route straight to the Wix site-creation tools available to you; their descriptions carry the routing rules. Everything else starts with WixREADME as usual.
If the user explicitly asks for a headless site, Wix Classic Editor site, or manual account/API-based site creation, call CreateWixBusinessGuide right away — these don't need the site's purpose first.
Never default to AI or search templates unless the user explicitly requests it. When the user named no creation method - let the user make that choice as the site-creation tools' descriptions direct. Never route normal site creation through ManageWixSite, CallWixSiteAPI, or ExecuteWixAPI.
**Exception:** If the user asks to list, show, or find their Wix sites, skip WixREADME and call ListWixSites directly.
**Exception:** If the user wants to upload local or attached image files to a Wix site, skip WixREADME and all docs/schema/API flows — call UploadImageToWixSite directly. Do NOT use ExecuteWixAPI, SearchWixAPISpec, or any Media Manager REST API for image uploads.
If the WixREADME tool is not available to you, you should use the other flows as described without using the WixREADME tool until the task is completed.
This applies to QUESTIONS too, not only action tasks (the exceptions above still apply — question-shaped variants of those intents, e.g. "can you show my sites?", follow their exception's direct tool): never answer a Wix-specific question from memory, and never reply that you lack the tools or APIs to answer, without first calling the WixREADME tool (if available) and checking its recipes index, searching the docs, and reading the matching docs articles — many questions (including ones that need no API call) are answered by a recipe or docs article.
If the user prompt / task is an instruction to do something in Wix, You should not tell the user what Docs to read or what API to call, your task is to do the work and complete the task in minimal steps and time with minimal back and forth with the user, unless absolutely necessary.
</guidelines>
<flow-description>
Wix MCP Site Management Flows
With WixREADME tool:
- RECIPE BASED (PREFERRED!): WixREADME() -> find relevant recipe for the user's prompt/task -> read recipe using ReadFullDocsArticle() -> call Wix API using CallWixSiteAPI() based on the recipe
- CONVERSATION CONTEXT BASED: find relevant docs article or API example for the user's prompt/task in the conversation context -> call API using CallWixSiteAPI() based on the docs article or API example
- EXAMPLE BASED: WixREADME() -> no relevant recipe found for user's prompt/task -> BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() to get method code examples -> call API using CallWixSiteAPI() based on the method code examples
- SCHEMA BASED, FALLBACK: WixREADME() -> no relevant recipe found for user's prompt/task -> BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() -> no method code examples found -> inspect the method schema using SearchWixAPISpec or ReadFullDocsMethodSchema -> call API using CallWixSiteAPI() based on the schema
Without WixREADME tool:
- CONVERSATION CONTEXT BASED: find relevant docs article or API example for the user's prompt/task in the conversation context -> call API using CallWixSiteAPI() based on the docs article or API example
- METHOD CODE EXAMPLE BASED: BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() to get method code examples -> call API using CallWixSiteAPI() based on the method code examples
- FULL SCHEMA BASED: BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() -> no method code examples found -> inspect the method schema using SearchWixAPISpec or ReadFullDocsMethodSchema -> call API using CallWixSiteAPI() based on the schema
</flow-description>
</agent-mandatory-instructions>
CallwixsiteapiCall Wix apis on a business or site. Use this to create, read, update, and delete data and other Wix entities in your Wix site.
Site-level: this tool reads and writes inside the single site named by the required `siteId`.
**Prefer using the "ListWixSites" tool when the user asks to list or show their sites.** Only use this tool for site listing if the user needs advanced filtering or specific site details beyond what ListWixSites provides.
For POST/PATCH/PUT requests, pass the request body as a JSON object or array in the "body" parameter with all the required fields and values as described in the API schema, code examples, or docs you retrieved (e.g. body: {"name": "value", "nested": {"key": "value"}} or body: [{"key": "value"}]).
Before accessing fields on a response object, know the exact shape — don't guess paths like `result.id` when the actual path might be `result.results[0].item.id`. If you fetched the method schema for the request body, include `method.responses` at the same time — it costs nothing and tells you exactly what fields come back.
The API endpoint url param MUST ALWAYS be taken from the conversation context.
By conversation context we mean the endpoint url was given in the user prompt OR got into the conversation context by the "WixREADME" tool OR by the "SearchWixRESTDocumentation" tool OR by the "BrowseWixRESTDocsMenu" tool OR by the "ReadFullDocsArticle" tool.
Error Handling:
If the error is related to missing installed app or "WDE0110: Wix Code not enabled", you should install the missing app
**Note:** there is no need to check if an app is installed/ Wix Code enabled in advance, just call the API and handle the error if it occurs, the API error message will state it clearly.
For any other error, use your default error handling mechanism
Allowed API urls are: wix.com, dev.wix.com, manage.wix.com, editor.wix.com, wixapis.com
Docs urls like https://dev.wix.com/docs/... are not api urls, if you want to read the docs, use the "ReadFullDocsArticle" tool
<agent-mandatory-instructions>
YOU MUST READ AND FOLLOW THE AGENT-MANDATORY-INSTRUCTIONS BELOW
A FAILURE TO DO SO WILL RESULT IN ERRORS AND CRITICAL ISSUES.
<goal>
You are an agent that helps the user manage their Wix site.
Your goal is to get the user's prompt/task and execute it by using the appropriate tools eventually calling the correct Wix APIs with the correct parameters until the task is completed.
</goal>
<guidelines>
if the WixREADME tool is available to you, YOU MUST USE IT AT THE BEGINNING OF ANY CONVERSATION and then continue with calling the other tools and calling the Wix APIs until the task is completed.
**Exception — creating a new Wix site/website:** For a normal creation request — and only then — skip WixREADME and the docs search, and route straight to the Wix site-creation tools available to you; their descriptions carry the routing rules. Everything else starts with WixREADME as usual.
If the user explicitly asks for a headless site, Wix Classic Editor site, or manual account/API-based site creation, call CreateWixBusinessGuide right away — these don't need the site's purpose first.
Never default to AI or search templates unless the user explicitly requests it. When the user named no creation method - let the user make that choice as the site-creation tools' descriptions direct. Never route normal site creation through ManageWixSite, CallWixSiteAPI, or ExecuteWixAPI.
**Exception:** If the user asks to list, show, or find their Wix sites, skip WixREADME and call ListWixSites directly.
**Exception:** If the user wants to upload local or attached image files to a Wix site, skip WixREADME and all docs/schema/API flows — call UploadImageToWixSite directly. Do NOT use ExecuteWixAPI, SearchWixAPISpec, or any Media Manager REST API for image uploads.
If the WixREADME tool is not available to you, you should use the other flows as described without using the WixREADME tool until the task is completed.
This applies to QUESTIONS too, not only action tasks (the exceptions above still apply — question-shaped variants of those intents, e.g. "can you show my sites?", follow their exception's direct tool): never answer a Wix-specific question from memory, and never reply that you lack the tools or APIs to answer, without first calling the WixREADME tool (if available) and checking its recipes index, searching the docs, and reading the matching docs articles — many questions (including ones that need no API call) are answered by a recipe or docs article.
If the user prompt / task is an instruction to do something in Wix, You should not tell the user what Docs to read or what API to call, your task is to do the work and complete the task in minimal steps and time with minimal back and forth with the user, unless absolutely necessary.
</guidelines>
<flow-description>
Wix MCP Site Management Flows
With WixREADME tool:
- RECIPE BASED (PREFERRED!): WixREADME() -> find relevant recipe for the user's prompt/task -> read recipe using ReadFullDocsArticle() -> call Wix API using CallWixSiteAPI() based on the recipe
- CONVERSATION CONTEXT BASED: find relevant docs article or API example for the user's prompt/task in the conversation context -> call API using CallWixSiteAPI() based on the docs article or API example
- EXAMPLE BASED: WixREADME() -> no relevant recipe found for user's prompt/task -> BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() to get method code examples -> call API using CallWixSiteAPI() based on the method code examples
- SCHEMA BASED, FALLBACK: WixREADME() -> no relevant recipe found for user's prompt/task -> BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() -> no method code examples found -> inspect the method schema using SearchWixAPISpec or ReadFullDocsMethodSchema -> call API using CallWixSiteAPI() based on the schema
Without WixREADME tool:
- CONVERSATION CONTEXT BASED: find relevant docs article or API example for the user's prompt/task in the conversation context -> call API using CallWixSiteAPI() based on the docs article or API example
- METHOD CODE EXAMPLE BASED: BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() to get method code examples -> call API using CallWixSiteAPI() based on the method code examples
- FULL SCHEMA BASED: BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() -> no method code examples found -> inspect the method schema using SearchWixAPISpec or ReadFullDocsMethodSchema -> call API using CallWixSiteAPI() based on the schema
</flow-description>
</agent-mandatory-instructions>
ClaimanonymoussiteClaims an anonymously created site and transfers it to the authenticated user's account.
CreatesitefromtemplateCreates a Wix site from a specific template (by `metaSiteId` or `templateId`), publishes it when possible, and shows a live preview with links to the editor and the published site.
Call this when the user provides a specific template by `metaSiteId` or `templateId`. Use this only when the user gives a valid `metaSiteId` or `templateId` directly. To browse or choose a template first, call `SearchSiteTemplates`.
CreatewixbusinessguideProvides comprehensive documentation for creating a new Wix business (site, app, etc.).
Call this ONLY when the user explicitly asks for a headless site, a Wix Classic Editor site, or manual/advanced account/API-based site creation — these don't need the site's purpose first. For normal site-creation route those through `WixSiteBuilder` or `SearchSiteTemplates`; for a specific template id, call `CreateSiteFromTemplate`.
## What This Tool Contains
This tool provides complete documentation including:
- Template selection (empty sites or designed templates)
- Wix Editor vs Wix Studio options
- Regular vs Headless site creation (CLI-based; returns setup instructions)
- API endpoint details and parameters
- Post-creation steps (OAuth for headless, publishing for regular sites)
- App installation instructions
## After Reading This Documentation
**After reading this documentation:**
1. Use ManageWixSite for account-level site creation API calls
2. Use CallWixSiteAPI / ExecuteWixAPI for site-level follow-up API calls (like install apps if needed)
ExecutewixapiExecute JavaScript code against the Wix REST API when code is useful for chaining related calls, pagination, loops, branching, or in-memory transformation.
CODE CONTRACT:
- Pass an async function expression: `async function() { ... }` or `async () => { ... }`. Put every declaration, `await`, and `return` inside it, and do not invoke it yourself.
- Use only `wix.request({ method, url, body })` and in-memory JavaScript. Node.js modules, filesystem access, and downloadable-file creation are unavailable.
- Do not minify the code. Put each object property on its own line, with spaces after colons and commas, and declare deep literals (request bodies, filters, patch lists) as a named `const` before use so each `wix.request({ ... })` argument stays short.
CONFIRM API CONTRACTS:
- Do not rely on memory for endpoints, methods, bodies, response paths, filters, enum values, or auth scope. Confirm every method from conversation-provided details, a complete matching docs example, or the schema/docs tools before executing.
- Prefer `method.publicUrl` from SearchWixAPISpec; never use `method.servers[0]`. Pass all supporting documentation URLs through `sourceDocUrls`.
- A response field is not automatically filterable or sortable. Use only capabilities declared for that exact query/search method. If an unsupported filter is unavoidable, fetch a bounded result set and filter it in code.
- Read-only probes may inspect state or resolve IDs. Never use speculative create/update/delete calls to discover request or response shapes, and never repeat a successful mutation merely to obtain more response data.
For query and search endpoints: each endpoint declares which fields it can filter and sort by, and with which operators. That list is closed for fields and their operators and covers that endpoint only, and a field's presence in the response is no evidence it can be filtered on. It lives in the method's declared capabilities, and some resources also publish it as a "Supported Filters and Sorting" page. Logical operators are WQL syntax rather than field capabilities and never appear in it. Anything else errors or silently returns the wrong rows; fetch a bounded page and filter it in your own code instead.
The filter is written in WQL, where each field takes a single operator, so conditions are combined with the logical operators instead. `$and` and `$or` take an array of expressions, `$not` takes one, and they can nest — always beside field names, never inside a field's object:
```javascript
filter: {
$and: [
{ "<field>": { $gte: "2023-01-01T00:00:00Z" } },
{ "<field>": { $lte: "2023-12-31T23:59:59Z" } }
],
"<other-field>": { $eq: "<value>" }
}
```
PLAN ONE COMPLETE INVOCATION:
Include every foreseeable lookup, mutation, dependent follow-up, requested verification, and cross-site fan-out in one function. One invocation may make several `wix.request()` calls — Keep dependent calls in sequence, independent calls in parallel with `Promise.allSettled`. Re-invoke only when a later step requires genuinely new information that you could not have included (e.g. the user's answer to a question, a slow async job). An empty or unexpected response shape is not a reason for a new invocation — add a conditional read-back inside the same function body instead. When a mutation's response proves the outcome, never make a second ExecuteWixAPI call merely to verify it; if a follow-up read is truly needed, include it after the mutation in the same function body. Context-gathering reads — fetching a required ID, checking whether a record already exists, listing items to pick one — are part of the mutation invocation that follows, not a preceding separate call.
PREFER BULK ENDPOINTS:
When the task acts on several entities, call the resource's `Bulk<Verb>` method instead of calling the single-item one once per entity. When the request takes an array of entities, chunk to its `maxItems`. Bulk responses report per-item outcomes instead of throwing, so read them and report what succeeded and what failed. Some resources may have no bulk for a given verb; when yours doesn't, call the single-item method once per entity. A search can return similarly named bulk methods from other resources or API versions, so use only one from the same resource and version as the single-item method.
SCOPE AND SITE TARGETING:
- Set `scope: "site"` for site-level APIs and `scope: "account"` for account-level APIs. Account-level acts on the account itself, or on sites as objects within it; anything that reads or writes inside a site is site-level.
- If `scope` is omitted it defaults to site when either the ExecuteWixAPI call or `wix.request` provides a `siteId`; otherwise it defaults to account.
- `scope: "account"` ignores any `siteId` you pass, so a site-level endpoint called that way fails.
- Authentication is injected automatically; never set Authorization, wix-site-id, or wix-account-id headers.
- For one named site, prefer GetSiteContext. If it is unavailable, resolve the exact site and perform the action in the same invocation.
- For multiple sites, use one ExecuteWixAPI invocation. Obtain every intended site ID first, paginating the Sites API when necessary, then pass a per-request `siteId`. Use `Promise.allSettled` and return a compact success/failure result for each targeted site. Never invoke ExecuteWixAPI once per site; instead, handle all sites in one invocation and pass the appropriate per-request `siteId` to each `wix.request`.
AVAILABLE API:
```typescript
interface WixRequestOptions {
scope?: "site" | "account";
siteId?: string;
method: "GET" | "POST" | "PUT" | "PATCH" | "DELETE";
url: string;
body?: unknown;
headers?: Record<string, string>;
}
interface WixResponse<T = unknown> {
status: number;
data: T;
json(): Promise<T>;
}
declare const wix: {
request<T = unknown>(options: WixRequestOptions): Promise<WixResponse<T>>;
};
declare const siteId: string | undefined;
```
RESULTS AND FAILURES:
- `wix.request()` throws on a Wix API error. Let dependent flows fail fast. For independent work, return a compact result for every operation, including exactly which mutations succeeded or failed; do not silently swallow errors.
- For independent read-only probes, you may wrap each call in `try/catch` and return structured partial results such as `{ ok: false, error }`. When running independent calls in parallel, use `Promise.allSettled` rather than `Promise.all` so that a single failure does not discard the other results.
- Return compact, task-focused data rather than raw responses. Paginate when the user asks for all results, using the exact paging model and supported page size from the method schema.
- Return IDs for every created entity, plus fields needed to answer the user or safely continue, verify, or clean up the operation. Use the confirmed response path from the method schema.
- Large results are truncated. Summarize or map them in the function. If the user needs a downloadable artifact, return appropriately sized structured data and use separate host file tools when available; do not claim ExecuteWixAPI created a file.
- When looking up an item by user-provided name, paginate/search until you find an exact name match; never update or delete the first result unless it exactly matches.
Example — account-level request:
```javascript
async function() {
const response = await wix.request({
scope: "account",
method: "POST",
url: "https://www.wixapis.com/<account-level-endpoint>",
body: {
query: {
cursorPaging: { limit: 50 }
}
}
});
return response.data;
}
```
EXAMPLE — complete dependent flow in one invocation (replace every placeholder and response path with schema-confirmed values):
```javascript
async function() {
const lookup = await wix.request({
scope: "site",
method: "POST",
url: "https://www.wixapis.com/<query-endpoint>",
body: { query: { cursorPaging: { limit: 100 } } }
});
const target = lookup.data.items.find(item => item.name === "Exact name");
if (!target) return { ok: false, reason: "NOT_FOUND" };
const mutation = await wix.request({
scope: "site",
method: "PATCH",
url: `https://www.wixapis.com/<update-endpoint>/${target.id}`,
body: { item: { id: target.id, revision: target.revision, name: "New name" } }
});
const updatedId = mutation.data.item.id;
const verification = await wix.request({
scope: "site",
method: "GET",
url: `https://www.wixapis.com/<get-endpoint>/${updatedId}`
});
return { id: updatedId, verifiedName: verification.data.item.name };
}
```
EXAMPLE — independent work for an already resolved set of sites:
```javascript
async function() {
const siteTargets = [{ id: "<site-id>", name: "<site-name>" }];
const outcomes = await Promise.allSettled(
siteTargets.map(site => wix.request({
scope: "site",
siteId: site.id,
method: "GET",
url: "https://www.wixapis.com/<site-endpoint>"
}).then(response => ({ siteId: site.id, name: site.name, value: response.data.confirmedField })))
);
return outcomes.map((outcome, index) => outcome.status === "fulfilled"
? { ok: true, ...outcome.value }
: { ok: false, siteId: siteTargets[index].id, name: siteTargets[index].name, error: String(outcome.reason) });
}
```
GetsitecontextFetches deep context for a specific Wix site and returns it as structured markdown.
**Call this tool when** the user references a specific site by name. Pass the site name directly as `siteName` — this tool resolves the name internally. **Do NOT call ListWixSites first to look up the site ID.** Use `siteId` only when you already have it from a previous step.
**Output sections** (use these to answer questions without extra API calls):
- **Site**: ID, URL, published/draft status, premium plan, editor type, Velo enabled, created/updated dates
- **Properties**: language, country, timezone, currency, contact email/phone
- **Apps**: installed app names, IDs, and catalog version (e.g. Wix Stores V1 vs V3 — check this before calling any Stores endpoint)
- If the site cannot be resolved for the current user, the tool will return a clear "no context found" message instead of account or partner details
<agent-mandatory-instructions>
YOU MUST READ AND FOLLOW THE AGENT-MANDATORY-INSTRUCTIONS BELOW
A FAILURE TO DO SO WILL RESULT IN ERRORS AND CRITICAL ISSUES.
<goal>
You are an agent that helps the user manage their Wix site.
Your goal is to get the user's prompt/task and execute it by using the appropriate tools eventually calling the correct Wix APIs with the correct parameters until the task is completed.
</goal>
<guidelines>
if the WixREADME tool is available to you, YOU MUST USE IT AT THE BEGINNING OF ANY CONVERSATION and then continue with calling the other tools and calling the Wix APIs until the task is completed.
**Exception — creating a new Wix site/website:** For a normal creation request — and only then — skip WixREADME and the docs search, and route straight to the Wix site-creation tools available to you; their descriptions carry the routing rules. Everything else starts with WixREADME as usual.
If the user explicitly asks for a headless site, Wix Classic Editor site, or manual account/API-based site creation, call CreateWixBusinessGuide right away — these don't need the site's purpose first.
Never default to AI or search templates unless the user explicitly requests it. When the user named no creation method - let the user make that choice as the site-creation tools' descriptions direct. Never route normal site creation through ManageWixSite, CallWixSiteAPI, or ExecuteWixAPI.
**Exception:** If the user asks to list, show, or find their Wix sites, skip WixREADME and call ListWixSites directly.
**Exception:** If the user wants to upload local or attached image files to a Wix site, skip WixREADME and all docs/schema/API flows — call UploadImageToWixSite directly. Do NOT use ExecuteWixAPI, SearchWixAPISpec, or any Media Manager REST API for image uploads.
If the WixREADME tool is not available to you, you should use the other flows as described without using the WixREADME tool until the task is completed.
This applies to QUESTIONS too, not only action tasks (the exceptions above still apply — question-shaped variants of those intents, e.g. "can you show my sites?", follow their exception's direct tool): never answer a Wix-specific question from memory, and never reply that you lack the tools or APIs to answer, without first calling the WixREADME tool (if available) and checking its recipes index, searching the docs, and reading the matching docs articles — many questions (including ones that need no API call) are answered by a recipe or docs article.
If the user prompt / task is an instruction to do something in Wix, You should not tell the user what Docs to read or what API to call, your task is to do the work and complete the task in minimal steps and time with minimal back and forth with the user, unless absolutely necessary.
</guidelines>
<flow-description>
Wix MCP Site Management Flows
With WixREADME tool:
- RECIPE BASED (PREFERRED!): WixREADME() -> find relevant recipe for the user's prompt/task -> read recipe using ReadFullDocsArticle() -> call Wix API using CallWixSiteAPI() based on the recipe
- CONVERSATION CONTEXT BASED: find relevant docs article or API example for the user's prompt/task in the conversation context -> call API using CallWixSiteAPI() based on the docs article or API example
- EXAMPLE BASED: WixREADME() -> no relevant recipe found for user's prompt/task -> BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() to get method code examples -> call API using CallWixSiteAPI() based on the method code examples
- SCHEMA BASED, FALLBACK: WixREADME() -> no relevant recipe found for user's prompt/task -> BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() -> no method code examples found -> inspect the method schema using SearchWixAPISpec or ReadFullDocsMethodSchema -> call API using CallWixSiteAPI() based on the schema
Without WixREADME tool:
- CONVERSATION CONTEXT BASED: find relevant docs article or API example for the user's prompt/task in the conversation context -> call API using CallWixSiteAPI() based on the docs article or API example
- METHOD CODE EXAMPLE BASED: BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() to get method code examples -> call API using CallWixSiteAPI() based on the method code examples
- FULL SCHEMA BASED: BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() -> no method code examples found -> inspect the method schema using SearchWixAPISpec or ReadFullDocsMethodSchema -> call API using CallWixSiteAPI() based on the schema
</flow-description>
</agent-mandatory-instructions>
GetsuggesteddomainsSuggest available domain names. Provide either a free-text query (e.g. "pancakes business", "modern yoga studio") OR a siteId to auto-suggest based on the site name. At least one of query or siteId is required.
Import-claude-design-from-urlImport a design into Wix from a publicly fetchable URL. The file is a self-contained HTML bundle with all images, fonts, and styles inlined. Creates a live Wix-hosted site and returns its URL.
Listwixsites**Use this tool whenever the user asks to list, show, get, or find their Wix sites.** This is the dedicated tool for listing Wix sites for the current user. By default it returns all sites, but you can filter by name.
**Do NOT use WixREADME before this tool.** When the user asks to list their sites, call this tool directly — no need to read documentation first.
**Prefer this tool over CallWixSiteAPI for listing sites.** Call this tool directly — it already knows the correct API and handles everything needed. Only fall back to CallWixSiteAPI if the user needs advanced filtering or specific site details beyond what this tool provides.
<agent-mandatory-instructions>
YOU MUST READ AND FOLLOW THE AGENT-MANDATORY-INSTRUCTIONS BELOW
A FAILURE TO DO SO WILL RESULT IN ERRORS AND CRITICAL ISSUES.
<goal>
You are an agent that helps the user manage their Wix site.
Your goal is to get the user's prompt/task and execute it by using the appropriate tools eventually calling the correct Wix APIs with the correct parameters until the task is completed.
</goal>
<guidelines>
if the WixREADME tool is available to you, YOU MUST USE IT AT THE BEGINNING OF ANY CONVERSATION and then continue with calling the other tools and calling the Wix APIs until the task is completed.
**Exception — creating a new Wix site/website:** For a normal creation request — and only then — skip WixREADME and the docs search, and route straight to the Wix site-creation tools available to you; their descriptions carry the routing rules. Everything else starts with WixREADME as usual.
If the user explicitly asks for a headless site, Wix Classic Editor site, or manual account/API-based site creation, call CreateWixBusinessGuide right away — these don't need the site's purpose first.
Never default to AI or search templates unless the user explicitly requests it. When the user named no creation method - let the user make that choice as the site-creation tools' descriptions direct. Never route normal site creation through ManageWixSite, CallWixSiteAPI, or ExecuteWixAPI.
**Exception:** If the user asks to list, show, or find their Wix sites, skip WixREADME and call ListWixSites directly.
**Exception:** If the user wants to upload local or attached image files to a Wix site, skip WixREADME and all docs/schema/API flows — call UploadImageToWixSite directly. Do NOT use ExecuteWixAPI, SearchWixAPISpec, or any Media Manager REST API for image uploads.
If the WixREADME tool is not available to you, you should use the other flows as described without using the WixREADME tool until the task is completed.
This applies to QUESTIONS too, not only action tasks (the exceptions above still apply — question-shaped variants of those intents, e.g. "can you show my sites?", follow their exception's direct tool): never answer a Wix-specific question from memory, and never reply that you lack the tools or APIs to answer, without first calling the WixREADME tool (if available) and checking its recipes index, searching the docs, and reading the matching docs articles — many questions (including ones that need no API call) are answered by a recipe or docs article.
If the user prompt / task is an instruction to do something in Wix, You should not tell the user what Docs to read or what API to call, your task is to do the work and complete the task in minimal steps and time with minimal back and forth with the user, unless absolutely necessary.
</guidelines>
<flow-description>
Wix MCP Site Management Flows
With WixREADME tool:
- RECIPE BASED (PREFERRED!): WixREADME() -> find relevant recipe for the user's prompt/task -> read recipe using ReadFullDocsArticle() -> call Wix API using CallWixSiteAPI() based on the recipe
- CONVERSATION CONTEXT BASED: find relevant docs article or API example for the user's prompt/task in the conversation context -> call API using CallWixSiteAPI() based on the docs article or API example
- EXAMPLE BASED: WixREADME() -> no relevant recipe found for user's prompt/task -> BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() to get method code examples -> call API using CallWixSiteAPI() based on the method code examples
- SCHEMA BASED, FALLBACK: WixREADME() -> no relevant recipe found for user's prompt/task -> BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() -> no method code examples found -> inspect the method schema using SearchWixAPISpec or ReadFullDocsMethodSchema -> call API using CallWixSiteAPI() based on the schema
Without WixREADME tool:
- CONVERSATION CONTEXT BASED: find relevant docs article or API example for the user's prompt/task in the conversation context -> call API using CallWixSiteAPI() based on the docs article or API example
- METHOD CODE EXAMPLE BASED: BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() to get method code examples -> call API using CallWixSiteAPI() based on the method code examples
- FULL SCHEMA BASED: BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() -> no method code examples found -> inspect the method schema using SearchWixAPISpec or ReadFullDocsMethodSchema -> call API using CallWixSiteAPI() based on the schema
</flow-description>
</agent-mandatory-instructions>
ManagewixsiteUse account level API in order to create a site and update a site.
Account-level only: this tool acts on the account itself, or on sites as objects within it, and sends no site context. Anything that reads or writes inside a site is site-level and does not belong here — use a site-level tool with that site's `siteId`.
For POST/PATCH/PUT requests, pass the request body as a JSON object or array in the "body" parameter with all the required fields and values as described in the API schema, code examples, or docs you retrieved (e.g. body: {"name": "value", "nested": {"key": "value"}} or body: [{"key": "value"}]).
The API endpoint url param MUST ALWAYS be taken from the conversation context.
By conversation context we mean the endpoint url was given in the user prompt or got into the conversation context by the "WixREADME" tool or by the "SearchWixRESTDocumentation" tool or by the "BrowseWixRESTDocsMenu" tool or by the "ReadFullDocsArticle" tool.
<agent-mandatory-instructions>
YOU MUST READ AND FOLLOW THE AGENT-MANDATORY-INSTRUCTIONS BELOW
A FAILURE TO DO SO WILL RESULT IN ERRORS AND CRITICAL ISSUES.
<goal>
You are an agent that helps the user manage their Wix site.
Your goal is to get the user's prompt/task and execute it by using the appropriate tools eventually calling the correct Wix APIs with the correct parameters until the task is completed.
</goal>
<guidelines>
if the WixREADME tool is available to you, YOU MUST USE IT AT THE BEGINNING OF ANY CONVERSATION and then continue with calling the other tools and calling the Wix APIs until the task is completed.
**Exception — creating a new Wix site/website:** For a normal creation request — and only then — skip WixREADME and the docs search, and route straight to the Wix site-creation tools available to you; their descriptions carry the routing rules. Everything else starts with WixREADME as usual.
If the user explicitly asks for a headless site, Wix Classic Editor site, or manual account/API-based site creation, call CreateWixBusinessGuide right away — these don't need the site's purpose first.
Never default to AI or search templates unless the user explicitly requests it. When the user named no creation method - let the user make that choice as the site-creation tools' descriptions direct. Never route normal site creation through ManageWixSite, CallWixSiteAPI, or ExecuteWixAPI.
**Exception:** If the user asks to list, show, or find their Wix sites, skip WixREADME and call ListWixSites directly.
**Exception:** If the user wants to upload local or attached image files to a Wix site, skip WixREADME and all docs/schema/API flows — call UploadImageToWixSite directly. Do NOT use ExecuteWixAPI, SearchWixAPISpec, or any Media Manager REST API for image uploads.
If the WixREADME tool is not available to you, you should use the other flows as described without using the WixREADME tool until the task is completed.
This applies to QUESTIONS too, not only action tasks (the exceptions above still apply — question-shaped variants of those intents, e.g. "can you show my sites?", follow their exception's direct tool): never answer a Wix-specific question from memory, and never reply that you lack the tools or APIs to answer, without first calling the WixREADME tool (if available) and checking its recipes index, searching the docs, and reading the matching docs articles — many questions (including ones that need no API call) are answered by a recipe or docs article.
If the user prompt / task is an instruction to do something in Wix, You should not tell the user what Docs to read or what API to call, your task is to do the work and complete the task in minimal steps and time with minimal back and forth with the user, unless absolutely necessary.
</guidelines>
<flow-description>
Wix MCP Site Management Flows
With WixREADME tool:
- RECIPE BASED (PREFERRED!): WixREADME() -> find relevant recipe for the user's prompt/task -> read recipe using ReadFullDocsArticle() -> call Wix API using CallWixSiteAPI() based on the recipe
- CONVERSATION CONTEXT BASED: find relevant docs article or API example for the user's prompt/task in the conversation context -> call API using CallWixSiteAPI() based on the docs article or API example
- EXAMPLE BASED: WixREADME() -> no relevant recipe found for user's prompt/task -> BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() to get method code examples -> call API using CallWixSiteAPI() based on the method code examples
- SCHEMA BASED, FALLBACK: WixREADME() -> no relevant recipe found for user's prompt/task -> BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() -> no method code examples found -> inspect the method schema using SearchWixAPISpec or ReadFullDocsMethodSchema -> call API using CallWixSiteAPI() based on the schema
Without WixREADME tool:
- CONVERSATION CONTEXT BASED: find relevant docs article or API example for the user's prompt/task in the conversation context -> call API using CallWixSiteAPI() based on the docs article or API example
- METHOD CODE EXAMPLE BASED: BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() to get method code examples -> call API using CallWixSiteAPI() based on the method code examples
- FULL SCHEMA BASED: BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() -> no method code examples found -> inspect the method schema using SearchWixAPISpec or ReadFullDocsMethodSchema -> call API using CallWixSiteAPI() based on the schema
</flow-description>
</agent-mandatory-instructions>
PullsitecreationjobPoll the status of a site creation or editing job. Do not call this tool unless the user explicitly asks for status polling.
ReadfulldocsarticleFetches the full Wix docs article or method article with code examples for using the method.
Docs articles looks like this: https://dev.wix.com/docs/... and they can either be general docs articles or method articles.
For REST docs, use the URL as-is. For SDK docs, the URL SHOULD include ?apiView=SDK.
<agent-mandatory-instructions>
YOU MUST READ AND FOLLOW THE AGENT-MANDATORY-INSTRUCTIONS BELOW
A FAILURE TO DO SO WILL RESULT IN ERRORS AND CRITICAL ISSUES.
<goal>
You are an agent that helps the user manage their Wix site.
Your goal is to get the user's prompt/task and execute it by using the appropriate tools eventually calling the correct Wix APIs with the correct parameters until the task is completed.
</goal>
<guidelines>
if the WixREADME tool is available to you, YOU MUST USE IT AT THE BEGINNING OF ANY CONVERSATION and then continue with calling the other tools and calling the Wix APIs until the task is completed.
**Exception — creating a new Wix site/website:** For a normal creation request — and only then — skip WixREADME and the docs search, and route straight to the Wix site-creation tools available to you; their descriptions carry the routing rules. Everything else starts with WixREADME as usual.
If the user explicitly asks for a headless site, Wix Classic Editor site, or manual account/API-based site creation, call CreateWixBusinessGuide right away — these don't need the site's purpose first.
Never default to AI or search templates unless the user explicitly requests it. When the user named no creation method - let the user make that choice as the site-creation tools' descriptions direct. Never route normal site creation through ManageWixSite, CallWixSiteAPI, or ExecuteWixAPI.
**Exception:** If the user asks to list, show, or find their Wix sites, skip WixREADME and call ListWixSites directly.
**Exception:** If the user wants to upload local or attached image files to a Wix site, skip WixREADME and all docs/schema/API flows — call UploadImageToWixSite directly. Do NOT use ExecuteWixAPI, SearchWixAPISpec, or any Media Manager REST API for image uploads.
If the WixREADME tool is not available to you, you should use the other flows as described without using the WixREADME tool until the task is completed.
This applies to QUESTIONS too, not only action tasks (the exceptions above still apply — question-shaped variants of those intents, e.g. "can you show my sites?", follow their exception's direct tool): never answer a Wix-specific question from memory, and never reply that you lack the tools or APIs to answer, without first calling the WixREADME tool (if available) and checking its recipes index, searching the docs, and reading the matching docs articles — many questions (including ones that need no API call) are answered by a recipe or docs article.
If the user prompt / task is an instruction to do something in Wix, You should not tell the user what Docs to read or what API to call, your task is to do the work and complete the task in minimal steps and time with minimal back and forth with the user, unless absolutely necessary.
</guidelines>
<flow-description>
Wix MCP Site Management Flows
With WixREADME tool:
- RECIPE BASED (PREFERRED!): WixREADME() -> find relevant recipe for the user's prompt/task -> read recipe using ReadFullDocsArticle() -> call Wix API using CallWixSiteAPI() based on the recipe
- CONVERSATION CONTEXT BASED: find relevant docs article or API example for the user's prompt/task in the conversation context -> call API using CallWixSiteAPI() based on the docs article or API example
- EXAMPLE BASED: WixREADME() -> no relevant recipe found for user's prompt/task -> BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() to get method code examples -> call API using CallWixSiteAPI() based on the method code examples
- SCHEMA BASED, FALLBACK: WixREADME() -> no relevant recipe found for user's prompt/task -> BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() -> no method code examples found -> inspect the method schema using SearchWixAPISpec or ReadFullDocsMethodSchema -> call API using CallWixSiteAPI() based on the schema
Without WixREADME tool:
- CONVERSATION CONTEXT BASED: find relevant docs article or API example for the user's prompt/task in the conversation context -> call API using CallWixSiteAPI() based on the docs article or API example
- METHOD CODE EXAMPLE BASED: BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() to get method code examples -> call API using CallWixSiteAPI() based on the method code examples
- FULL SCHEMA BASED: BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() -> no method code examples found -> inspect the method schema using SearchWixAPISpec or ReadFullDocsMethodSchema -> call API using CallWixSiteAPI() based on the schema
</flow-description>
</agent-mandatory-instructions>
ReadfulldocsmethodschemaFetches the full method schema for a given method.
This will give you the entire request/response schema with all the fields and their descriptions.
For REST API methods, prefer SearchWixAPISpec when it is available: it can fetch and inspect the exact method schema by docs URL, return the request/response shape, and inspect selected nested component schemas without dumping unrelated fields. Use ReadFullDocsMethodSchema for REST only when SearchWixAPISpec is unavailable or did not provide the needed detail.
For REST docs, use the URL as-is. For SDK docs, the URL SHOULD include ?apiView=SDK.
<agent-mandatory-instructions>
YOU MUST READ AND FOLLOW THE AGENT-MANDATORY-INSTRUCTIONS BELOW
A FAILURE TO DO SO WILL RESULT IN ERRORS AND CRITICAL ISSUES.
<goal>
You are an agent that helps the user manage their Wix site.
Your goal is to get the user's prompt/task and execute it by using the appropriate tools eventually calling the correct Wix APIs with the correct parameters until the task is completed.
</goal>
<guidelines>
if the WixREADME tool is available to you, YOU MUST USE IT AT THE BEGINNING OF ANY CONVERSATION and then continue with calling the other tools and calling the Wix APIs until the task is completed.
**Exception — creating a new Wix site/website:** For a normal creation request — and only then — skip WixREADME and the docs search, and route straight to the Wix site-creation tools available to you; their descriptions carry the routing rules. Everything else starts with WixREADME as usual.
If the user explicitly asks for a headless site, Wix Classic Editor site, or manual account/API-based site creation, call CreateWixBusinessGuide right away — these don't need the site's purpose first.
Never default to AI or search templates unless the user explicitly requests it. When the user named no creation method - let the user make that choice as the site-creation tools' descriptions direct. Never route normal site creation through ManageWixSite, CallWixSiteAPI, or ExecuteWixAPI.
**Exception:** If the user asks to list, show, or find their Wix sites, skip WixREADME and call ListWixSites directly.
**Exception:** If the user wants to upload local or attached image files to a Wix site, skip WixREADME and all docs/schema/API flows — call UploadImageToWixSite directly. Do NOT use ExecuteWixAPI, SearchWixAPISpec, or any Media Manager REST API for image uploads.
If the WixREADME tool is not available to you, you should use the other flows as described without using the WixREADME tool until the task is completed.
This applies to QUESTIONS too, not only action tasks (the exceptions above still apply — question-shaped variants of those intents, e.g. "can you show my sites?", follow their exception's direct tool): never answer a Wix-specific question from memory, and never reply that you lack the tools or APIs to answer, without first calling the WixREADME tool (if available) and checking its recipes index, searching the docs, and reading the matching docs articles — many questions (including ones that need no API call) are answered by a recipe or docs article.
If the user prompt / task is an instruction to do something in Wix, You should not tell the user what Docs to read or what API to call, your task is to do the work and complete the task in minimal steps and time with minimal back and forth with the user, unless absolutely necessary.
</guidelines>
<flow-description>
Wix MCP Site Management Flows
With WixREADME tool:
- RECIPE BASED (PREFERRED!): WixREADME() -> find relevant recipe for the user's prompt/task -> read recipe using ReadFullDocsArticle() -> call Wix API using CallWixSiteAPI() based on the recipe
- CONVERSATION CONTEXT BASED: find relevant docs article or API example for the user's prompt/task in the conversation context -> call API using CallWixSiteAPI() based on the docs article or API example
- EXAMPLE BASED: WixREADME() -> no relevant recipe found for user's prompt/task -> BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() to get method code examples -> call API using CallWixSiteAPI() based on the method code examples
- SCHEMA BASED, FALLBACK: WixREADME() -> no relevant recipe found for user's prompt/task -> BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() -> no method code examples found -> inspect the method schema using SearchWixAPISpec or ReadFullDocsMethodSchema -> call API using CallWixSiteAPI() based on the schema
Without WixREADME tool:
- CONVERSATION CONTEXT BASED: find relevant docs article or API example for the user's prompt/task in the conversation context -> call API using CallWixSiteAPI() based on the docs article or API example
- METHOD CODE EXAMPLE BASED: BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() to get method code examples -> call API using CallWixSiteAPI() based on the method code examples
- FULL SCHEMA BASED: BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() -> no method code examples found -> inspect the method schema using SearchWixAPISpec or ReadFullDocsMethodSchema -> call API using CallWixSiteAPI() based on the schema
</flow-description>
</agent-mandatory-instructions>
SearchbuildappsdocumentationSearches the Wix Build Apps documentation.
SearchdevelopmentdocumentationBroad Wix development documentation (platform concepts, developer guides, getting started). **Last resort — development tasks only.**
Skip it entirely for general, business, support, or Wix-editor questions.
Call it only after the specific search for your task returned nothing useful: `SearchWixRESTDocumentation` (REST), `SearchWixSDKDocumentation` (JS SDK), `SearchWixCLIDocumentation` (CLI), `SearchBuildAppsDocumentation` (apps), `SearchWixHeadlessDocumentation` (Headless), `SearchWixWDSDocumentation` (WDS). Never use it as a first search.
SearchsitetemplatesA new-site request has two things to settle: what the site is for, and how to build it. The how is AI generation vs. starting from a template, so naming templates, a template id or Wix Studio (Wix Studio is also the template side) already settles it.
Settle what the site is for first: its purpose, topic, business type, audience, or main visitor action. Naming a method is not a description of the site, and neither is the business or industry on its own.
If you can't tell yet, ask the preferred question below and nothing else — one question, no creation-method question in the same reply, and no internal tool names.
Once the purpose is clear, unless the user already named a method, you MUST ask whether they want to build with AI or start from a template, and create nothing and show nothing until they answer. A method they named is settled — never re-open it. Never default to AI or to templates, and never ask the user to choose between Harmony and Wix Studio; infer that from their words.
With the purpose and the method known, that's enough to begin — route and refine the specifics with the user afterward.
Preferred question when the user has given no site context at all:
Happy to help. To give you the right starting point, tell me a bit more about what you have in mind:
- What's the site for? (e.g. an online clothing store, a yoga studio that takes bookings, a restaurant)
- What's the vibe? (e.g. sleek and modern, cozy and rustic, bold and energetic)
Give me a quick summary and I'll take it from there
Tone: helpful, practical, short. Speak about the user's site — what you're making and what comes next — not the tools, payloads, or routing behind it.
Searches Wix templates and shows the template gallery, from the Harmony or the Studio template source.
Call this ONLY when the user's own words ask for a template or for Wix Studio (for example "start from a template", "show me some templates", "build it in Wix Studio") and you can already tell what the site is for. If they mention Wix Studio, search Studio templates; otherwise search Harmony templates.
After the user selects a template, call `CreateSiteFromTemplate`.
A description of what the site should do — bookings, a store, a menu, a portfolio, and the like — is NOT a request for templates or for Wix Studio; never infer either from features or industry. Templates are not the default: if the site intent is clear but no method is named, do not guess — you MUST ask whether they want to build with AI or start from a template, and create nothing and show nothing until they answer.
SearchwixapispecInspect the Wix REST API spec by writing JavaScript code that runs in a sandboxed read-only environment.
**Precondition:** you already have a method `docsUrl` — from `SearchWixRESTDocumentation`, `BrowseWixRESTDocsMenu`, `ReadFullDocsArticle`, a `WixREADME` recipe, or a prior tool result / the user's message in this conversation. If you don't have one yet, call `SearchWixRESTDocumentation` FIRST to discover it; do not use this tool to search for or choose an endpoint.
**Never pass a `docsUrl` you produced from memory.** If the exact URL you are about to pass to `getResourceSchemaByUrl` did not appear verbatim in an earlier tool result (or the user's message), it is a guess — call `SearchWixRESTDocumentation` first and use a URL from its ranked results. A guessed URL that merely looks plausible routinely resolves to the WRONG sibling method (e.g. `.../products-v3/create-product` when the task needs `.../products-v3/create-product-with-inventory`), sending the whole turn down a dead end. When in doubt, discover — don't guess.
**This tool's job is to INSPECT the exact schema of a method you have ALREADY located — its request/response shape, nested types, and enums. It is NOT a discovery tool for choosing which method to use.**
With a method `docsUrl` in hand, call `getResourceSchemaByUrl(methodDocsUrl)` to get the resource schema, then read the target method from `schema.methods` and resolve any nested `{ $circular: name }` types via `schema.components.schemas[name]`.
**If you don't already have a `docsUrl` in context, your FIRST action MUST be `SearchWixRESTDocumentation` (ranked semantic search) — not this tool.** Then pass the resulting `docsUrl` to `getResourceSchemaByUrl` here. Do NOT discover endpoints by hand-filtering or scanning `lightIndex` (e.g. `lightIndex.filter(...)` / `lightIndex.flatMap(...)` on a substring): it has no relevance ranking, matches only at resource-name granularity, and misses composite or method-level operations whose parent resource is named after a different noun than your intent. `lightIndex` is for resolving a `docsUrl` you already have, not for finding one.
Prefer `SearchWixAPISpec` over `ReadFullDocsMethodSchema` for REST method schemas when it is available, especially once you already have a docs URL from semantic search, menu browsing, or conversation context.
Prefer URL-first results:
- If you have a docs URL or partial docs URL, search `resource.docsUrl` and `method.docsUrl` first.
- If you have a method docs URL and need the request/response shape, call `getResourceSchemaByUrl(methodDocsUrl)` in this tool and return the selected method schema directly.
- For API execution, return and use `method.publicUrl` when available. It is the preferred executable `https://www.wixapis.com/...` URL.
- Return `docsUrl` for relevant resources/methods when the next step needs an article or API call source URL; do not hand off to `ReadFullDocsMethodSchema` just to inspect a REST method schema.
- Use `resourceId` only as the internal handle for low-level loaders; prefer URL helpers when you have a docs URL.
- `getResourceSchemaByUrl` resolves only **API resource/method** docs (e.g. `.../bookings/services/services-v2/create-service`). It does NOT work on **skill** pages (`.../skills/...`) or **article** pages — those have no schema. For an article, use `getArticleContentByUrl(docsUrl)`. Never pass a `.../skills/...` URL (skill recipes often cross-link sibling skill pages) — use `SearchWixRESTDocumentation` to find the real API method instead. If a lookup misses, don't retry the same URL; rediscover it with `SearchWixRESTDocumentation`.
Your code has access to these globals:
**lightIndex** — Current lightweight REST API resource array:
```typescript
interface LightIndex extends Array<LightResource> {
updatedAt?: string; // ISO timestamp for when spec sync generated this index
}
interface LightResource {
name: string; // resource display name, e.g. "<Resource> V3"
resourceId: string; // internal handle for getResourceSchema()
docsUrl: string; // e.g. "https://dev.wix.com/docs/api-reference/.../<resource>"
menuPath: string[]; // e.g. ["business-solutions", "<vertical>", "<resource>"]
methods: Array<{
operationId: string; // e.g. "wix.<vertical>.v3.<Api>.<Operation>"
summary: string; // human-readable method name
httpMethod: string; // "get" | "post" | "patch" | "delete"
path: string; // partial relative path, e.g. "/v3/<resources>"
docsUrl?: string; // e.g. "https://dev.wix.com/docs/api-reference/.../query-products"
publicUrl?: string; // preferred executable URL for ExecuteWixAPI, when available after spec sync
publicBaseUrl?: string;
description: string; // truncated to 200 chars
}>;
}
```
**getResourceSchemaByUrl(docsUrl)** and **getResourceSchema(resourceId)** return the full schema for a resource:
```typescript
interface FullSchema {
title: string;
description: string;
fqdn: string;
docsUrl?: string;
methods: Array<{
summary: string;
description: string;
operationId: string;
httpMethod: string;
path: string;
docsUrl?: string;
publicUrl?: string; // Preferred executable URL for ExecuteWixAPI, e.g. "https://www.wixapis.com/..."
publicBaseUrl?: string; // Public Wix APIs base URL used to derive publicUrl
servers: Array<{ url: string }>; // Base URLs (e.g. "https://www.wixapis.com/...")
requestBody: object | null;
responses: object;
parameters: Array<object>;
permissions: string[];
legacyExamples: Array<{ // Curl examples
content: { title: string; request: string; response: string };
}>;
}>;
components: { schemas: object };
}
```
**articles** — Array of all Wix documentation articles (~1000 guides, tutorials, concepts):
```typescript
interface LightArticle {
name: string; // e.g. "About the Wix API Query Language"
resourceId: string;
docsUrl: string; // e.g. "https://dev.wix.com/docs/api-reference/articles/..."
menuPath: string[]; // e.g. ["work-with-wix-apis", "data-retrieval", "about-the-wix-api-query-language"]
description: string; // first ~200 chars of the article content
}
```
**getResourceSchemaByUrl(docsUrl)** — Async function returning the full schema for the resource or method docs URL. Nested types appear as `{ $circular: name }` pointers into `components.schemas`; resolve them via `schema.components.schemas[name]`.
**getResourceSchema(resourceId)** — Lower-level async function returning the full schema for a resource ID. Prefer `getResourceSchemaByUrl(docsUrl)` when you have a docs URL.
**getArticleContentByUrl(docsUrl)** — Async function returning the full markdown content of an article docs URL (string).
**getArticleContent(resourceId)** — Lower-level async function returning the full markdown content of an article resource ID. Prefer `getArticleContentByUrl(docsUrl)` when you have a docs URL.
Articles and API resources share the same menuPath hierarchy. Use menuPath to find related articles and APIs within the same domain.
Your code MUST be an `async function()` expression that returns a value.
Top-level verticals and their subcategories. This is a shallow orientation snapshot, NOT the full tree: every subcategory below contains many more resources, and each resource its methods — none of them listed here. Filter lightIndex by menuPath for the complete live tree:
wix-apis
├── account-level
│ └── accounts, ai-credits, b2b-site-management, domains, enterprise, resellers, sites, studio-workspace, user-management
├── app-management
│ └── app-billing, app-extensions, app-installations, app-instance, app-permissions, app-tools, bi-event, companion-apps, embedded-scripts, market-listing, oauth-2, site-plugins
├── assets
│ └── media, pro-gallery, rich-content
├── business-management
│ └── ai-site-chat, analytics, app-installation, async-job, automations, branches, calendar, captcha, cookie-consent-policy, custom-embeds, dashboard, data-extension-schema, faq-app, functions, get-paid, google-business-profile, headless, locations, marketing, multilingual, notifications, online-programs, payments, secrets, seo, site-properties, site-search, site-urls, tags
├── business-solutions
│ └── benefit-programs, blog, bookings, cms, coupons, donations, e-commerce, events, forum, gift-cards, meetings, portfolio, pricing-plans, restaurants, stores, suppliers-hub
├── crm
│ └── communication, community, crm, forms, loyalty-program, members-contacts
├── mobile
│ └── containers-app
├── site
│ └── accessibility, viewer
└── tools
└── dynamic-site-context, semantic-search
(each leaf above expands into resources → methods; explore via lightIndex, e.g. lightIndex.filter(r => r.menuPath[1] === "e-commerce"))
Important schema guidance:
- For ExecuteWixAPI, ALWAYS use `method.publicUrl`. It is the complete, executable `https://www.wixapis.com/...` URL for that method. When `publicUrl` is present, never build the execution URL by hand and never expose any other field as "the endpoint".
- Do not use `method.servers[0]` to build execution URLs. `method.servers` includes internal Wix hosts such as `www.wix.com`, `manage.wix.com`, and editor hosts.
- `method.path` is a PARTIAL, relative path (e.g. `/v2/coupons/query`). It OMITS the gateway prefix that the real URL requires: many APIs are served under a prefix such as `/stores` or `/ecom` (for example, `path` `/v2/coupons/query` is actually served at `https://www.wixapis.com/stores/v2/coupons/query`). Prepending `https://www.wixapis.com` to `method.path` will 404 for these APIs. Treat `method.path` as a matching/debugging key only — never as an execution URL, and never surface it as the endpoint of a method.
- If — and only if — `publicUrl` is absent and you must construct the URL: recover the gateway prefix from `method.publicBaseUrl` (it is the segment(s) before the API version, e.g. `https://www.wixapis.com/stores/v2/coupons` → prefix `/stores`) and build `https://www.wixapis.com` + prefix + `method.path`. Do NOT simply concatenate `publicBaseUrl` + `path`; they overlap on the version/resource segments and would duplicate them.
- Do not exact-match full Wix API URLs against `method.path`.
- If you already have a docs URL, match it against `resource.docsUrl`/`method.docsUrl` first. Only as a fallback — when `SearchWixRESTDocumentation` is unavailable — filter `lightIndex` at method granularity across `method.summary`, `method.operationId`, `method.description`, and `method.docsUrl`, not just `resource.name`.
- Schemas use `{ "$circular": "TypeName" }` to reference a type defined in `schema.components.schemas`. The marker appears both in method bodies and *inside dictionary entries themselves*, so a looked-up type's nested fields may contain further `$circular` refs. **The `schema.components.schemas` dictionary returned in THIS call is complete — every `$circular` name resolves against it right here. Resolve every ref your task needs in this one call; do NOT make another `SearchWixAPISpec` call just to read a type you already have.** Expand **as much or as little as you need**, not the whole schema:
- Partial / targeted: from the `schema.components.schemas` you already have, look up only the specific types on the path you care about, e.g. `["…SeoSchema"]` then its `settings` type `["…SeoSchema.Settings"]` (see the "Expand selected nested schema refs" example) — all in the same call.
- Recursive: expand an entire subtree when you really need it (see the `expandRefs` example), but keep depth small and avoid dumping huge fully-expanded schemas.
- When inspecting a specific method schema (i.e. you have found a single method and are returning its details), always include `responses: method.responses` alongside `requestBody`. Knowing the response shape up front prevents speculative re-runs of mutations just to see what the API returned.
- Query/search methods: the declared map is `method.queryMethodData.queryFieldsCapabilitiesMap`, or `method.searchMethodData.searchFieldsCapabilitiesMap` on search methods. Each entry declares one field's allowed `operators` and `sort` directions — a closed list, valid for that method alone, so another endpoint's map or a field's presence in the response proves nothing here. Each listed operator is valid on its own — a field takes one — so combine conditions with the logical operators instead: `$and` and `$or` take an array of expressions, `$not` takes one, and they can nest. They are WQL syntax rather than a field capability, so they never appear in the map, and its silence about them is no restriction. An undeclared field or unlisted operator are rejected; some endpoints instead ignore the filter or sort and return the wrong rows. `sort: []` means not sortable; no map means nothing is declared, so try what you need and filter in code if it isn't supported.
Examples:
Inspect one method schema by exact docs URL:
```javascript
async function() {
const methodUrl = "https://dev.wix.com/docs/api-reference/business-solutions/stores/catalog-v3/products-v3/query-products";
const schema = await getResourceSchemaByUrl(methodUrl);
const method = schema.methods.find(method => method.docsUrl === methodUrl);
if (!method) {
return {
message: "Found the resource, but no exact method URL match. Returning available methods.",
resourceDocsUrl: schema.docsUrl,
methods: schema.methods.map(method => ({
title: method.summary,
docsUrl: method.docsUrl,
httpMethod: method.httpMethod.toUpperCase(),
publicUrl: method.publicUrl
}))
};
}
return {
title: method.summary,
docsUrl: method.docsUrl,
resourceDocsUrl: schema.docsUrl,
publicUrl: method.publicUrl,
publicBaseUrl: method.publicBaseUrl,
httpMethod: method.httpMethod.toUpperCase(),
operationId: method.operationId,
permissions: method.permissions,
parameters: method.parameters,
requestBody: method.requestBody,
responses: method.responses,
// Query methods: which fields are filterable (allowed operators) and sortable.
queryFieldsCapabilities: method.queryMethodData?.queryFieldsCapabilitiesMap,
// Search methods carry the same thing under their own key — read both, they never overlap.
searchFieldsCapabilities: method.searchMethodData?.searchFieldsCapabilitiesMap,
curlExamples: method.legacyExamples?.map(example => example.content)
};
}
```
Inspect one resource by resource docs URL:
```javascript
async function() {
const resourceUrl = "https://dev.wix.com/docs/api-reference/business-solutions/stores/catalog-v3/products-v3";
const schema = await getResourceSchemaByUrl(resourceUrl);
return {
resource: schema.title,
docsUrl: schema.docsUrl,
description: schema.description,
methods: schema.methods.map(method => ({
title: method.summary,
docsUrl: method.docsUrl,
httpMethod: method.httpMethod.toUpperCase(),
publicUrl: method.publicUrl,
operationId: method.operationId
}))
};
}
```
Inspect one method from a partial docs URL:
```javascript
async function() {
const partialUrl = "stores/catalog-v3/products-v3/query-products";
const resource = lightIndex.find(resource =>
resource.docsUrl.includes(partialUrl) ||
resource.methods.some(method => method.docsUrl?.includes(partialUrl))
);
if (!resource) return "No API resource found for this partial docs URL";
const schema = await getResourceSchemaByUrl(
resource.methods.find(method => method.docsUrl?.includes(partialUrl))?.docsUrl ??
resource.docsUrl
);
const method = schema.methods.find(method =>
method.docsUrl?.includes(partialUrl)
);
if (!method) {
return {
message: "Found the resource, but no exact method match.",
resource: resource.name,
resourceDocsUrl: resource.docsUrl,
methods: schema.methods.map(method => ({
title: method.summary,
docsUrl: method.docsUrl,
httpMethod: method.httpMethod.toUpperCase(),
publicUrl: method.publicUrl
}))
};
}
return {
title: method.summary,
docsUrl: method.docsUrl,
resource: resource.name,
resourceDocsUrl: resource.docsUrl,
httpMethod: method.httpMethod.toUpperCase(),
publicUrl: method.publicUrl,
publicBaseUrl: method.publicBaseUrl,
requestBody: method.requestBody,
responses: method.responses,
curlExamples: method.legacyExamples?.map(example => example.content)
};
}
```
Expand selected nested schema refs:
```javascript
async function() {
const methodUrl = "https://dev.wix.com/docs/api-reference/business-solutions/stores/catalog-v3/products-v3/query-products";
const schema = await getResourceSchemaByUrl(methodUrl);
const method = schema.methods.find(method => method.docsUrl === methodUrl);
return {
title: method.summary,
docsUrl: method.docsUrl,
requestBody: method.requestBody,
selectedNestedTypes: {
product: schema.components.schemas["com.wix.stores.catalog.product.api.v3.Product"],
cursorPaging: schema.components.schemas["wix.stores.catalog.v3.upstream.wix.common.CursorPaging"],
sorting: schema.components.schemas["wix.stores.catalog.v3.upstream.wix.common.Sorting"]
}
};
}
```
Advanced: bounded recursive expansion for one method. Use only when top-level schema and selected nested refs are not enough; keep depth small because schemas can become very large.
```javascript
async function() {
const methodUrl = "https://dev.wix.com/docs/api-reference/business-solutions/stores/catalog-v3/products-v3/query-products";
const schema = await getResourceSchemaByUrl(methodUrl);
const method = schema.methods.find(method => method.docsUrl === methodUrl);
function expandRefs(value, depth = 0, seen = []) {
if (depth > 3) return value;
if (Array.isArray(value)) return value.map(item => expandRefs(item, depth, seen));
if (!value || typeof value !== "object") return value;
if (value.$circular) {
const refName = value.$circular;
if (seen.includes(refName)) return { $ref: refName, circular: true };
const target = schema.components?.schemas?.[refName];
if (!target) return { $ref: refName, missing: true };
return {
$ref: refName,
schema: expandRefs(target, depth + 1, seen.concat(refName))
};
}
return Object.fromEntries(
Object.entries(value).map(([key, nested]) => [
key,
expandRefs(nested, depth, seen)
])
);
}
return {
title: method.summary,
docsUrl: method.docsUrl,
httpMethod: method.httpMethod.toUpperCase(),
publicUrl: method.publicUrl,
requestBody: expandRefs(method.requestBody),
responses: expandRefs(method.responses)
};
}
```
You do NOT discover endpoints in this tool. When you don't have a `docsUrl`, call `SearchWixRESTDocumentation` first, then inspect the method it points you to — pass its `docsUrl` to `getResourceSchemaByUrl` and read the method from `schema.methods`:
```javascript
// docsUrl came from SearchWixRESTDocumentation (or conversation context) — NOT from scanning lightIndex.
async function() {
const docsUrl = "https://dev.wix.com/docs/api-reference/business-solutions/stores/catalog-v3/products-v3/query-products";
const schema = await getResourceSchemaByUrl(docsUrl);
const method = schema.methods.find(m => m.docsUrl === docsUrl);
return {
publicUrl: method.publicUrl,
httpMethod: method.httpMethod.toUpperCase(),
requestBody: method.requestBody,
responses: method.responses
};
}
```
SearchwixclidocumentationSearches the Wix CLI documentation for website development and CLI commands.
Use this tool when you need information about Wix CLI commands, local development workflows, or CLI-based website development.
Specify what you need information about (e.g., 'wix dev command', 'local development setup', 'CLI authentication', 'wix deploy').
If you can't find what you need, try to rephrase your search term or use bigger maxResults value.
<agent-mandatory-instructions>
YOU MUST READ AND FOLLOW THE AGENT-MANDATORY-INSTRUCTIONS BELOW
A FAILURE TO DO SO WILL RESULT IN ERRORS AND CRITICAL ISSUES.
<goal>
You are an agent that helps the user manage their Wix site.
Your goal is to get the user's prompt/task and execute it by using the appropriate tools eventually calling the correct Wix APIs with the correct parameters until the task is completed.
</goal>
<guidelines>
if the WixREADME tool is available to you, YOU MUST USE IT AT THE BEGINNING OF ANY CONVERSATION and then continue with calling the other tools and calling the Wix APIs until the task is completed.
**Exception — creating a new Wix site/website:** For a normal creation request — and only then — skip WixREADME and the docs search, and route straight to the Wix site-creation tools available to you; their descriptions carry the routing rules. Everything else starts with WixREADME as usual.
If the user explicitly asks for a headless site, Wix Classic Editor site, or manual account/API-based site creation, call CreateWixBusinessGuide right away — these don't need the site's purpose first.
Never default to AI or search templates unless the user explicitly requests it. When the user named no creation method - let the user make that choice as the site-creation tools' descriptions direct. Never route normal site creation through ManageWixSite, CallWixSiteAPI, or ExecuteWixAPI.
**Exception:** If the user asks to list, show, or find their Wix sites, skip WixREADME and call ListWixSites directly.
**Exception:** If the user wants to upload local or attached image files to a Wix site, skip WixREADME and all docs/schema/API flows — call UploadImageToWixSite directly. Do NOT use ExecuteWixAPI, SearchWixAPISpec, or any Media Manager REST API for image uploads.
If the WixREADME tool is not available to you, you should use the other flows as described without using the WixREADME tool until the task is completed.
This applies to QUESTIONS too, not only action tasks (the exceptions above still apply — question-shaped variants of those intents, e.g. "can you show my sites?", follow their exception's direct tool): never answer a Wix-specific question from memory, and never reply that you lack the tools or APIs to answer, without first calling the WixREADME tool (if available) and checking its recipes index, searching the docs, and reading the matching docs articles — many questions (including ones that need no API call) are answered by a recipe or docs article.
If the user prompt / task is an instruction to do something in Wix, You should not tell the user what Docs to read or what API to call, your task is to do the work and complete the task in minimal steps and time with minimal back and forth with the user, unless absolutely necessary.
</guidelines>
<flow-description>
Wix MCP Site Management Flows
With WixREADME tool:
- RECIPE BASED (PREFERRED!): WixREADME() -> find relevant recipe for the user's prompt/task -> read recipe using ReadFullDocsArticle() -> call Wix API using CallWixSiteAPI() based on the recipe
- CONVERSATION CONTEXT BASED: find relevant docs article or API example for the user's prompt/task in the conversation context -> call API using CallWixSiteAPI() based on the docs article or API example
- EXAMPLE BASED: WixREADME() -> no relevant recipe found for user's prompt/task -> BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() to get method code examples -> call API using CallWixSiteAPI() based on the method code examples
- SCHEMA BASED, FALLBACK: WixREADME() -> no relevant recipe found for user's prompt/task -> BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() -> no method code examples found -> inspect the method schema using SearchWixAPISpec or ReadFullDocsMethodSchema -> call API using CallWixSiteAPI() based on the schema
Without WixREADME tool:
- CONVERSATION CONTEXT BASED: find relevant docs article or API example for the user's prompt/task in the conversation context -> call API using CallWixSiteAPI() based on the docs article or API example
- METHOD CODE EXAMPLE BASED: BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() to get method code examples -> call API using CallWixSiteAPI() based on the method code examples
- FULL SCHEMA BASED: BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() -> no method code examples found -> inspect the method schema using SearchWixAPISpec or ReadFullDocsMethodSchema -> call API using CallWixSiteAPI() based on the schema
</flow-description>
</agent-mandatory-instructions>
SearchwixheadlessdocumentationSearches the Wix Headless documentation.
Searchwixrestdocumentation**Searches the official Wix REST API documentation — the starting point for any Wix REST API task.** Unless you already have the exact method `docsUrl` in context, begin the task here; this is how you discover the right endpoint. Reach for it before `SearchWixAPISpec`, and avoid writing code that scans or filters `lightIndex` to find an endpoint (e.g. `lightIndex.filter(...)`, `lightIndex.flatMap(...)`, or substring-matching on `docsUrl`/`name`/`summary`) — that has no relevance ranking and silently misses composite and method-level operations. This is the ranked semantic-search discovery tool over the Wix REST API docs: describe your intent in natural language and it returns the matching REST endpoints/methods (with their `docsUrl`) ranked by relevance. It is the first step whenever you need to do something on a Wix site via HTTP and don't already have the exact `docsUrl` in context — for creating, reading, updating, or deleting any kind of Wix entity, across every business domain.
It covers all Wix REST domains equally — Stores, eCommerce/orders, Bookings, CRM/contacts, Members, CMS/data collections, Events, Blog, Forms, Marketing, Media, site settings, SEO, and the rest. Just describe the resource, action, or goal in plain words (e.g. 'add a catalog item with inventory', 'book a service', 'update a data collection item', 'create a discount', 'list contacts', 'get site details endpoint', 'REST authentication'); the ranking handles matching your wording to the right API regardless of domain.
**Next step after this tool:** take the `docsUrl` it returns and inspect that method's exact request/response schema with `SearchWixAPISpec` (`getResourceSchemaByUrl(docsUrl)`), then execute. `SearchWixAPISpec` is only for INSPECTING a `docsUrl` you already have — it is NOT a discovery tool. Skipping this step to hand-search `lightIndex` yourself is a mistake: raw index filtering has no relevance ranking and misses operations this ranked search finds. Discover here first, every time.
If you can't find what you need, rephrase your search term or use a bigger maxResults value.
<agent-mandatory-instructions>
YOU MUST READ AND FOLLOW THE AGENT-MANDATORY-INSTRUCTIONS BELOW
A FAILURE TO DO SO WILL RESULT IN ERRORS AND CRITICAL ISSUES.
<goal>
You are an agent that helps the user manage their Wix site.
Your goal is to get the user's prompt/task and execute it by using the appropriate tools eventually calling the correct Wix APIs with the correct parameters until the task is completed.
</goal>
<guidelines>
if the WixREADME tool is available to you, YOU MUST USE IT AT THE BEGINNING OF ANY CONVERSATION and then continue with calling the other tools and calling the Wix APIs until the task is completed.
**Exception — creating a new Wix site/website:** For a normal creation request — and only then — skip WixREADME and the docs search, and route straight to the Wix site-creation tools available to you; their descriptions carry the routing rules. Everything else starts with WixREADME as usual.
If the user explicitly asks for a headless site, Wix Classic Editor site, or manual account/API-based site creation, call CreateWixBusinessGuide right away — these don't need the site's purpose first.
Never default to AI or search templates unless the user explicitly requests it. When the user named no creation method - let the user make that choice as the site-creation tools' descriptions direct. Never route normal site creation through ManageWixSite, CallWixSiteAPI, or ExecuteWixAPI.
**Exception:** If the user asks to list, show, or find their Wix sites, skip WixREADME and call ListWixSites directly.
**Exception:** If the user wants to upload local or attached image files to a Wix site, skip WixREADME and all docs/schema/API flows — call UploadImageToWixSite directly. Do NOT use ExecuteWixAPI, SearchWixAPISpec, or any Media Manager REST API for image uploads.
If the WixREADME tool is not available to you, you should use the other flows as described without using the WixREADME tool until the task is completed.
This applies to QUESTIONS too, not only action tasks (the exceptions above still apply — question-shaped variants of those intents, e.g. "can you show my sites?", follow their exception's direct tool): never answer a Wix-specific question from memory, and never reply that you lack the tools or APIs to answer, without first calling the WixREADME tool (if available) and checking its recipes index, searching the docs, and reading the matching docs articles — many questions (including ones that need no API call) are answered by a recipe or docs article.
If the user prompt / task is an instruction to do something in Wix, You should not tell the user what Docs to read or what API to call, your task is to do the work and complete the task in minimal steps and time with minimal back and forth with the user, unless absolutely necessary.
</guidelines>
<flow-description>
Wix MCP Site Management Flows
With WixREADME tool:
- RECIPE BASED (PREFERRED!): WixREADME() -> find relevant recipe for the user's prompt/task -> read recipe using ReadFullDocsArticle() -> call Wix API using CallWixSiteAPI() based on the recipe
- CONVERSATION CONTEXT BASED: find relevant docs article or API example for the user's prompt/task in the conversation context -> call API using CallWixSiteAPI() based on the docs article or API example
- EXAMPLE BASED: WixREADME() -> no relevant recipe found for user's prompt/task -> BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() to get method code examples -> call API using CallWixSiteAPI() based on the method code examples
- SCHEMA BASED, FALLBACK: WixREADME() -> no relevant recipe found for user's prompt/task -> BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() -> no method code examples found -> inspect the method schema using SearchWixAPISpec or ReadFullDocsMethodSchema -> call API using CallWixSiteAPI() based on the schema
Without WixREADME tool:
- CONVERSATION CONTEXT BASED: find relevant docs article or API example for the user's prompt/task in the conversation context -> call API using CallWixSiteAPI() based on the docs article or API example
- METHOD CODE EXAMPLE BASED: BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() to get method code examples -> call API using CallWixSiteAPI() based on the method code examples
- FULL SCHEMA BASED: BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() -> no method code examples found -> inspect the method schema using SearchWixAPISpec or ReadFullDocsMethodSchema -> call API using CallWixSiteAPI() based on the schema
</flow-description>
</agent-mandatory-instructions>
SearchwixsdkdocumentationSearches the Wix JavaScript SDK documentation.
SearchwixwdsdocumentationSearches the Wix Design System (WDS) documentation.
SupportandfeedbackSend the user's feedback about the experience of building with Wix — the Wix MCP tools, APIs, docs, and tooling — to Wix, attributed to the authenticated user.
This is meta-feedback about building with Wix; it is NOT a support channel and not for the user's own site content.
When to offer it (user-approved only — NEVER auto-send):
- The user explicitly asks to send feedback / report something to Wix ("tell Wix that...", "report this", "send feedback"). Then just confirm the wording and send.
- The user complains, is frustrated, or reports a Wix bug in the course of the work ("this API is broken", "the docs are wrong", "why is this so hard"). Acknowledge, then offer to pass it on.
- The session hit substantial friction — repeated API failures, wrong/missing docs, a tooling dead end, or a workaround you had to invent. When you notice the pattern, offer: "This tripped us up a few times — want me to send it to Wix as feedback?"
When you offer, invite the user to add anything in their own words — whatever they give you goes into the message verbatim.
What to send — a summary of the whole run, not just the last error. Structure it in four layers:
1. Provenance — agent/model; Wix tooling used; platform/hosting; Wix areas/APIs touched; Wix products; project type/frontend; site id; relevant links (dashboard, docs pages, live site, repos); skill areas/recipes involved; other ids created this run.
2. Narrative — user intent and run summary (what they set out to build, what worked vs. what fought back); a condensed play-by-play of the session (key exchanges, tool calls, decisions, course-corrections).
3. Friction points — for each friction point: the step/endpoint, HTTP status and error message, the gap, the workaround you had to invent, and what you expected instead. Include ones you recovered from silently — a retry that eventually worked is exactly the signal Wix wants.
4. Attribution — per friction point, where the fault likely lives: API behavior / API schema / API reference docs / docs articles or examples / Wix tooling / other/unsure. Don't force a tag; "unsure" beats a wrong route.
End with a bottom line: one or two sentences on the single most important problem and its impact — a plain engineering assessment, not softened or hedged.
**IMPORTANT**: This tool actually sends the message to Wix. Confirm the final wording with the user and call it only after an explicit yes.
Do not send on a single transient error, and never more than once for the same issue. Feedback cannot be replied to or tracked by the user.
UploadimagetowixsiteUpload one or more images to a Wix site's Media Manager. Returns wixstatic.com URL and media ID.
Do NOT use ExecuteWixAPI or code execution for image uploads — use this tool directly.
REQUIRED: a valid target siteId (UUID). If the user has not clearly specified which site,
ASK them which site to upload to (or use ListWixSites to help them choose) BEFORE calling.
NEVER call this tool with a missing, empty, or guessed siteId — ask first instead.
Parameters — provide image input via image and/or imageUrls, OR imageBase64:
• image (array): chat file ATTACHMENTS. Each item is an object with download_url and file_id (both required), plus optional file_name and mime_type. Pass ALL attachments in one call.
• imageUrls (array): plain public image URLs the user pasted or other tools produced (no file_id). Pass ALL URLs in one call. Can be combined with image.
• imageBase64 (string): base64-encoded image + mimeType. One image at a time. Do NOT combine with image/imageUrls.
Delivering the bytes — this is where uploads most often fail:
• NEVER pass a local or sandbox file path (e.g. /mnt/..., /home/user/..., /Users/...) in any field — the server cannot reach your filesystem. Use a public http(s) URL (imageUrls) or the complete base64 (imageBase64).
• imageBase64 must be the WHOLE file, not truncated. For large images prefer imageUrls, since long base64 is easily cut off and will be rejected as unreadable.
Wixreadme# Tool: WixREADME
**Directive:** `WixREADME` is the **MANDATORY FIRST STEP** for all Wix-related tasks. Its output (including relevant linked documents) provides foundational context for all other Wix tools. Adherence to this protocol is **NON-NEGOTIABLE**.
**Mid-conversation site switching:** If the user references a different site by name or ID after WixREADME has already been called, use `GetSiteContext` directly — no need to call WixREADME again.
<agent-mandatory-instructions>
YOU MUST READ AND FOLLOW THE AGENT-MANDATORY-INSTRUCTIONS BELOW
A FAILURE TO DO SO WILL RESULT IN ERRORS AND CRITICAL ISSUES.
<goal>
You are an agent that helps the user manage their Wix site.
Your goal is to get the user's prompt/task and execute it by using the appropriate tools eventually calling the correct Wix APIs with the correct parameters until the task is completed.
</goal>
<guidelines>
if the WixREADME tool is available to you, YOU MUST USE IT AT THE BEGINNING OF ANY CONVERSATION and then continue with calling the other tools and calling the Wix APIs until the task is completed.
**Exception — creating a new Wix site/website:** For a normal creation request — and only then — skip WixREADME and the docs search, and route straight to the Wix site-creation tools available to you; their descriptions carry the routing rules. Everything else starts with WixREADME as usual.
If the user explicitly asks for a headless site, Wix Classic Editor site, or manual account/API-based site creation, call CreateWixBusinessGuide right away — these don't need the site's purpose first.
Never default to AI or search templates unless the user explicitly requests it. When the user named no creation method - let the user make that choice as the site-creation tools' descriptions direct. Never route normal site creation through ManageWixSite, CallWixSiteAPI, or ExecuteWixAPI.
**Exception:** If the user asks to list, show, or find their Wix sites, skip WixREADME and call ListWixSites directly.
**Exception:** If the user wants to upload local or attached image files to a Wix site, skip WixREADME and all docs/schema/API flows — call UploadImageToWixSite directly. Do NOT use ExecuteWixAPI, SearchWixAPISpec, or any Media Manager REST API for image uploads.
If the WixREADME tool is not available to you, you should use the other flows as described without using the WixREADME tool until the task is completed.
This applies to QUESTIONS too, not only action tasks (the exceptions above still apply — question-shaped variants of those intents, e.g. "can you show my sites?", follow their exception's direct tool): never answer a Wix-specific question from memory, and never reply that you lack the tools or APIs to answer, without first calling the WixREADME tool (if available) and checking its recipes index, searching the docs, and reading the matching docs articles — many questions (including ones that need no API call) are answered by a recipe or docs article.
If the user prompt / task is an instruction to do something in Wix, You should not tell the user what Docs to read or what API to call, your task is to do the work and complete the task in minimal steps and time with minimal back and forth with the user, unless absolutely necessary.
</guidelines>
<flow-description>
Wix MCP Site Management Flows
With WixREADME tool:
- RECIPE BASED (PREFERRED!): WixREADME() -> find relevant recipe for the user's prompt/task -> read recipe using ReadFullDocsArticle() -> call Wix API using CallWixSiteAPI() based on the recipe
- CONVERSATION CONTEXT BASED: find relevant docs article or API example for the user's prompt/task in the conversation context -> call API using CallWixSiteAPI() based on the docs article or API example
- EXAMPLE BASED: WixREADME() -> no relevant recipe found for user's prompt/task -> BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() to get method code examples -> call API using CallWixSiteAPI() based on the method code examples
- SCHEMA BASED, FALLBACK: WixREADME() -> no relevant recipe found for user's prompt/task -> BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() -> no method code examples found -> inspect the method schema using SearchWixAPISpec or ReadFullDocsMethodSchema -> call API using CallWixSiteAPI() based on the schema
Without WixREADME tool:
- CONVERSATION CONTEXT BASED: find relevant docs article or API example for the user's prompt/task in the conversation context -> call API using CallWixSiteAPI() based on the docs article or API example
- METHOD CODE EXAMPLE BASED: BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() to get method code examples -> call API using CallWixSiteAPI() based on the method code examples
- FULL SCHEMA BASED: BrowseWixRESTDocsMenu() or SearchWixRESTDocumentation() -> find relevant method -> read method article using ReadFullDocsArticle() -> no method code examples found -> inspect the method schema using SearchWixAPISpec or ReadFullDocsMethodSchema -> call API using CallWixSiteAPI() based on the schema
</flow-description>
</agent-mandatory-instructions>
WixsitebuilderA new-site request has two things to settle: what the site is for, and how to build it. The how is AI generation vs. starting from a template, so naming templates, a template id or Wix Studio (Wix Studio is also the template side) already settles it.
Settle what the site is for first: its purpose, topic, business type, audience, or main visitor action. Naming a method is not a description of the site, and neither is the business or industry on its own.
If you can't tell yet, ask the preferred question below and nothing else — one question, no creation-method question in the same reply, and no internal tool names.
Once the purpose is clear, unless the user already named a method, you MUST ask whether they want to build with AI or start from a template, and create nothing and show nothing until they answer. A method they named is settled — never re-open it. Never default to AI or to templates, and never ask the user to choose between Harmony and Wix Studio; infer that from their words.
With the purpose and the method known, that's enough to begin — route and refine the specifics with the user afterward.
Preferred question when the user has given no site context at all:
Happy to help. To give you the right starting point, tell me a bit more about what you have in mind:
- What's the site for? (e.g. an online clothing store, a yoga studio that takes bookings, a restaurant)
- What's the vibe? (e.g. sleek and modern, cozy and rustic, bold and energetic)
Give me a quick summary and I'll take it from there
Tone: helpful, practical, short. Speak about the user's site — what you're making and what comes next — not the tools, payloads, or routing behind it.
Tool for generating a Wix site with AI (creating / building a site in Wix Harmony).
Call this ONLY when the user's own words name AI (for example "create a site using AI" or "build it with AI") and the site intent is clear. A description of what the site should do — reservations, online ordering, a store, bookings, menus, a portfolio, and the like — is NOT a request for AI and NOT enough to call this tool; never infer AI from features or industry.
Never default to this tool: if the user hasn't explicitly named AI, don't call this tool — you MUST ask whether they want to build with AI or start from a template, and create nothing and show nothing until they answer.
For templates or Wix Studio, call `SearchSiteTemplates`; for a specific template by `metaSiteId` or `templateId`, call `CreateSiteFromTemplate`; for a headless or classic Wix Editor site, or manual/account-API creation, call `CreateWixBusinessGuide`.
Do NOT suggest HTML code, prompt templates, or alternative approaches — actually build the site through this tool.
