DEV Community: t ra

Standby, Not Stopped: What Happens to Site Edits When Orivox's MCP Server Idles

t ra — Mon, 02 Nov 2026 09:56:33 +0000

By Zahi Raifer, founder of Orivox. I have spent 23 years building software in AI, Python, .NET and databases.

People who connect their own AI to a hosted service tend to ask the same nervous question sooner or later: what happens when the connector goes quiet? Is the site now half-edited, or locked, or out of step with what the AI thinks it did?

At Orivox, a small business owner can build and edit their website from their own Claude through a remote MCP server. Their AI does the reasoning and our side carries out the work. This piece explains what "idle" means for that connector. I am not going to describe timers or queues we don't have. I want to walk through the design decisions that make a quiet connector harmless, and say plainly where those decisions stop.

The short version: there is nothing to go stale

The most important property of the Orivox MCP server is something it doesn't have. It keeps no session state between calls. There is no in-memory conversation, no half-built edit waiting in a buffer, and no per-user object that has to be kept warm. Any instance can serve any request.

That changes what "idle" means. In many systems an idle connection is a liability. Something is holding context, and that context can expire, drift, or vanish in a restart. Our connector holds nothing worth losing, so a gap between two calls is just a gap. Whether the next tool call arrives in two seconds or two days, it starts from the same place: who is calling, which project, which operations.

Restarts work the same way. Our engineering notes put it in one line: because the MCP server keeps no session state, a restart costs at most the one request in flight. An idle server that restarts loses nothing, because nothing was in flight.

Where the real state lives

If the connector holds no state, the state has to live somewhere, and it should live somewhere durable. Orivox gives every piece of state exactly one owner:

Each project's Git history belongs to the editing service. Every edit turn is a commit, and the original site is committed as a baseline before the first edit.
Accounts, credits, plans and publishing belong to the web app. The web app also issues the OAuth tokens and decides quota.
The project lock lives in Redis, shared, and is held for a whole turn by whoever is writing: an edit, a manual commit, a site copy or a background job.

The MCP server owns none of these. It holds no database write credentials. It calls the editing service and the web app over HTTP, and it reads a single read-only view to identify the caller. So "what happens to my site while the connector idles" has a simple answer: the site sits in Git, in its last committed version, exactly as it was after the last completed turn.

Why a pause can't leave a half-applied edit

The second worry is the more interesting one. Suppose your AI sends a batch of changes and then everything goes quiet. Could the page be stuck halfway?

The answer comes from how edits are expressed. Neither the in-house planner nor the owner's Claude writes files. They send a list of operations from a fixed grammar of 14 verbs, such as set_text, add_class, move_before and remove. Each operation addresses an element by its data-ai-id. The MCP edit tool takes the same 14 operations, and the editing service applies a list from Claude exactly as it applies one from our own planner: the same checks, the same Git commit, the same transcript.

Python applies the whole list, runs its deterministic checks, saves the page, commits the change to the project's Git repository and records the turn. Only the server decides whether a turn is saved. The unit of change is the turn, and a turn ends in a commit.

The guardrails also don't care how long the AI was away. Every save passes checks that don't depend on the model behaving well. A save may never empty a live page. Moved text must keep every sentence. A whole-page rewrite must keep every section the owner didn't name. The business logo and the contact form's privacy notice are protected. And when the AI's next edit is based on a page, that page must be read as it is now, not as the AI remembers it. That last rule matters most after a long pause. If something changed in the meantime, the edit is built on the current page.

The lock: one writer, not a held door

A natural fear about locks is that an idle client might sit on one forever. The Orivox design scopes the lock to a turn. It is held for a whole turn by whoever is writing, so two changes can never interleave on the same site. The lock covers the work of writing, not a user's presence. A connector that is only connected, with no write under way, has nothing to hold.

The same rule covers the web app. It never runs Git against a project. When it writes files itself, it takes the lock, writes, and asks the editing service to commit. There is always a single, consistent version of every site, whether the last change came from the owner's chat in our web app, from their own Claude, or from a background job.

Retries after a quiet spell

When a connection comes back after a pause, AI clients like to retry. A retry is dangerous if the first attempt actually succeeded. Orivox makes one specific promise here: a completed write is always reported as done. If usage metering fails after the files are written, the tool still returns success, so the AI never retries and creates a duplicate.

Standby, literally

There is one more sense of "standby" in our stack, and it is the literal one. Production runs on two identical servers, and only one takes traffic at a time. The other is a ready standby. A release goes to the standby first and is checked there before it takes a single customer request. Rolling back means moving traffic back. Customer site files sit on shared storage that both servers mount, so a switch moves no files.

This is where the stateless connector earns its keep. Since any instance can serve any request, moving traffic from one server to the other doesn't strand a user's session, because there is no session to strand. The site, its Git history and the lock all live in places both servers share.

Two more rules keep quiet periods quiet. Services restart only when we release, so operating-system updates never bounce the application on their own schedule. And we watch the connector from the outside: every five minutes a probe walks it end to end, from discovery and sign-in to a real tool call, and emails an incident report on any failure and on recovery. An idle connector is still a monitored one.

What this design doesn't claim

I want to be precise about the limits. Statelessness doesn't mean the AI on the other end remembers what it did. That memory belongs to the owner's own Claude conversation, and Orivox doesn't control it. What we do provide is a durable record to check against: the editing service keeps the transcript of turns, and every turn is a Git commit that can be restored. If you come back to a project after a week and aren't sure what your AI changed, the answer is in the history, not in anyone's memory.

The takeaway

An MCP server that "idles" is only a risk when it is holding something. We built the Orivox connector to hold nothing: no session, no write credentials, no copy of your site. The site lives in Git, the business rules live in the web app, writes are serialized by a turn-scoped lock, and every save passes the same deterministic checks. When your AI goes quiet, your site stays exactly where the last completed turn left it.

If you want to try editing a real business site from your own AI, you can start at orivox.pro.

About the author: Zahi Raifer is a software developer with 23 years of experience in AI development, Python, .NET and databases, and the founder of Orivox, an AI website builder for Hebrew and right-to-left languages.

I Built an MCP Server That Lets Claude Create and Publish Real Websites

t ra — Mon, 07 Sep 2026 04:52:02 +0000

I have been building websites for more than 20 years, and AI has completely changed how quickly we can create them.

But I kept running into the same problem: generating code is only one part of building a real website.

After the AI writes the HTML, you still need to manage files, hosting, SSL, domains, forms, databases, and future edits. For someone who is not a developer, this final part can be more difficult than creating the website itself.

That is why I built the Orivox MCP website builder.

What is Orivox MCP?

Orivox MCP connects Claude directly to the Orivox website platform using the Model Context Protocol.

Instead of opening another AI website builder, purchasing AI credits, and learning a new editor, you can describe the website you want directly inside Claude.

For example:

Create a modern website for a local moving company in Haifa. Add a services section, customer reviews, a WhatsApp button, and a contact form.

Claude understands the request, while Orivox performs the actual website operations.

It creates the project, generates the website files, provides a working preview, and allows Claude to continue making changes.

Editing the website through conversation

After the first version is created, you can continue talking naturally:

Make the header smaller.
Change the colors to dark blue and white.
Add another service.
Replace the main image.
Create an About page.
Connect my domain.
Add a registration form and database.

The important difference is that the conversation is connected to a real website project. Claude is not simply returning a block of code that you must copy somewhere else.

When a change is requested, Orivox updates the actual website.

Claude does the thinking

I designed the system so that each side has a clear role.

Claude handles the conversation, planning, content, and decisions. Orivox handles the website infrastructure: creating and editing files, hosting the project, publishing it, securing it, connecting domains, and managing website features.

You use your own Claude account, so Orivox does not charge you for separate AI calls or sell additional AI credits.

This also means that you can keep working in an interface you already know instead of moving between an AI chat, a code editor, a hosting dashboard, and a domain-management panel.

Why use MCP for this?

MCP gives an AI assistant controlled access to external tools.

A normal chatbot can explain how to publish a website. An MCP-connected assistant can actually perform the authorized steps.

That distinction is what interested me most.

I did not want Claude to only generate instructions such as “upload this file to your server.” I wanted it to safely create the project, update it, and prepare it for real visitors.

The user remains in control and connects their Orivox account through an authorization process. Claude can then access the website-building tools associated with that account.

Who is it for?

I think this approach is particularly useful for:

Small-business owners who do not want to learn web design.
Developers who want to create and test websites quickly.
Freelancers building websites for customers.
Claude users who prefer working through conversation.
Anyone who wants a real hosted website rather than another code snippet.

It will not replace every development workflow. Complex applications can still require developers, custom architecture, and manual testing.

But for business websites, landing pages, prototypes, and many database-backed projects, speaking to an AI can be a much simpler starting point.

Try it

The project is still evolving, and I am continuing to improve it based on real usage.

You can learn more and connect Claude here:

https://orivox.org/mcp

I would genuinely appreciate feedback from other developers experimenting with MCP. I am especially interested in hearing which website operations you would want an AI assistant to handle automatically.