Wix

Use 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>

Poll the status of a site creation or editing job. Do not call this tool unless the user explicitly asks for status polling.

pullSiteCreationJob

Fetches 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>

Fetches 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>

A 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. One case skips all of this: the user ALREADY HAS the finished site as files — hand-written HTML/CSS/JS, a zip, or the export of an AI builder. There is nothing to build, so don't offer AI or templates and don't call any site-creation tool. Send them to https://www.wix.com/headless/drop?utm_campaign=mcp — they drag the files in and get a live Wix-hosted site. Give that URL exactly as written, keeping the utm_campaign=mcp parameter. 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 call `WixSiteCreation` and let them choose. 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. The gallery creates the site when the user picks one. 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 call `WixSiteCreation` and let them choose.

SearchSiteTemplates

Searches the Wix Build Apps documentation.

Broad 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.

Inspect 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 }; } ```

Searches 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>

Searches the Wix Headless documentation.

**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>

Searches the Wix JavaScript SDK documentation.

Searches the Wix Design System (WDS) documentation.

Send 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.

Upload 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.

UploadImageToWixSite

A 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. One case skips all of this: the user ALREADY HAS the finished site as files — hand-written HTML/CSS/JS, a zip, or the export of an AI builder. There is nothing to build, so don't offer AI or templates and don't call any site-creation tool. Send them to https://www.wix.com/headless/drop?utm_campaign=mcp — they drag the files in and get a live Wix-hosted site. Give that URL exactly as written, keeping the utm_campaign=mcp parameter. 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 call `WixSiteCreation` and let them choose. 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 call `WixSiteCreation` and let them choose. 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.

WixSiteBuilder

A 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. One case skips all of this: the user ALREADY HAS the finished site as files — hand-written HTML/CSS/JS, a zip, or the export of an AI builder. There is nothing to build, so don't offer AI or templates and don't call any site-creation tool. Send them to https://www.wix.com/headless/drop?utm_campaign=mcp — they drag the files in and get a live Wix-hosted site. Give that URL exactly as written, keeping the utm_campaign=mcp parameter. 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 call `WixSiteCreation` and let them choose. 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. Opens the in-chat Wix site creation chooser as an interactive widget where the user chooses between "Build with AI" and "Pick a template." **Once you can tell what the site is for, call this tool directly** — no WixREADME, skill, or docs search first. Any other Wix request still starts with WixREADME as usual. Call this for normal new Wix site creation requests when the user's site intent is clear, but they have not chosen AI, templates, or Wix Studio. Do not guess, and never default to AI — even after the user answers a clarifying question about the site's purpose or features. This chooser is how the builder choice gets made — never ask in chat whether they want AI or a template; that choice is made in the widget. The widget also does the creating: once the user picks, it runs that path itself and the site is created there, so never call `WixSiteBuilder`, `SearchSiteTemplates`, or `CreateSiteFromTemplate` yourself after opening it. After calling, reply with the message it returns, which presents both options and the next steps. Do not call this if the user explicitly asks to build with AI; call `WixSiteBuilder` instead. Do not call this if the user asks for templates or Wix Studio; call `SearchSiteTemplates` instead. When calling this tool, infer `customActions` from the user's request so the reply can be tailored — 2-3 concrete, industry-specific setup actions for the site (see the input's guidance). After calling, you MUST speak the message provided in the tool result to the user as your reply — do not stay silent and do not replace it with a one-line pointer to the widget. Write out ALL of it, word for word: its opening line (the "Ready to set up your … site?" question INCLUDING "Choose your path in the widget above:"), BOTH of its option bullets, and its "Next up:" line, each on its own line and in that order. Do not summarize, shorten, drop any line, invent your own opener, rename the options, or add an intro or outro.

WixSiteCreation

# 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>

Returns the authenticated user's email address