---
title: "Discussion on \"We gave our MCP server an undo button\" | Hashnode"
description: "Discussion on \"We gave our MCP server an undo button\". Letting an AI agent change your product's settings is only reasonable if you can take it all back. So every change our MCP server makes goes into a run that can be undone in one step. This is how it w"
url: "https://hashnode.com/posts/we-gave-our-mcp-server-an-undo-button/6ad836b459e12396314dd304"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [We gave our MCP server an undo button](https://privatrak.hashnode.dev/we-gave-our-mcp-server-an-undo-button?utm_source=hashnode&utm_medium=feed)

Letting an AI agent change your product's settings is only reasonable if you can take it all back. So every change our MCP server makes goes into a run that can be undone in one step. This is how it w

Oct 21 · 10 min read · privatrak.hashnode.dev  
Read the article

-   [#ai](https://hashnode.com/tag/ai)
-   [#mcp](https://hashnode.com/tag/mcp)
-   [#webdev](https://hashnode.com/tag/webdev)
-   [#developer](https://hashnode.com/tag/developer)
-   [#saas](https://hashnode.com/tag/saas)

## Written by

[Quentin Wendegass](https://hashnode.com/@quentinw)

@quentinw · Bangkok, Thailand

  
[View profile](https://hashnode.com/@quentinw)

Software geek and founder of Privatrak

Software geek and founder of Privatrak: no-code, cookieless product analytics. Writing about what I learn building it.

## Responses 4

Markdown supported · ⌘↵ to post

[Kartik N V J K](https://hashnode.com/@kartik-nvj)

[Oct 22](https://hashnode.com/posts/we-gave-our-mcp-server-an-undo-button/6ad836b459e12396314dd304/comment/6ad9f6c433fb0a7d0ff0dbab)

Making the preview the real undo, rolled back, is the line I'm taking with me. A separate preview path would drift from the real one sooner or later. My worry is from the agent side: if someone undoes a run mid-session, the agent still believes its funnel exists. When its next write gets refused for joining an undone run, does the error say why, so it doesn't just open a fresh run and put everything back?

[Quentin Wendegass](https://hashnode.com/@quentinw)

[Oct 25](https://hashnode.com/posts/we-gave-our-mcp-server-an-undo-button/6ad836b459e12396314dd304/comment/6ad9f6c433fb0a7d0ff0dbab#reply-6adde2f24c3bcf1186999326)

It says why, but not quite enough. The write gets a 409 with its own error code and "this setup run has been undone and takes no more changes; start a new one". So the agent knows the run is gone, but the message actually nudges it towards a fresh run, and nothing tells it the user undid those changes on purpose. I'll change it to say what was undone and to check with the user before redoing any of it. Thanks, that's a real gap.

[Mike Dabydeen](https://hashnode.com/@firelinks)

[Oct 21](https://hashnode.com/posts/we-gave-our-mcp-server-an-undo-button/6ad836b459e12396314dd304/comment/6ad8a032d9343ecc8bb271be)

Your runs table already measures something most agent setups can't: how often people take the agent's work back. The share of runs undone within a couple of weeks is close to what DORA calls change fail rate, the ratio of deployments that need immediate intervention, usually a rollback or a hotfix. Split by client and by tool, it would show whether one assistant gets funnels wrong more often than rules, which tells you where the server's instructions need work.

I'd count the quiet fixes too. A setup someone repaired by hand never shows up as an undo, but your conflict check already spots it: a human edit to a field a run set. Tracking both keeps a low undo rate from hiding a lot of manual rework.

[Quentin Wendegass](https://hashnode.com/@quentinw)

[Oct 21](https://hashnode.com/posts/we-gave-our-mcp-server-an-undo-button/6ad836b459e12396314dd304/comment/6ad8a032d9343ecc8bb271be#reply-6ad8bd089ad6f051d0fec7d0)

Yeah, we've been thinking about that too, change fail rate is a good way to put it. Counting the quiet fixes is a good catch, the undo rate alone would look better than reality.