Your agent needs to read and write Wix: list a customer's sites, update a product, upload media, publish a page. Wix ships a hosted MCP server and a full REST platform, and both can reach the same endpoints. That last part is what makes the choice non-obvious. Wix's MCP server is not a catalog of typed business tools; it is a documentation index plus a generic REST proxy. That design decision changes the calculus in ways the other tools in this series do not. Here's how to pick.
Wix has three distinct machine surfaces, and conflating them is the most common source of wasted engineering time on Wix agents. Two of them are MCP servers with completely different audiences.
The Wix MCP server is built and maintained by Wix and reachable remotely at https://mcp.wix.com/mcp. Wix documents "http" and "sse" as supported transport types, plus a local npx configuration for clients without remote MCP support, which requires Node.js 19.9.0 or higher.
Authentication has two documented paths. The default is a browser-based OAuth flow triggered on first connect. Wix also documents an API key plus Wix account ID configuration, called out specifically for tools like n8n and A2A that cannot complete an interactive consent flow. Product overview: the official Wix MCP Server page.
Every published Wix site also exposes its own site MCP server, aimed at visitors rather than developers. It needs no authentication, mints its own visitor tokens through GenerateVisitorToken, and exposes tools like GetBusinessDetails, SearchInSite, and a visitor-scoped CallWixSiteAPI.
That surface is for agents shopping on a site, not for agents operating a site. It is out of scope for this comparison, and you should not plan a back-office agent around it.
The Wix REST API covers the platform: eCommerce, Stores, Bookings, CMS and Wix Data, Media, CRM and Contacts, Forms, Marketing, plus account-level Sites, Accounts, and Domains APIs. A GraphQL surface and a JavaScript SDK sit over the same endpoints.
Auth is identity-based. Wix recognizes site visitors, site members, Wix users, Wix apps, and API key admins as distinct calling identities, each with its own token acquisition path.
Four dimensions decide this for a production agent: what the tools actually do, what auth model each path forces, what you still operate yourself, and which workloads each one fits.
Scalekit's Wix MCP connector page enumerates 22 tools on the live server. Eleven of the twelve in Wix's published table are present, plus eleven the table does not mention, including wixmcp_wixsitebuilder, wixmcp_executewixapi, wixmcp_uploadimagetowixsite, and wixmcp_getsuggesteddomains. The published table lags the server.
Read that table again with one thing in mind: there is no wix_create_product tool. There is wixmcp_callwixsiteapi, whose required parameters include url, method, siteId, and sourceDocUrl — the last of which the tool description insists must be a real Wix docs URL the agent actually read.
So a single business operation is a chain. Search the REST docs, read the method schema, then call the endpoint. Three tool calls and three round trips of documentation into context before one product is updated.
The chain is not free. Every step is a model decision, which means every step is a place the agent can pick the wrong endpoint or hallucinate a body shape. Wix has clearly seen this: wixmcp_executewixapi carries a required hasMutations boolean that the agent must set true for any create, update, delete, import, or upload, even when the mutation is incidental to an inspection.
A guardrail parameter that depends on the model self-reporting intent is a guardrail with a soft floor. For read-heavy and exploratory work that is an acceptable tradeoff. For a nightly job that writes inventory, it is not.
Wix MCP breaks the pattern this series has documented elsewhere. It is not OAuth-only, which means the usual "MCP cannot go headless" conclusion does not apply cleanly to Wix. Understanding why OAuth and API keys serve different purposes for AI agents helps frame the tradeoff precisely.
Both MCP auth paths resolve to the same identity class: someone with standing access to a Wix account. Wix API keys can only be created by account owners and co-owners, and Wix states plainly that API keys are not available to third-party Wix apps.
That is the disqualifying constraint. If you sell a Wix app that customers install on their sites, the correct model is app instance OAuth: you exchange your app ID, app secret, and the site's instance_id for a Bearer token via Create Access Token, valid for four hours. Per-site scope, per-site revocation, no user browser required. The MCP server cannot participate in that model at all.
On the MCP path, Wix owns the tool schemas, the docs index, the endpoint proxy, and the sandbox runtime. That is genuine leverage: when Wix ships a new API, the MCP server can reach it the same day, because the tool is a proxy rather than a hand-written wrapper.
What you still own is everything after the token is issued. Storage, refresh, revocation on disconnect, and tenant isolation stay yours on both paths. So does the site selection problem: wixmcp_callwixsiteapi requires a siteId, and wixmcp_executewixapi can target exactly one siteId per call.
MCP tool schemas change when Wix updates the hosted server, with no version header to pin. Wix's own published tool table is currently eleven tools behind the live surface, which tells you how much notice to expect. The REST API is the stable contract by comparison.
Events are the cleanest split. Wix webhooks require an app registered in the Wix dashboard, deliver JWT-signed payloads, time out at 1250 ms, and can arrive more than once, so handlers must be idempotent. None of that exists on the MCP surface. Rate limiting is real on both paths; Wix returns 429 on throttle and Wix Data enforces separate per-minute read and write quotas tied to the site's premium plan, and MCP tool calls hit the same underlying endpoints.
Pick either path and you end up in the same place: a credential per Wix account, sitting somewhere in your infrastructure, that nobody has assigned an owner to.
An agency product managing 60 client Wix accounts holds 60 credentials. On the MCP path each is an OAuth grant or an account-scoped API key. On the REST path each is an app installation token that expires every four hours and has to be reminted proactively.
Neither path gives you a vault, rotation logic, or a revocation flow. Neither tells you when a client revoked access; you find out from a 401 in the middle of a run, or you do not find out at all because the job failed quietly at 3am. This is exactly the kind of challenge covered in secure token management for AI agents at scale.
Wix API keys are attractive precisely because they are the easy path: no consent flow, no refresh, works headlessly today. They are also created by account owners, scoped by hand, and long-lived by default.
One key, stored in an environment variable, shared across every agent run for every customer, is a single credential whose blast radius is every site it can touch. It works in a demo. It does not survive a security review. The pattern and its risks are explored in depth in credential ownership across agent tool-calling patterns.
Scalekit's Wix MCP connector handles the OAuth flow, per-user token storage, and rotation, so the MCP vs API decision does not change what you build for auth. Credentials stay in the vault and never enter your agent runtime or the model's context.
Scalekit ships the Wix connector as an MCP-backed connector under the slug wixmcp. For direct REST work against endpoints the MCP proxy does not suit, use bring your own connector with the same connected account model.
Create the connection once in the Scalekit dashboard under AgentKit > Connections, then copy the connection name into your code. The string in code must match the dashboard value character for character; a mismatch here is the single most common integration error. Setup steps are in Configure connections.
The user grants Wix access one time. Scalekit stores the resulting credential against your identifier for that user and keeps the connected account's state current, so later runs check status instead of re-prompting. Production redirect handling is covered in Authorize a user.
Before any tool list reaches the model, decide what this user's agent is allowed to reach. actions.langchain.get_tools returns the tools the current user's connected account is authorized to call, filtered further by the names you pass. That is four tools in context, not twenty-two.
listScopedTools returns schemas in the shape Anthropic's tool use API expects, so there is no conversion step. executeTool resolves the user's Wix credential server-side on every call.
Wix is a case where the generic proxy tools make surface reduction load-bearing rather than a nice-to-have. wixmcp_callwixsiteapi and wixmcp_executewixapi can reach any Wix endpoint the credential permits, so exposing them to a read-only reporting agent hands that agent the entire write surface by accident.
Virtual MCP Servers enforce least privilege at the tool level: one server definition per agent role, declaring exactly which connections and which tools are visible. Create it once, not once per user.
The endpoint is static; the identity is not. Confirm the user's connections are still active, mint a short-lived token bound to that user, and pass both to your agent as bearer auth. Full walkthrough: set up and connect a Virtual MCP server.
Wix agents rarely stay single-tool. A storefront operations agent reads Wix orders, posts to Slack, and files a Linear issue when inventory is short. Each connector resolves under the same user identity with its own vaulted credential, and the agent sees one scoped tool surface rather than three full catalogs.
That is also the multi-tenant answer. One Virtual MCP server definition serves every customer; the session token minted before each run is what makes the call act as that customer and no other. The broader challenge of access control for multi-tenant AI agents is relevant to any team scaling beyond a single account.
Scalekit logs each tool call against the connected account that authorized it, so every Wix write traces back to a specific user and a specific grant rather than a service identity. Auth events sit alongside tool call history, with full attribution on who authorized the call and which agent ran it, exportable to your SIEM. See Auth Logs.
This is the part that is painful to retrofit. When a client asks who deleted a product from their site last Tuesday, the answer is a query, not a three-week investigation across application logs that only recorded a shared API key. For teams thinking through this proactively, audit trails for agent auth in B2B SaaS walks through what good looks like.
If your agent is a developer or agency assistant working across your own Wix accounts on exploration, provisioning, and creative work, the hosted MCP server is the better fit. Its documentation tools are a real capability the REST API does not have.
If you sell a Wix app that customers install, react to Wix events, or run deterministic writes on a schedule, build against the REST API with app instance tokens. The absence of app instance auth on the MCP server is an architectural mismatch, not a configuration gap.
Most production Wix agents end up on both: MCP for the interactive surface, REST for the pipeline. The credential problem is identical either way.
Browse the Scalekit Wix MCP connector on the connector page or in the AgentKit docs. The rest of the catalog is in all connectors.
Building something on Wix and want a second opinion on the auth model? Join the Scalekit Slack community, or talk to us if you need help now.
