Webstudio MCP is more than an API wrapper
Most MCP servers only call an API. Webstudio MCP edits a real Webstudio project, opens the result in a browser, and uses vision to check its own work.

Most MCP servers turn API endpoints into tools an AI can call. That is useful, but it is not enough to edit a website.
An API can let an agent create a record or change a field. It cannot tell the agent where a component belongs, which breakpoint owns a style, whether the page still works on mobile, or whether you can keep editing it later.
We did not get there by adding MCP to an API. We completely reengineered Webstudio's core runtime so the visual editor and MCP can read, change, and build the same project. The agent edits the real site, not a simplified copy made for AI.
The core runtime is the important part
Take a simple request: “Add a pricing section.” Dropping some HTML onto the page is easy. Adding a proper Webstudio section is harder. It has to use valid components, respect the site’s styles and breakpoints, connect any dynamic data, and stay editable on the Canvas.
That is what the MCP tools are for. The agent can add a complete section, reuse the components and tokens already in the project, move elements safely, and connect data without treating the site like a pile of unrelated records.
Before it makes a change, the agent can inspect the project and check what it is allowed to do. Afterward, it can validate the change and open the result in a browser.
When the agent is done, you can open the same project in the visual editor and carry on. There is no separate AI version of the site.
Why Webstudio MCP runs locally
Webstudio MCP runs through the Webstudio CLI on your computer. The CLI can build the site, run a preview, control a browser, take screenshots, and work with local files.
Running all of that for every user in our cloud would take a lot of infrastructure. We would need to give every active agent its own cloud computer and pay for the CPU, memory, storage, browsers, and network traffic. We could hide that cost in a subscription, but you would still pay for it.
Running locally uses the computer you already have. It also keeps the project configuration and credential on your machine. Webstudio still handles the project API, validation, builds, and publishing, so an internet connection is still required for cloud projects.
You do not need to set this up by hand. Install an app such as Codex, Claude Code, Cursor, or VS Code, say “Use Webstudio CLI,” and the agent can install what it needs, link the project, and manage the local process.
There is still a tradeoff: you are giving that app access to your computer, and the work uses your CPU, memory, disk, browser, and network. You choose the app and the project permissions. Webstudio adds dry runs, validation, and review steps so you can see what will change before it happens.
This is not tied to one AI company. Any capable MCP client can use the same tools.
Vision lets the agent see what it built
A change can be technically valid and still look bad. A heading can wrap at the wrong word, a card can leak out of the mobile viewport, or a desktop fix can quietly break tablet.
Webstudio keeps the preview ready while the project changes. The agent can make a small edit, render it, inspect mobile and desktop with vision, and fix the result right away.
Vision catches visible mistakes while layout checks catch mechanical problems such as overflow and broken images. Neither can decide whether the design is good. That judgment still belongs to the designer.
What you can do with it
The useful jobs rarely stop at one element. An agent can:
- Build or reorganize pages without losing their settings.
- Clean up styles, tokens, and breakpoints across the site.
- Connect a CMS or API and bind its data to components.
- Organize assets, run audits, and publish when you ask it to.
The point is simple: the agent can work across the whole project, not just call one API endpoint. JSON-LD and animations are good examples.
Webstudio checks the JSON-LD
JSON-LD is a good job for an agent. It is verbose, and most of its values already exist in the page or CMS.
The agent can inspect the page, decide whether it contains an article, product, event, or another type of content, and create matching JSON-LD in the page head. Values such as the title, author, price, or breadcrumbs can come from the page or CMS, so the structured data stays in sync when the content changes.
Structured data has a fixed vocabulary. An agent can write code that looks correct but uses a category search engines do not recognize. Nothing visibly breaks; search engines may simply ignore it.
Webstudio checks the JSON-LD instead of trusting whatever the model writes. It can catch malformed JSON, missing fields, unknown types, and properties that do not belong. The agent can run an SEO audit, fix the findings, and check the final result in the rendered page. It writes the tedious part; Webstudio tells it what needs fixing.
Animations should remain editable
It is easy for an agent to add an animation by injecting a script. The problem arrives later, when you want to change it.
Webstudio MCP can use the same animation components and CSS keyframes as the visual editor. You can ask for a staggered card reveal or a scroll-linked video, then adjust or remove it on the Canvas without digging through generated JavaScript.
The agent can preview the animation and refine it with vision, but you still decide whether the motion feels right. Webstudio animation components automatically respect reduced-motion preferences.
Use the agent and visual editor together
I do not see the visual editor and the agent as competitors. You might ask the agent for a first version, adjust the layout on the Canvas, tweak one card yourself, and then ask the agent to repeat that change across twenty pages.
That only works if both of you are editing the same project. This is the point of Webstudio MCP: use the agent when it is faster, use the visual editor when you want direct control, and move between them without starting over.
This is the broader direction for Webstudio. The same core runtime should work visually, through code, and with agents. You should be able to choose the fastest way to make each change without rebuilding the site in another tool.
