In July 2025, Replit's AI agent deleted a company's production database during a code freeze, then told the user the data couldn't be recovered. It could. Replit had a rollback, and the user restored everything from a checkpoint. The agent just didn't know the feature existed. Two lessons from that story shaped what we built: the agent has to know that undo exists, and people have to be able to undo without asking the agent.

We build Privatrak, a cookieless analytics tool. Its MCP server lets Claude, Cursor or Codex do more than read your analytics. They can set them up: feature rules that name what people click, funnels, dashboards, and marking click problems as fixed. 17 of its 44 tools change something.

Most MCP servers with write access rely on the client asking before each call. We wanted one more thing: after an agent has made twenty changes, you see all of them in one list and undo them in one step, without losing what you or a colleague changed in between.

Asking first isn't enough

Claude asks before it runs a tool marked destructive. That's good, and we set our tool annotations carefully for it. But it depends on the server labelling its tools honestly, which is why the MCP specification tells clients to treat those labels as untrusted unless the server is trusted. And it protects one call at a time, while an agent's work isn't one call.

Setting up a project takes a dozen or twenty writes: rules, a funnel built on those rules, a dashboard whose widgets query them. Nobody reads the fifteenth confirmation as carefully as the first. Security people call this confirmation fatigue, and OWASP's list of risks for AI agents includes it. And the mistakes in a setup rarely show in a single call. They show later, when a dashboard counts the wrong thing.

What you need then isn't another confirmation. You need to see everything the agent did as one unit, and to take that unit back. Developers have that for code in version control. Product settings usually have nothing like it.

Undo has to live in the server

Coding agents already have undo. Claude Code and Cursor keep checkpoints you can go back to. But both only cover files the agent edited. Claude Code's docs say changes made through commands aren't tracked, and Cursor's say restoring a checkpoint doesn't undo a database migration the agent ran. Once an agent calls an API, the client can't take it back. Only the service behind the API can.

MCP doesn't help here either. The specification asks clients to keep a person in the loop and to confirm tool calls, but it has nothing for transactions or rollback. So if you want undo for what an agent does in your product, you build it into your MCP server. That's what the rest of this article is about.

One task, one run

The unit of undo is a setup run. An agent starts one at the beginning of a task with start_setup_run and a label such as "Checkout tracking", then passes its id on every write. The run answers the question "what did the assistant do?"

Two rules make it reliable:

• Nothing happens outside a run. A write tool called without a run id starts a run itself and returns its id. Even an agent that ignores the instructions leaves a trail that can be undone.

• Runs that changed nothing don't clutter the list. If the API rejects a write, the tool deletes the run it had just started for it.

In the API, a write joins a run through a header, X-Setup-Run-ID, not a body field. DELETE has no body, and all fourteen write operations should join the same way. A write without the header takes exactly the code path it always took, so adding runs changed nothing that already worked.

The runs also show up in the dashboard under Settings, as AI assistant changes. The person who connected the assistant doesn't need the assistant to undo what it did.

Record before and after, in the same transaction

Every write that belongs to a run is saved together with a record of what it changed: the state before and the state after. Both are saved in one database transaction, so either both happen or neither does. The run is locked meanwhile, so nobody can undo it halfway through a write.

The recorded state is the whole definition: a rule's name and conditions, a funnel's steps, a dashboard with its widgets. Everything undo needs to rebuild it. The database enforces the shape: a creation has no "before", a deletion has no "after".

One detail cost us more time than the rest. Undo later compares these records with what is in the database now. If the same thing can be saved in two ways that mean the same, the comparison fails, and every undo looks like a conflict. So every write saves its input in exactly one form.

Undo walks backwards

Undo replays the run's changes newest first, in one transaction:

• Created becomes deleted.

• Updated gets back the fields the run changed.

• Deleted is recreated, with its original id.

Newest first matters. An agent that created a rule and then renamed it has to unwind the rename before the creation. And if the run created something and later deleted it itself, there is nothing to do for it at all.

The original id matters more than it sounds. Dashboards, funnels and links refer to things by id. A recreated rule even gets its original creation time back, because the order of rules decides which name the journey view shows for a click. Undo should leave the project reading exactly as before, not just something equivalent.

Afterwards the run is marked as undone and its report is stored. Asking again returns the same report, and a write that tries to join an undone run is refused.

The undo starts with the agent's last change and works back to its first. The funnel you renamed stays, and everything else goes.

Never overwrite someone else's work

This was the hardest decision. Between the agent's run and the undo, people keep working. Someone renames a widget the agent made, or fixes a rule's condition. Undo must not destroy that.

So every change is checked before it is reverted:

• Undoing a creation requires the thing to still be exactly what the run created.

• Undoing an update requires every field the run changed to still hold the run's value. Fields the run didn't touch may have changed since. They are none of its business.

• A dashboard the run created that now holds someone else's widgets is not deleted.

• Recreating something that would go over the plan's limits is skipped, not forced through.

When a check fails, that one change is skipped and reported with the reason, and the rest of the run is still undone. We considered stopping the whole undo instead. But then one widget someone renamed would keep an agent's entire setup in place. Skipping and reporting gives people the undo they asked for, minus exactly the things they have since made their own.

What counts as someone's work was a decision too. Moving or resizing a widget doesn't count. Someone who drags an agent's widget aside hasn't made it theirs, and deleting it destroys nothing they did.

The preview is the real undo, rolled back

You want to see an undo before it happens. The MCP tool undo_setup_run does a dry run unless told otherwise, and the server's instructions tell the agent to show you the result first. In the dashboard, the dialog says "This is what undoing will do. Nothing has been changed yet." before the button.

The preview isn't a separate prediction. It runs the actual undo, every check and every write, inside the transaction, and then rolls the transaction back. A prediction written as separate code drifts away from what undo really does, and then the preview is wrong exactly when it matters. One code path can't disagree with itself.

Say what can't come back

Some things can't be undone exactly, and pretending otherwise is worse than saying so.

In Privatrak, a funnel counts from the day it is created. The per-visitor data that could recount earlier days is deleted every night, for privacy. That has two consequences for undo:

• Undoing a funnel the agent created also deletes the days it has counted since. The preview says how many.

• A funnel the agent deleted comes back with its name and steps, but it counts again from the undo. Its old days are gone, and the report says so.

The rule we took from this: when undo can't be exact, the preview has to say what will be lost, before anyone confirms.

Undo is the last line, not the only one

Undo is what makes write access reasonable, but it sits behind other guards:

• Tools go through our own API. Each tool sends an ordinary request to our existing API, with the same authentication, validation, plan limits and project scoping as any other client. There is no second path to the data, so there is no second set of rules to get wrong.

• Write access is a fixed list. A read-only connection can reach a fixed list of API endpoints. Write access adds exactly the endpoints the write tools need, and nothing else. Tests fail if the tools and the lists disagree, in either direction.

• People choose at sign-in. Which projects the connection may see, and whether it may only read or also make changes.

• Every call names its project. The server keeps no "current project" that one chat could switch for another.

• The hints are honest. Creating isn't destructive. Updating, deleting and undoing are, so Claude asks before them.

When we submitted Privatrak to Claude's connector directory, the undo made one more thing possible: a test plan that calls all 44 tools on a shared review account and ends by undoing everything it changed.

If you build this yourself

1. Pick the unit: one task, one run. Make every write join a run, even when the agent forgets to start one.

2. Record the whole state before and after, in the same transaction as the write, saved in one fixed form so you can compare it later.

3. Undo newest first, in one transaction, and recreate deleted things with their original ids.

4. Check every change for conflicts. Skip and report; never force, and never give up on the whole run.

5. Make the preview the real undo, rolled back.

6. Say what can't come back, before it is lost.

7. Put undo where people are: in the tool for the agent, and in your product's UI for everyone else.

Privatrak's MCP server works with Claude, Cursor and Codex. Our docs show how to connect it.

He was right. For visitors in the US we were counting some people twice, every day, around dinner time. The reason is obvious in hindsight and was invisible before: we had never decided what a "day" is.

How we count people without a cookie

A cookie is a label stuck on a browser. Every page view carries it, so counting unique visitors is easy.

We don't store anything on the visitor's device, so we compute an identifier on the server from things every request already contains:

visitor_id = HMAC(daily_key, IP address + browser + site)

The same person on the same device produces the same identifier on every page view, so we count them once. We never keep the raw IP address or browser string, only the hash.

The daily_key is what keeps this private. If it never changed, the identifier would be a stable fingerprint that follows someone for months, which is exactly what cookie rules exist to prevent. So the key changes once a day. After the change, yesterday's identifiers can't be matched to today's.

What we hadn't thought about: "once a day" means "at some clock time". We had picked midnight UTC without realising it was a choice.

Midnight UTC is not midnight

Midnight UTC arrives at very different times of day depending on where your visitors are:

(The ranges are the two sides of daylight saving time.)

For a European audience that moment is the middle of the night, so almost nobody is browsing and almost nobody gets split. For a US audience it lands in the early evening. Someone reads your pricing page at 7:50 pm, goes to dinner and comes back at 8:10 pm. The key changed at 8:00 (in winter it is 7:00). Same person, new identifier, two visitors.

That is why a tester in the US saw more visits than expected, and why a tester in Europe would never have noticed. We can't give you a percentage, because it depends on how long your visitors stay, how many come back the same evening and when your traffic peaks. What we can say is what happened after the fix: the difference was big, and his funnels improved as well.

The funnels make sense once you see it. A funnel follows one visitor from step to step, so someone who looked at the pricing page at 7:50 pm and signed up at 8:10 pm was two visitors, and neither of them ever completed the funnel. Once the day was cut in the right place, his funnel numbers also matched what the insights in the dashboard showed.

Who this affects

Not everyone. It takes distance: if your visitors live close to the timezone where the day is cut, almost nobody is browsing when it turns over, and nobody gets split. It bites when visitors are far from that boundary. For a product like ours, where customers and visitors can be in every timezone, any single fixed boundary can land in somebody's evening, so one boundary for everyone can't be right.

A site whose visitors are mostly in one region can fix it by choosing that region's timezone. A site with a truly worldwide audience can't make it go away, because some part of the world is always in the evening when the day turns over. The best you can do is cut the day where your own traffic is lowest.

It wasn't only visitors

When we looked, the visitor key was only one of two places that used the UTC day. The other was every daily bucket in the reports. We had two separate pieces of code that each decided independently that a day starts at midnight UTC. They happened to agree with each other, so the mistake didn't show up as a disagreement anywhere.

For a New York project, the bar labelled "Tuesday" actually held Monday 8 pm to Tuesday 8 pm. So the problem wasn't just a few extra visitors. Every day in the report was shifted. A newsletter sent at 9 pm on Monday would have appeared to work on Tuesday.

The fix: decide once, in one place

We gave every project a timezone and made it decide both things: the moment the key changes and the edges of every daily bucket. Now there is only one value, so the two can't disagree.

It looked like a small change. It wasn't.

A counted day is frozen. We delete the raw rows of a day once we've counted it, for privacy. So when someone changes a project's timezone, we can't re-count old days on the new boundary; the rows that would answer it are gone. A timezone change applies from then on, and the first day after a change is longer or shorter than 24 hours.

Daylight saving makes days 23 or 25 hours long. An hourly chart has 25 buckets on the day the clocks go back and 23 when they go forward. We label each bucket with the UTC offset at that moment, so there's one bucket per real hour.

This is not only an analytics bug

Once we'd seen it, we started spotting the same bug elsewhere. Plenty of software never decides whose day it is or when things reset, and just uses whatever clock the server has. Places we'd look:

• Daily quotas and rate limits that reset at midnight UTC, so users elsewhere get their fresh allowance at an odd hour.

• Streaks and daily goals. A streak that breaks because the server's midnight arrived mid-evening is a classic.

• "Today" in dashboards and reports, especially when you compare it with another system's day, such as your payment provider's.

• Daily budgets and billing periods that pace or reset by an account's day.

• Scheduled digests and cron jobs. "Every day at 9 am" in whose 9 am?

• Anything that rotates an identifier on a schedule: session IDs, rate-limit buckets, A/B test bucket seeds. If it changes at a fixed time, it splits whoever is mid-action, exactly like ours did.

• Daylight saving, for everything that assumes a day has 24 hours.

What we'd do differently

The first time DATE(timestamp) or "reset at midnight" shows up in code, ask whose midnight it is. We didn't, and we found out when a tester in another timezone noticed.