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

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.