---
title: "Comment by Mike Dabydeen on \"We gave our MCP server an undo button\" | Hashnode"
description: "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 wee"
url: "https://hashnode.com/posts/we-gave-our-mcp-server-an-undo-button/6ad836b459e12396314dd304/comment/6ad8a032d9343ecc8bb271be"
---

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

Comment [We gave our MCP server an undo button](https://hashnode.com/posts/we-gave-our-mcp-server-an-undo-button/6ad836b459e12396314dd304)

[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.