Which integrations are available for this server?

Records HTTP mutations to Stripe API and logs compensating requests (e.g., refunds) for potential reversal of charges.

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@undo checkpoint before running the deployment script" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

undo

by tathagat22

Overview Schema Related Servers Score Discussions

Rust

Local

Your agent's file changes are already recoverable — that's what git is for. But an autonomous agent does far more than edit files: it fires off API calls, charges cards, sends emails, runs migrations, spins up cloud resources. Git can't see any of that, and nothing reverses it.

walkback is the journal and the rollback for everything git can't track.

$ walkback watch                   # arm it — now the agent's changes are reversible

  ... agent edits 15 files, POSTs a charge, sends an email, drops a table ...

$ walkback diff                    # review exactly what it did
$ walkback rollback                # rewind the files
  ✓ rewound to cp001

…and for the things that have no undo anywhere — the charge, the email, the migration, the bucket — the agent records the inverse as it acts, and walkback replays it (dry-run gated, so it never fires blind).

Why not just git?

	git / editor undo	walkback
File changes	✅	✅ (byte-for-byte, or via git)
A `POST` that charged a card	❌	✅ records a refund compensator
A sent email	❌	✅ holds as a draft → true unsend
A dropped table / migration	❌	✅ runs the inverse you record
A cloud resource it created	❌	✅ runs the teardown you record
One audit + one rollback across all of it	❌	✅

Not a git replacement — a second system for everything git can't track.

Related MCP server: checkpointer

Works with any AI agent

walkback is not tied to any model, vendor, or IDE. Every agent changes files on disk, so it meets yours at whichever layer is convenient:

Your setup	Turn it on	Covers
Anything — Cursor, Copilot, Windsurf, Aider, custom scripts, even you	`walkback watch`	Snapshots, then watches the filesystem. Reversible no matter what made the change.
Any CLI agent	`walkback run -- <agent-cmd>`	Wraps the command; snapshots first, reversible after.
Any MCP client	add the MCP server	The agent calls `walkback_checkpoint` / `walkback_compensate` / … itself.
Claude Code	`walkback protect`	Native PreToolUse hook — auto-checkpoints every session, zero effort.

Install

The CLI (walkback binary) works on macOS, Linux, and Windows — no Node required:

cargo install walkback-core                  # via crates.io (installs the `walkback` binary)
brew install tathagat22/tap/walkback         # via Homebrew
curl -fsSL https://raw.githubusercontent.com/tathagat22/walkback/main/packaging/install.sh | sh

The MCP server (for MCP clients like Cursor / Claude):

npx -y @tathagatmaitray/walkback

What it reverses

One consistent model — record a change with its inverse, replay the inverse on rollback — across every domain. Anything that touches the outside world is dry-run gated: walkback shows you what it would do and never fires blindly.

📁 Files — byte-perfect, crash-safe · CLI, automatic

Create / modify / delete / directories / symlinks / permissions, all restored exactly from a content-addressed blob store. Plus redo, and selective per-file revert.

walkback rollback              # rewind everything since the checkpoint
walkback revert src/auth.ts    # ...or just one file
walkback redo                  # ...changed your mind

🔍 `walkback diff` — review before you trust · CLI + MCP

A PR-style view of exactly what the agent changed, built from walkback's own before-snapshots:

 src/auth.ts  modified  +2 -2
  -const KEY = "prod-secret"
  +const KEY = ""
 2 file(s) changed, +3 -2

🌐 Network calls — actually reversed · MCP tools

When the agent records a mutation with a compensator (the request that reverses it), walkback runs it:

agent: POST /v1/charges          → walkback_record_http  (compensator: a refund)
        walkback_compensate                → preview: "WOULD send the refund"
        walkback_compensate execute=true   → fires it, most-recent-first

✉️ Email — honest hold-and-release · MCP tools

No tool can recall a delivered email — the recipient has a copy nothing can touch. So walkback does the one honest thing that works: it holds the email as a draft that has gone nowhere.

walkback_email_stage    to=… subject=… body=…   # held, NOT sent
walkback_email_cancel                            # delete the draft → it never existed
walkback_email_release                           # ...or actually deliver it

Before release: cancel is a true unsend. After delivery: it's gone, and walkback says so plainly — the most it can do then is trash your copy. We don't pretend to reach into other people's inboxes. Works with Gmail (GMAIL_ACCESS_TOKEN) and Outlook / Microsoft 365 (OUTLOOK_ACCESS_TOKEN); walkback holds no credentials of its own.

☁️ Cloud & databases — any tool · MCP tools

walkback doesn't hardcode AWS or Postgres. The agent records the command that reverses what it did, and walkback runs it (dry-run gated):

walkback_record_reversal  description="created S3 bucket assets-prod"  command="aws s3 rb s3://assets-prod --force"
walkback_record_reversal  description="ran migration 042"             command="psql $DB -f rollback_042.sql"
walkback_compensate execute=true

Works with any cloud, database, or CLI. (For DB UPDATE/DELETE, you record the inverse — walkback runs what you give it.)

CLI

walkback init                      set up walkback in this directory
walkback checkpoint [label]        mark a point you can rewind to
walkback track <path>...           capture a path before the agent changes it
walkback status                    what's changed since the last checkpoint
walkback diff                      a PR-style diff of everything the agent changed
walkback rollback [checkpoint]     rewind everything since a checkpoint
walkback revert <path>             selectively undo just one file
walkback redo                      undo the last rollback
walkback watch                     snapshot + watch the filesystem (any agent)
walkback run -- <command>          snapshot, then run any command reversibly
walkback protect / unprotect       install / remove the Claude Code auto-capture hook

The CLI covers files (automatic). The network / cloud / DB / email reversals are driven by the agent through the MCP tools below — because walkback can reverse files on its own, but it can't guess the inverse of a network call.

MCP server

Add to your MCP client's config (e.g. .mcp.json):

{ "mcpServers": { "walkback": { "command": "npx", "args": ["-y", "@tathagatmaitray/walkback"] } } }

16 tools: walkback_init · walkback_checkpoint · walkback_track · walkback_status · walkback_diff · walkback_log · walkback_rollback · walkback_revert · walkback_redo · walkback_record_http · walkback_record_reversal · walkback_compensate · walkback_email_stage · walkback_email_release · walkback_email_cancel · walkback_email_pending

The server ships instructions (auto-injected into the agent's context) telling the agent to checkpoint first and record the inverse of any network / cloud / DB / email action. Not using MCP? See docs/agent-instructions.md for the same policy as a system-prompt block.

Architecture

A polyglot system with a real native boundary:

┌─────────────────────────────┐
│  TypeScript  (agent surface) │   MCP server · compensation · email · reversals
├─────────────────────────────┤   ↕ NAPI-RS (in-process, no subprocess)
│  Rust  (the engine)          │   Effect · Journal · blob store · rollback · diff
│   crates/walkback-core       │   + the standalone `walkback` CLI
└─────────────────────────────┘

Rust owns the part that touches your filesystem and has to be fast and trustworthy; TypeScript owns the agent-facing surface; NAPI-RS bridges them in-process.

Why you can trust it

A universal undo is only worth anything if it's correct under pressure:

Crash-safe — journal/state written write-temp-then-rename (atomic on POSIX).
Rollback integrity — if any step fails, the journal is left intact and it's safe to retry; never reports success while leaving files unrestored.
Concurrency-safe — an exclusive lock, so an agent and a human can't corrupt the journal.
Sandboxed — refuses paths outside the project, never captures .undo, auto-gitignores snapshots so secrets aren't committed.

This is tested, not asserted: unit tests per property, a property test that runs dozens of randomized mutation sequences and asserts byte-for-byte round-trips, a concurrency test that hammers one journal from many threads, and Node suites that drive real HTTP/Gmail/command reversals against mock servers. The engine suite runs in CI on Linux, macOS, and Windows.

Platform note: the engine is verified on all three OSes. On Windows, content + structure + mtime restore exactly; unix permission bits and symlink fidelity are POSIX-only (they no-op rather than fail).

License

MIT © Tathagat Maitray

Available Tools

16 tools

walkback_checkpointCreate a checkpointA

Mark a point in time you can rewind to. Call this BEFORE you start making changes.

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	No	Project directory. Defaults to the server's working directory.
`label`	Yes	A short description, e.g. 'before refactor'.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses the tool saves a state for rewinding and implies safe invocation before changes. No contradictions found.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, no waste. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 params, no output schema), the description is sufficient. Could mention revert behavior but implied by sibling tool names.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so description need not add param info. However, the description does not enhance the meaning of 'label' or 'cwd' beyond schema definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool marks a point in time for rewinding and distinguishes it from siblings like walkback_revert. The verb 'mark' and resource 'checkpoint' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to call 'BEFORE you start making changes,' which provides clear when-to-use context. Does not list alternatives but the timing guidance is strong.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

walkback_compensateReverse network + cloud/DB actionsA

Execute the compensating actions recorded since the last checkpoint: the reversing HTTP request (DELETE undoes POST, refund undoes charge) AND any recorded reversal commands (cloud teardown, inverse SQL). Dry-run by default — pass execute=true to fire them. Most-recent-first.

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	No	Project directory. Defaults to the server's working directory.
`execute`	No	If true, actually send the compensating requests. Defaults to false (preview).

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries full burden. It discloses dry-run behavior, execution flag, and action ordering. It explains which types of actions are compensated (reverse HTTP request, recorded reversal commands). It lacks explicit warnings about irreversibility or failure modes, but is reasonably transparent for a compensation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words. The description is front-loaded with the core action and immediately provides concrete examples. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description covers purpose, usage (dry-run), and parameter semantics. It could mention what the preview output looks like or what happens on failure, but it's reasonably complete for a tool with two simple parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for both parameters (cwd, execute). The description adds value over the schema by explaining the dry-run default and the effect of execute=true. This goes beyond the schema's descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verbs and resources: 'Execute the compensating actions recorded since the last checkpoint' with concrete examples (DELETE, refund, cloud teardown, inverse SQL). It clearly distinguishes from sibling tools like walkback_rollback or walkback_revert by focusing on recorded compensating actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states dry-run default and execute=true to fire, and mentions most-recent-first order. However, it does not explicitly state when to use this tool versus alternatives like walkback_revert or walkback_rollback, nor does it provide exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

walkback_diffReview what the agent changedA

A PR-style diff of every file changed since the last checkpoint — the reviewable 'here's exactly what I did' surface. Built from walkback's own before-snapshots.

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	No	Project directory. Defaults to the server's working directory.

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full burden. It states the tool is built from before-snapshots and produces a diff, which suggests read-only behavior. However, it does not explicitly confirm no side effects or disclose any behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no fluff. The first sentence defines the action and scope, the second provides origin. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With one optional parameter and no output schema, the description sufficiently covers what the tool does, its data source, and its purpose. No gaps given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single parameter (cwd). The description adds context beyond schema by explaining the diff is built from walkback's own before-snapshots, enhancing understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool provides a PR-style diff of every file changed since the last checkpoint, using before-snapshots. This verb-resource combination is specific and distinguishes from siblings like walkback_checkpoint or walkback_log.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (reviewing changes) but provides no explicit guidance on when to use this vs alternatives, nor any exclusions. Sibling tools are listed but not compared.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

walkback_email_cancelUnsend held email(s)A

Delete the held draft(s) so they never go out — a true unsend, possible only because they were never delivered. Does nothing to emails already released.

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	No	Project directory. Defaults to the server's working directory.
`draftId`	No	A specific held draft id, or omit for all.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It honestly describes behavior: true unsend, deletion, no effect on released emails. Lacks details on permanence or recovery, but adequate for a simple cancellation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no redundant words. First sentence front-loads purpose. Every word serves a clear function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, no annotations, and 2 params, the description covers the main points: action, scope, and what it does not do. Missing return value or side effects, but sufficient for a straightforward deletion.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. Description restates schema for draftId (omit for all) without adding new semantics. cwd parameter is not elaborated, but its purpose is clear from schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'delete' and resource 'held draft(s)', with the specific outcome 'so they never go out'. It distinguishes from sending by noting 'possible only because they were never delivered'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates the tool is for held drafts and explicitly states it does nothing to released emails. However, it does not contrast with sibling tools like walkback_email_release or walkback_email_pending, leaving some ambiguity about when to use each.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

walkback_email_pendingList held emailsA

Show emails staged but not yet released — these can still be cancelled.

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	No	Project directory. Defaults to the server's working directory.

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It discloses that emails are staged (not yet released) and can still be cancelled, which is useful behavioral information beyond the title. However, it lacks details on authorization, side effects, or output format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no wasted words. Every part earns its place, clearly communicating the tool's purpose and a key behavioral trait.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple listing tool with one optional parameter and no output schema, the description is adequate. It explains what is shown and a key property (cancellability). Could mention output type (e.g., list of identifiers) but not necessary given simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, cwd, is well-described in the input schema (100% coverage). The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb 'show' and resource 'emails staged but not yet released', distinguishing from sibling tools like cancel, release, and stage. It tells exactly what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. While the sibling names hint at context (cancel, release), the description does not provide usage direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

walkback_email_releaseDeliver held email(s)A

Actually send the held draft(s). After this the email is delivered and CANNOT be recalled.

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	No	Project directory. Defaults to the server's working directory.
`draftId`	No	A specific held draft id, or omit for all.

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It explicitly states that after this the email is delivered and CANNOT be recalled, disclosing irreversibility—a critical behavioral trait.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the primary action and followed by the key consequence. Every sentence adds value with no waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description covers the main purpose and irreversible nature. However, it omits prerequisites (e.g., emails must be in a held/staged state) and does not explain behavior when draftId is omitted (implicitly all). Adequate but has gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The tool description does not add any parameter-specific meaning beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool actually sends held drafts, with the specific verb 'send' and resource 'held drafts'. It distinguishes from siblings like cancel and pending by emphasizing delivery and irreversibility.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for sending held drafts but does not explicitly state when to use this tool versus alternatives like cancel or stage. No when-not-to-use guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

walkback_email_stageSend an email — reversibly (hold as draft)A

Hold an email instead of sending it immediately: it becomes a Gmail DRAFT that has gone nowhere. Release it with walkback_email_release to actually deliver, or walkback_email_cancel to truly unsend it (it never reaches the recipient). Needs GMAIL_ACCESS_TOKEN.

ParametersJSON Schema

Name	Required	Description
`to`	Yes	Recipient email address.
`cwd`	No	Project directory. Defaults to the server's working directory.
`body`	Yes	Plain-text body.
`subject`	Yes	Subject line.

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It explains that the email becomes a draft that has gone nowhere and mentions authorization needs. However, it doesn't mention potential error states or what happens if token is missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no wasted words. Front-loads the core action and then provides alternative usage. Excellent conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description provides good context about the tool's role in the walkback_email suite. It could mention return value or side effects, but it's adequately complete for a side-effect tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so description need not repeat parameter details. But description does not explain the 'cwd' parameter (project directory), which is less intuitive than others. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool holds an email as a draft instead of sending immediately, and contrasts with walkback_email_release and walkback_email_cancel, distinguishing it from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use (to hold an email) and when to use alternatives (release/cancel). Also mentions the required GMAIL_ACCESS_TOKEN, providing clear usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

walkback_initInitialize walkbackA

Set up the walkback time machine in a project directory (and gitignore its snapshots). Run once before checkpointing.

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	No	Project directory. Defaults to the server's working directory.

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavior. It mentions gitignoring snapshots but lacks details on filesystem changes, idempotency, or consequences of multiple runs. More transparency is needed for a setup tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loading the core purpose and usage guidance. Every sentence adds value with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one optional parameter), the description is adequate but could be more complete. It does not mention prerequisites, error conditions, or idempotency. For a setup tool, these details would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the parameter description for 'cwd' is adequate. The tool description adds no further semantic value beyond the schema, so baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool sets up the walkback time machine in a project directory and gitignores snapshots, using specific verbs and resources. It distinguishes from siblings by indicating this is the initialization step before checkpointing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Run once before checkpointing,' providing clear context on when to use it. It does not exclude alternatives but implies it is the first step among sibling tools like walkback_checkpoint.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

walkback_logFull walkback historyB

List every checkpoint and effect in order.

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	No	Project directory. Defaults to the server's working directory.

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden for behavioral disclosure. It only says 'list in order' but does not mention read-only nature, permissions needed, or side effects. For a list operation, agents need to know if it is safe.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that gets to the point. It could be slightly more informative without adding much length, but it is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no output schema, no annotations, and many siblings, the description is too minimal. It does not explain return values, ordering specifics, or behavior differences from similar tools like walkback_status.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with a single parameter 'cwd' described. The tool description adds no extra meaning beyond what the schema provides. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List every checkpoint and effect in order,' providing a specific verb and resource. It distinguishes the tool from siblings like walkback_checkpoint or walkback_status by indicating it returns the full history.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for listing history, but it does not explicitly state when to use this tool versus alternatives like walkback_status or walkback_diff. No exclusions or when-not-to-use guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

walkback_record_httpRecord a network mutationA

Log a POST/PUT/PATCH/DELETE the agent made, with an optional compensating request (e.g. a DELETE that reverses a POST) so it can be undone later.

ParametersJSON Schema

Name	Required	Description
`cwd`	No	Project directory. Defaults to the server's working directory.
`url`	Yes	URL that was called.
`method`	Yes	HTTP method of the mutation.
`compensatorUrl`	No	URL of the reversing request.
`compensatorBody`	No	Body of the reversing request.
`compensatorMethod`	No	Method of the reversing request.

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must carry behavioral disclosure. It explains the core behavior (logging with optional compensator) but omits details like auth requirements, side effects, error handling, or what happens after logging.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence that front-loads the purpose and includes a concrete example. No superfluous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 6 parameters and no output schema, the description covers the core functionality but lacks details on return value, error states, or how logged entries are used later. Adequate but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear descriptions. The description adds meaning by explaining the optional compensator parameters (Url, Body, Method) and their role in undoing mutations, which goes beyond the schema's basic labels.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool logs an HTTP mutation (POST/PUT/PATCH/DELETE) made by the agent, with an optional compensating request for undo. It distinguishes from siblings like walkback_record_reversal by focusing on HTTP mutations and compensating requests.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description implies usage for logging HTTP mutations when undo capability is needed, but lacks explicit when-to-use or when-not-to-use guidance compared to similar tools like walkback_record_reversal or walkback_log.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

walkback_record_reversalRecord how to reverse a cloud/DB actionA

Record the command that reverses something the agent did to an external system — a cloud resource (e.g. 'terraform destroy', 'aws s3 rb s3://bucket') or a database change (e.g. an inverse SQL via psql). walkback_compensate will run it (dry-run gated). Works with any tool. For UPDATE/DELETE you must capture the prior values to build the inverse — walkback runs what you give it.

ParametersJSON Schema

Name	Required	Description
`cwd`	No	Project directory. Defaults to the server's working directory.
`runIn`	No	Directory to run the command in. Defaults to the project.
`command`	Yes	The command that reverses it, e.g. 'aws s3 rb s3://assets-prod'.
`description`	Yes	What was done, e.g. 'created S3 bucket assets-prod'.

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Discloses recording behavior and relationship to compensation tool, but does not detail validation, persistence, or side effects of recording. Adequate but not thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise single paragraph with front-loaded purpose, examples, and relation to sibling. No redundant sentences, but could be slightly better structured with bullet points.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Explains role in walkback system and gives use-case examples. However, does not address multiple recordings, overwrites, or persistence duration. For a recording tool, this is a gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline 3. Description adds value with concrete examples for command and description parameters, plus guidance on capturing prior values for updates/deletes. Exceeds baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb ('Record') and resource ('command that reverses something'), with specific examples (terraform destroy, aws s3 rb, inverse SQL). Distinguishes from sibling walkback_compensate by noting it will run the recorded command.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly relates to walkback_compensate (dry-run gated) and gives when-to-use guidance for UPDATE/DELETE requiring prior values. Lacks explicit when-not-to-use scenarios but is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

walkback_redoUndo the last rollbackA

Re-apply the changes that the most recent walkback_rollback reversed, and re-extend the history so you can roll back again.

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	No	Project directory. Defaults to the server's working directory.

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description bears full burden. It discloses the action (re-apply, re-extend history) but lacks details on destructive potential, idempotency, prerequisites (e.g., a prior rollback), or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, no redundancy, front-loaded with key action. Every phrase adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given low complexity (1 optional param, no output schema) and no annotations, the description is fairly complete. It explains core behavior and context but omits edge cases and results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers the single parameter cwd with a description; the tool description adds no extra semantic meaning beyond that. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb (Re-apply) and resource (changes from the most recent walkback_rollback), distinguishing it from siblings like walkback_rollback and walkback_revert by specifying it undoes the last rollback.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description implicitly tells when to use: after a rollback. It also mentions re-extending history for further rollbacks, providing context. However, it does not explicitly exclude cases (e.g., when no rollback exists) or compare with alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

walkback_revertSelectively undo one fileA

Reverse just a single file (the most recent change to it), leaving every other change since the checkpoint in place. The opposite of rollback's all-or-nothing.

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	No	Project directory. Defaults to the server's working directory.
`path`	Yes	The file to revert.

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that other changes remain intact, but does not explain side effects like whether the reversal is tracked as a new change, required permissions, or edge cases (e.g., file unchanged).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero wasted words, action verb first, efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and lack of output schema, the description covers the core behavior. Missing details about return value and edge cases, but overall sufficient for its purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for both parameters. The description adds no further parameter details beyond the schema, so it meets the baseline but doesn't exceed it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verbs ('reverse just a single file') and resources ('most recent change'), and explicitly contrasts with rollback, making the tool's distinct purpose clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states when to use this tool (selective undo) vs. rollback (all-or-nothing), providing clear context. However, it doesn't mention prerequisites like needing a checkpoint or behavior when the file has no changes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

walkback_rollbackRewind everythingA

Reverse every change made since a checkpoint (the latest one by default). Files, directories, and symlinks are restored exactly; network/shell effects are listed for manual handling. If any step fails, the journal is left intact so you can safely retry. Use walkback_redo to reverse a rollback.

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	No	Project directory. Defaults to the server's working directory.
`checkpoint`	No	Checkpoint id to rewind to. Defaults to the most recent.

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses that files/dirs/symlinks are restored exactly, network/shell effects are listed for manual handling, and step failure leaves journal intact. This is comprehensive behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no wasted words. Essential information is front-loaded and efficiently communicated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a rollback tool with 2 params and no output schema, description covers purpose, behavior, failure handling, and sibling reference. No gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so description does not need to add much. It briefly clarifies cwd as project directory and checkpoint defaults to most recent, but this is already in the schema. Thus baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Reverse every change made since a checkpoint', a specific verb+resource. It also distinguishes from sibling walkback_redo which reverses a rollback.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use (to reverse changes since a checkpoint), describes failure behavior (journal left intact for safe retry), and recommends walkback_redo as alternative for reversing a rollback.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

walkback_statusWhat's changed since the checkpointB

Show every effect recorded since the most recent checkpoint.

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	No	Project directory. Defaults to the server's working directory.

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. The description only states the action without disclosing side effects, permissions, or limitations. For a tool that likely performs a read-only operation, the description does not confirm this or provide additional behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, no wasted words. The purpose is front-loaded and clearly communicated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the single optional parameter and no output schema, the description is minimally adequate. However, lack of usage guidelines and behavioral transparency makes it incomplete for a tool in a family of similar tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for the single optional parameter 'cwd'. The description adds no meaning beyond the schema, so baseline score is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Show every effect recorded since the most recent checkpoint,' which is a specific verb (Show) and resource (effects since checkpoint). This distinguishes it from sibling tools like walkback_diff or walkback_log.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. With many sibling tools (e.g., walkback_log, walkback_diff), the description does not help the agent decide which tool is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

walkback_trackTrack a path before changing itA

Capture a file's (or whole directory's) current state BEFORE you create, modify, or delete it. This is what makes the change reversible. Call it on every path you're about to touch. Directories are captured recursively. Paths outside the project are refused.

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	No	Project directory. Defaults to the server's working directory.
`paths`	Yes	Files or directories you're about to change (relative or absolute).

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully conveys core behavioral traits: it captures state for reversibility, recursively handles directories, and refuses out-of-project paths. It does not disclose potential side effects like storage or latency, but covers the essential operational details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise (4 sentences) with the main purpose front-loaded. Every sentence adds value: purpose, why, when, constraints. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 2 parameters, no output schema, and 16 siblings, the description adequately explains usage and constraints. It lacks details on return value or error handling, but for a simple tool it is reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds extra context for paths (recursive capture, path refusal) and cwd (defaults to server directory), which goes beyond the schema descriptions. This aids correct usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool captures file/directory state before changes, using specific verbs ('Capture', 'BEFORE') and explicitly distinguishes from siblings by emphasizing it's for tracking before modification. It identifies the resource and the context of use.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear guidance: 'Call it on every path you're about to touch.' and explains the purpose ('makes the change reversible'). It also mentions directories are recursive and paths outside project are refused. However, it does not explicitly compare to sibling tools like walkback_checkpoint or walkback_compensate, nor does it state when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

16 tool updatesv0.2.2Jul 12, 2026
- First observedwalkback_checkpoint
- First observedwalkback_compensate
- First observedwalkback_diff
- First observedwalkback_email_cancel
- First observedwalkback_email_pending
- First observedwalkback_email_release
- First observedwalkback_email_stage
- First observedwalkback_init
- First observedwalkback_log
- First observedwalkback_record_http
- First observedwalkback_record_reversal
- First observedwalkback_redo
- First observedwalkback_revert
- First observedwalkback_rollback
- First observedwalkback_status
- First observedwalkback_track

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Every tool has a clearly distinct purpose: initialization, checkpointing, tracking, status, diff, logging, rollback, revert, redo, compensating, recording HTTP and reversal commands, and email staging/cancel. No ambiguity between them.

Naming Consistency5/5

All tools follow a consistent walkback_<action> or walkback_<action>_<target> pattern, with clear verb-noun structure. No mixing of conventions.

Tool Count4/5

16 tools is slightly above the typical well-scoped range (3-15), but each tool serves a necessary role in the undo workflow, including email handling. The count is justified and not excessive.

Completeness4/5

The tool set covers checkpointing, file tracking, external effect recording, reversing, and email lifecycle. Minor gaps exist (e.g., automatic tracking of all changes) but the surface is comprehensive for its domain.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

memnodeOAuth
dev.memnode
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
Knowledge & Memory Autonomous Agents Agent Orchestration
2
Oakallow A
io.github.oakallow
Runtime permission, approval, and audit layer for AI agent tool execution.
Autonomous Agents Security
521
runvouch B
com.runvouch
Watchdog for unattended AI agents: alerts, evidence checks and a verifiable proof per run.
Monitoring Observability
71
Penfield Memory AOAuth
io.github.penfieldlabs
Persistent memory and knowledge graphs for AI agents. Hybrid search, context checkpoints, and more.
Knowledge & Memory RAG Systems Vector Databases
26

Related MCP Servers

statecli-mcp-serverofficial
Knowledge & Memory Autonomous Agents
statecli
A
license
Not graded
quality
D
maintenance
Gives AI agents memory, undo, and self-awareness by tracking file changes and enabling checkpoints and rollbacks.
Updated 5 months ago (2026-04-07 02:59 UTC)
74
2
MIT
checkpointer
File Systems Developer Tools
IronKommander
F
license
B
quality
C
maintenance
MCP server for file checkpointing and undo, enabling AI agents to safely read, write, and edit files with full snapshot history and revert capabilities.
Updated 2 months ago (2026-07-15 14:49 UTC)
10
-
Archetypal AI MCP Server
archetypal-ai
F
license
Not graded
quality
C
maintenance
Provides persistent memory tools (recall, remember, checkpoint) for AI agents, enabling them to save and restore state across sessions.
Updated 5 months ago (2026-03-24 05:40 UTC)
2
-
Ketan-OS MCP Server
File Systems Shell Access Observability
umang-algo
A
license
A
quality
B
maintenance
Provides transactional intelligence for AI agents, enabling safe tool execution with pre-flight invariant checks, sub-second filesystem snapshots/rollback, causal tracing, belief contradiction detection, and 15 native MCP tools for Claude Code.
Updated 20 days ago (2026-08-16 20:14 UTC)
15
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tathagat22/walkback'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Why not just git?

Works with any AI agent

Install

What it reverses

📁 Files — byte-perfect, crash-safe · CLI, automatic

🔍 walkback diff — review before you trust · CLI + MCP

🌐 Network calls — actually reversed · MCP tools

✉️ Email — honest hold-and-release · MCP tools

☁️ Cloud & databases — any tool · MCP tools

CLI

MCP server

Architecture

Why you can trust it

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

statecli-mcp-serverofficial

Latest Blog Posts

MCP directory API

🔍 `walkback diff` — review before you trust · CLI + MCP