The Wix MCP: The Good, The Bad and The Ugly (A Real Test)

I spend my working life inside Wix, so when the Wix MCP arrived I wanted to know one thing: does it actually change how the work gets done, or is it another shiny thing that looks good in a demo and falls apart the moment you point it at a real, messy, live website?

So I gave it a real job. Today I used the Wix MCP to rewrite the page titles, meta descriptions and structured data across a fifteen page client site, all through the AI connection rather than clicking around the dashboard. It worked, the site is better for it, and along the way I hit every rough edge the thing has. This post is the honest account. What the Wix MCP is, what it can genuinely do, how to set it up, and then the good, the bad and the properly ugly, all based on what happened in front of me rather than what the marketing says.

If you build or manage Wix sites for a living, this is the piece I wish I had read before I started.

What the Wix MCP actually is

MCP stands for Model Context Protocol. Strip away the jargon and it is a standard way for an AI assistant to talk to an outside service through a fixed set of tools, so the assistant can do real work in that service instead of just describing how you might do it yourself.

The Wix MCP is Wix's own version of that. It is a server, run by Wix, that connects an AI agent to the Wix platform, and Wix documents it in full on the official Wix MCP page in the developer docs. It is available as a built in connector inside Claude, and it also works with other developer tools like Cursor, GitHub Copilot, Windsurf and Claude Code. You can see the supported setups and connect it from the official Wix MCP server page. Once it is connected, the assistant is no longer guessing about Wix from memory. It can look up the real documentation, write code against the real APIs, and, crucially, take real actions on a real site.

Wix groups what it does into four areas, and this is a fair summary of what I actually used today.

First, it can search and read the Wix developer documentation. It pulls the real articles, and it can fetch the exact schema for an API method, meaning the precise fields a request expects.

Second, it can write code for the Wix platform. If you are building something in a headless project or against the Wix SDK, it can generate correct REST or SDK calls rather than plausible looking nonsense.

Third, it can call APIs on your sites. This is the part that turns it from a clever encyclopaedia into a tool. It can apply a discount to a product, add a member of staff to your bookings, send an email to a contact, or, as in my case, rewrite the SEO tags and structured data on a page.

Fourth, it can manage sites, apps and projects at account level. Creating and publishing sites, installing business solutions, scaffolding a new headless project, and so on.

There are a couple of practical facts worth knowing before you start. The recommended way to connect is the remote MCP over an HTTP connection, which the main agents support directly. There is also a local option that runs through npx for tools that do not support remote MCP, and that route needs Node.js version 19.9.0 or higher. Authentication is normally handled by logging into your Wix account interactively, with an API key and account ID option for setups that cannot do an interactive login. Your credentials get cached locally, in a hidden folder in your user directory, so you are not logging in every five minutes.

One thing that confuses people, so I will clear it up early. There is a separate thing called the Wix Site MCP, and it points the other way. The Wix MCP connects your agent to Wix so you can build and manage. The Wix Site MCP is about letting a visitor's AI agent read an individual Wix site. Different tool, different direction. This post is about the first one.

Setting it up and getting connected

The good news is that the setup is not the hard part. If you are working inside an assistant that supports it as a built in connector, you turn it on, you get sent to log into your Wix account, you approve the connection, and you are away. On the developer side, Cursor can install it straight from its MCP library, Claude Code takes a short configuration command, and the npx route exists as a fallback for anything that will not do remote MCP.

I want to be honest about who this is really for, though, because the setup being easy does not make the tool beginner friendly. This is a developer and agency tool. To get value out of the parts that take real actions, you need to understand what a REST API is, what a request body looks like, what a field mask does, and what it means to publish a change versus save it. If none of that means anything to you, the Wix MCP will feel like being handed the keys to a machine with no labels on the buttons. That is not a criticism of the tool, it is just the reality of what it is. The documentation and code parts are genuinely useful to anyone building on Wix. The take real actions parts reward people who already know their way around.

What it can do, in plain terms

Let me make the four areas concrete, because a list of capabilities is meaningless until you see them do something.

On documentation, instead of me digging through dev.wix.com trying to find the right method, I can ask for the exact endpoint that sets a page's SEO tags and get back the real URL, the real HTTP method, and the real shape of the request. That sounds small. It is not. Wix has an enormous API surface, and the difference between a request that works and one that fails is often a single field. Having the tool fetch the actual schema before it builds a call removes a whole category of wasted time.

On writing code, if you are building a headless storefront or wiring up bookings, it will produce the SDK or REST calls to do it, grounded in the current documentation rather than a training snapshot that might be a year out of date.

On calling APIs, this is where the day was spent. I was able to read the current SEO settings of every page on the client site, then write new ones back, then publish them, all through the connection. No dashboard, no copy and paste into fifteen separate SEO panels. For structured data in particular, which I usually treat as a careful custom code job, being able to push a clean, consistent block onto every page in a couple of calls is a genuine step change. If structured data is your weak spot, my Wix schema markup guide covers the why before you worry about the how.

On managing sites, I did not need the account level tools today, but the ability to create, publish and configure sites programmatically is where this heads for anyone running lots of sites.

So that is the pitch, and it is a fair one. Now the real test.

The real test: fifteen pages, one live client site

Here is exactly what I set out to do, so you can judge the rest against a real task rather than a toy example.

The client is a massage and wellness clinic on a classic Wix Editor site. Fifteen indexable pages: a home page, a stack of treatment and location pages, a blog page and a courses page. The brief was straightforward on paper. Rewrite every page title so it sits under Google's sixty character guideline, rewrite every meta description to sit under a hundred and fifty five characters, and clean up the structured data, which was a mess of inconsistent business snippets, a placeholder phone number that had never been replaced, an out of date image link and several pages pointing search engines at the wrong web address for themselves.

Normally that is a long, dull afternoon of clicking through SEO panels. The plan was to do the whole thing through the Wix MCP instead. I did, and it is genuinely faster once you know the traps. Getting to that point, though, meant walking into every one of them first.

The Good

Let me start with what genuinely impressed me, because there is a lot.

The biggest win is bulk action across a whole site. There is a bulk endpoint for setting SEO tags that takes up to a hundred pages in a single call and reports back a result for each one. That meant I could push new titles, new descriptions and a fresh, consistent block of structured data onto twelve service pages in one go, get a clean pass on all twelve, and move on. What would have been an hour of repetitive dashboard work became a couple of calls. For anyone who manages sites at scale, that alone is worth the price of entry.

The second win is accuracy through the documentation tools. Before I sent a single change to the live site, I had the tool pull the exact schema for the method I was about to use, so the request was built against the real field names rather than my memory of them. Wix's own guidance is blunt about this, it tells you not to assemble a request from a half remembered example, and the docs tools are how you avoid it. On a live client site, that caution is not optional, and having it built into the workflow is reassuring.

The third win is that it let me find and fix real problems at a scale I would not normally attempt. Reading every page's current settings surfaced things I might have missed clicking around by eye. Broken canonical links with trailing spaces. Canonicals pointing at a completely different page. A duplicate page created by a typo in a slug. A business snippet with a placeholder phone number sitting live in the code. Once I could see all of it in one place, I could fix all of it in one coordinated push, and rebuild every page onto a single, correct business record with the right address, phone, map location, social profiles and opening hours, plus a service entry naming the exact treatment on each treatment page.

The fourth win is simply speed and consistency. When you change fifteen pages by hand, small inconsistencies creep in. When you generate the changes programmatically and push them in a batch, every page follows the same pattern exactly. The structured data on page one is identical in shape to the structured data on page fifteen. That consistency is good for search engines and good for my sanity.

If the story ended there, this would be an easy recommendation with no caveats. It does not end there.

The Bad

None of what follows makes the tool bad in the sense of not worth using. But these are the sharp edges, and if you do not know they are there, they will cut you.

The first is response truncation. When I asked the tool to list the SEO settings for every page, the responses came back capped at around fifty thousand characters. On a normal site that might be fine. On this site, several pages carried large blocks of structured data, so a single page's settings could run to five or six thousand characters on their own. That meant one listing call only returned a handful of pages before it hit the cap. Worse, the marker that tells you how to fetch the next batch sits at the very end of the response, so when the response overflowed the cap, that marker got cut off too, and I could not continue paging. The fix was to request the pages in very small batches so each response, plus its continuation marker, stayed under the limit. Once I did that, it worked cleanly, but it took a couple of dead ends to work out what was happening, and nothing warned me up front.

The second is that setting SEO tags replaces them in full. This is not a bug, it is how the API is designed, but it is a trap if you do not know it. If a page has ten tags on it, and you send a request to set just the title and the description, you do not update two tags and leave the other eight alone. You replace the whole set with two tags, and the other eight are gone. On the pages that had carefully built structured data, that would have wiped it. So the safe way to change only the title and the description is to read the page's entire current set of tags, swap the two you want to change, and send the whole lot back. Once you understand that, it is fine. If you assume it behaves like editing one field in a form, you will quietly destroy things.

The third is a validation quirk that cost me a few minutes. One page had a disabled structured data block sitting in its settings with empty content. When I tried to write the page back, the whole request was rejected because that empty block was not valid code. An empty structured data script is not valid, even when it is switched off. I had to give it a minimal valid value to get the write accepted. A small thing, but the kind of small thing that stops a live change dead until you spot it.

The fourth is reliability of the connection itself. Over the course of the session the MCP connection dropped and reconnected a few times. It always came back, and it did not lose any work, but it is worth knowing that this is a live network service, not a local tool, and it has the ordinary fragility of anything that talks over the internet. Build your process so that a dropped connection is an inconvenience, not a disaster.

And the fifth, which is less a fault and more a warning, is the learning curve. Every one of the problems above is solvable, and once you have solved it once you know it forever. But the tool does not hold your hand through any of it. The error messages are accurate but terse. You are expected to understand the platform. This is powerful in expert hands and genuinely hazardous in inexpert ones, because the actions it takes are real and they are live.

The Ugly

Now the one that actually caught me out, and the reason I wanted to write this post rather than just tweet that the Wix MCP is great.

On a classic Wix site, a page has two versions of its SEO settings. There is a saved version, which is the draft, and there is a published version, which is what the world sees. When you set a page's tags through the API, there is a flag that decides whether you are publishing the change or just saving it. Publish, and the live page updates. Leave it off, and the draft updates.

Here is the trap. Publishing with that flag updates only the published version. It does not also update the saved draft. And when you read a page's settings back, whether to check your work or to fetch the current tags, you are reading the saved draft, not the published version. So I would push a change live, then read the page back to confirm it, and the read would show the old values, because the read comes from the draft and the draft had not changed. That is confusing enough on its own.

But it gets genuinely ugly. Midway through the job, the client did something completely reasonable. They went into the Wix Editor, corrected a page slug, and hit publish. A normal editor publish pushes the saved draft version of the whole site live. And because I had published my structured data to the live version but had not also written it into the saved draft, that editor publish quietly overwrote my work. The schema I had put live was replaced by the older draft the editor still held. Nothing warned anyone. The client fixed a slug, and in doing so reverted a chunk of my work without ever touching it.

The fix, once I understood it, is simple but essential. Every change has to be written twice. Once to publish it live, and once to the saved draft, so the two versions match. Do that, and an editor publish can no longer revert you, because the draft it pushes live is already the correct one. I now treat this as a hard rule for any SEO change made through the API on a classic Wix site. Write it to both versions, every time, no exceptions.

This is the single most important thing in this entire post. If you take one thing away, take that. The API will happily let you publish a change that a routine editor publish will silently undo, and unless you know to write to both the published and the saved version, you will not find out until you notice your work has vanished. On a live client site, that is the difference between a smooth job and an embarrassing phone call.

What the MCP can and cannot touch

There is one more boundary worth drawing clearly, because it came up repeatedly today and it matters for managing expectations.

The SEO tags API, which is what I was using, controls a specific set of things. The page title, the meta description, the canonical link, the social sharing tags, and the structured data. It controls what search engines and social platforms read in the head of the page. It does a lot, and for on page SEO housekeeping it is exactly what you want.

What it does not touch is the visible content of the page itself. The main heading, the H1 that a visitor sees at the top of the page, is not an SEO tag. Neither are the section headings further down, the ones that say things like What We Do or About Us. Those are page content, and on a classic Wix site they live in the Editor. So if you want to improve a page's H1, or turn a weak section heading like Other Things We Do into something that actually names the treatments, the MCP will not do it for you through the SEO API. That is a job for the Editor.

This is not a shortcoming so much as a division of labour, but it is one people get wrong. The MCP is brilliant at the tags in the head of the page. It has no hand in the words on the face of the page. Plan your work knowing which is which, and you will not waste time looking for a tool that is not there.

Who it is for, and my verdict

So, having actually run it in anger, where do I land.

If you are a single site owner who dips into your Wix dashboard now and then, the Wix MCP is not for you yet, and that is fine. The dashboard exists for a reason and it is safer for occasional changes. The MCP's power is in doing many things, precisely and repeatedly, and its risk is that every action is live and unforgiving. That trade is wrong for a casual user.

If you are a developer building on Wix, the documentation and code tools alone justify connecting it today. Having the real API schemas and current docs a question away, rather than a search away, changes how quickly you can build. That is the safest and most immediately useful part of the whole thing, because reading and writing code is low risk.

If you are an agency or a specialist like me, managing lots of sites and making the same kinds of change again and again, this is where it earns its keep, with eyes open. The bulk actions are a real productivity gain. The ability to audit and fix a whole site's settings in one coordinated pass is something the dashboard simply cannot match. But you have to respect the traps. Full replacement on writes, the truncation and paging behaviour, and above all the published versus saved draft trap. Get those wrong on a live client site and you will cause the exact problems you were hired to fix.

My honest verdict is that the Wix MCP is a serious, useful tool that is clearly built for people who know what they are doing, and it does not pretend otherwise. Today it let me do a fifteen page rebuild of titles, descriptions and structured data faster and more consistently than I could have by hand, and it surfaced problems I would probably have missed. It also tried to bite me three or four times, and one of those bites would have gone unnoticed for weeks if I had not caught it. That is not a reason to avoid it. It is a reason to learn it properly before you point it at anything that matters.

The hard won lessons, in short

If you are going to use the Wix MCP on a real Wix site, here is what today taught me, condensed.

Write every SEO change to both the published version and the saved draft, every single time, or a routine editor publish will silently revert your work.

Remember that setting tags replaces them in full, so read the whole current set, change only what you mean to change, and send it all back.

Expect long listing responses to be truncated, and request pages in small batches so the continuation marker survives.

Use the documentation and schema tools to build every request against the real fields before you send anything to a live site.

Know the boundary. The API owns the tags in the head of the page. It does not own the H1 or the visible headings, which stay in the Editor.

And treat the whole thing with the respect you would give any tool that makes live changes to a client's website. It is fast, it is precise, and it does exactly what you tell it, which is wonderful right up until the moment it is not.

A final word

The Wix MCP is one of the more genuinely useful things Wix has shipped for people who build and manage sites, and it is only going to get more capable. It is not magic, it is not for everyone, and it will not save you from needing to understand the platform. What it will do, in the right hands, is take the repetitive, error prone, click heavy parts of Wix work and make them fast and consistent. That is worth a great deal.

I will keep using it, carefully, and I will keep sharing what I find, the good and the bad and the occasional ugly, because that is more useful than another glowing review that never mentions what went wrong. If you want the running list of what changes on the Wix platform and when, I keep that up to date in my Wix SEO platform changelog.

If you run a Wix site and any of this sounds like a job you would rather hand over, that is what I am here for. Get in touch and I will tell you honestly whether it is a job for the MCP, the Editor, or both.

Wix MCP FAQ

What is the Wix MCP?

The Wix MCP is a server run by Wix that lets an AI assistant work directly with the Wix platform. It is built into Claude as a connector and also works with tools like Cursor, GitHub Copilot, Windsurf and Claude Code. Once connected, the assistant can read the real Wix documentation, write code against the Wix APIs, and take real actions on a live site.

What can the Wix MCP actually do?

Four things. It searches and reads the Wix developer docs, it writes REST or SDK code for the platform, it calls APIs to take real actions on your sites such as updating SEO tags or adding a bookings staff member, and it manages sites, apps and projects at account level like creating and publishing sites.

Can the Wix MCP change a live Wix site?

Yes, and that is both the point and the risk. The actions it takes are real and they hit the live site, so it is a tool for people who understand what they are changing. I used it to rewrite the titles, meta descriptions and structured data across fifteen live pages in one session.

Can it change my page titles, and what about my headings?

It can set titles, meta descriptions, canonical links, social tags and structured data, the things in the head of the page. It does not touch the visible content, so your H1 and your on-page section headings are not controlled by it. Those stay in the Wix Editor.

What is the biggest risk with the Wix MCP?

On a classic Wix site, publishing a change through the API updates only the live version, not the saved draft. So a routine publish from the Editor can quietly push the old draft back over your work. The fix is to write every change to both the live version and the draft so an Editor publish cannot undo it.

Who is the Wix MCP for?

The documentation and code tools help any developer building on Wix. The parts that take live actions reward agencies and specialists making the same changes across many sites. For a casual owner making the odd change, the dashboard is safer.