What can you do with this server?

This server exposes VibeRevert's project safety and session tooling: run risk checks, inspect reports, and manage checkpoints/sessions. * check_repo: Run safety checks against the working tree or staged diff and persist the resulting ReportFile, optionally scoped by task, since a session, or threshold. * explain_diff: Render a CommonMark explanation of an existing check report alongside its metadata. * classify_risk: Get per-severity counts (critical, high, medium, low) for a check report. * list_risky_files: Get a per-file risky-files list sorted by max severity, finding count, and path (capped at 500 entries). * get_policy: Return the project's resolved policy from .viberevert.yml, including risk thresholds, check toggles, frameworks, and rollback exclude patterns. * start_session: Start a new VibeRevert session by creating an inner checkpoint, capturing pre-session git status, and acquiring the session lock. * create_checkpoint: Create a standalone checkpoint of the current working tree state. * generate_fix_prompt: Generate and persist a fix prompt from a check report, with truncation handling on the wire while keeping the full text on disk.

de en es ja ko ru zh

viberevert

by madeinplutofabio

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

VibeRevert is the project-integrity layer for AI coding. It records the real working state before an agent starts, flags risky changes with deterministic rules, and lets you remove the agent work you don't want without giving up the rest.

An agent changed 80 files. 75 are useful. Remove the 5 you don't.

No AI judges the AI: risk findings are reproducible, explainable, and based on rules you can inspect.

The working state you already had is part of the project. Staged work, unstaged edits and pre-existing untracked files are recorded before the session starts and preserved through recovery. You don't have to package your work into commits before letting an agent help with it.

Keep using your coding agent. VibeRevert works alongside Claude Code, Cursor, and other coding-agent workflows. Git worktrees give an agent an isolated checkout; VibeRevert protects and selectively recovers the working state an agent actually changes. They solve different problems and can be used together.

AI broke your project? Undo the session, not your week. Whole-session rollback is still one command.

See it work

The actual CLI, condensed from a real beta payment run — check flags it, and rollback previews what it will change before you --apply:

$ viberevert check
risk: CRITICAL · payments
  app/api/checkout/route.ts          payments   (critical)
  app/api/webhooks/stripe/route.ts   payments   (critical)

$ viberevert rollback <session>        # preview — nothing changed yet
  package.json                       tracked_restored
  app/page.tsx                       tracked_restored
  app/api/checkout/route.ts          untracked_deleted
  app/api/webhooks/stripe/route.ts   untracked_deleted
  lib/stripe.ts                      untracked_deleted
  .gitignore  README.md  (your uncommitted work)   skipped_unchanged

Related MCP server: uacos

Proof, not promises

3 real AI coding sessions. 3 exact project-file restorations. Payments, database migrations, and deployment infrastructure — all with pre-existing uncommitted work preserved. Read the beta report →

Quickstart

Works inside a Git repository and requires Node.js 22+. VibeRevert keeps its records on your machine and requires no VibeRevert account or hosted service.

npm install -g viberevert@beta

viberevert init                # one-time setup in your project
viberevert run <your-agent>    # records the session and saves your files' starting state
viberevert check               # see what changed and what looks risky
viberevert rollback <session>  # preview putting your files back; add --apply to restore

Restoring only part of a session works the same way, with a selector:

viberevert rollback <session> --only 'app/api/**'          # preview just that part
viberevert rollback <session> --only 'app/api/**' --apply  # restore just that part

What it protects you from

You let an AI agent work across your project, and it touched more than you expected — maybe payment code, a database migration, a deploy file — while your own half-finished work was sitting right there uncommitted. VibeRevert captures your project's starting file state first, so a session you don't like doesn't cost you your afternoon.

What VibeRevert does

Around each AI coding session, VibeRevert:

Checkpoints your project first — working tree, staged changes, and untracked files, including work you haven't committed.
Records the session and the project files that changed while it ran.
Flags risky edits — changes touching auth, payments, databases, secrets, dependencies, or infrastructure (risk taxonomy).
Writes an agent-ready fix prompt from those findings, to paste into your next iteration.
Restores your files to the checkpoint when you need it.

It warns you; it does not silently block your work. An optional pre-commit hook can reject a commit above your configured risk threshold — opt-in, tunable, and bypassable like any local Git hook.

Rules decide. Agents fix.

VibeRevert does not ask another language model whether your agent's changes look risky. Its checks are deterministic: the same inputs and configuration produce the same findings, with an inspectable reason for every flag.

When something needs attention, VibeRevert can turn those findings into an agent-ready fix prompt. The rules decide what to flag; you decide what happens next.

Roll back all of it, or only the part that went wrong

viberevert rollback restores your local project files — tracked, staged, and untracked, including uncommitted work — to how they were when the session started. It previews by default; --apply writes the change, and every apply first saves an emergency checkpoint you can recover from.

Since 0.8.0 you can also restore part of a session. Say the agent's payments change was wrong but its test additions were fine: put back only the payments work and keep everything else.

$ viberevert rollback <session> --only 'app/api/**'    # preview — nothing changed yet
[RESTORED]  app/api/checkout/route.ts
[RESTORED]  app/api/webhooks/stripe/route.ts
Eligibility: eligible

$ viberevert rollback <session> --only 'app/api/**' --apply

Four ways to choose, and any one of them switches rollback into selective mode:

Selector	Picks
`--only <glob>`	changes matching a path pattern
`--except <glob>`	everything but those, subtracted last
`--risk <level>`	changes a finding rated at or above that level touches
`--finding <id>`	the changes one specific finding applies to

Positive selectors combine by intersection, so --only 'payments/**' --risk critical means critical changes inside payments/, not payments plus every unrelated critical file. Path selectors follow a renamed file, so a file moved out of payments/ still matches. Nothing is restored unless everything you selected can be: if any selected path drifted since the session ended, the whole operation refuses rather than half-applying, and --force does not override that. If a selective apply is interrupted, the next one fails closed and points you at the emergency checkpoint rather than layering a second partial restore on top.

Two current limitations worth knowing before you rely on it:

Sessions ended before 0.8.0 cannot be selectively rolled back. They have no record of what they contributed and it cannot be reconstructed. Whole-session rollback still works on them, unchanged. See MIGRATIONS.md.
--finding needs the full finding id, as printed by viberevert check --since <session> --json. Short prefixes are not accepted yet.

It does not reverse effects outside your project files. Deployments, database writes, third-party API calls, payments, and sent emails need their own recovery. Rollback is state-based rather than atomic, and it's a safety net around AI sessions, not a replacement for tests or review. Read what rollback can and can't restore before you rely on it.

One recovery layer across your coding agents

Keep using the coding tools you prefer. VibeRevert can wrap command-line agent sessions (viberevert run <your-agent>) and integrates with tools such as Claude Code and Cursor through its installers.

Built-in checkpoints live inside the agent's workflow. VibeRevert stays with the project.

It captures your project's starting state — including uncommitted work — then records the session, flags risky changes, previews the rollback, and keeps that recovery path outside the agent itself.

Use Claude Code today, Cursor tomorrow, or wrap another terminal agent: the safety layer stays with your project.

Wire it into your tools

VibeRevert installs non-destructively and can be removed cleanly. It integrates with Claude Code and Cursor (MCP server and hooks); every install previews its changes and keeps a recovery journal. See getting started.

An experimental terminal bridge (--pty) can intercept commands inside an interactive agent shell; it's best-effort and documented as such in the PTY contract.

Platforms

Linux, macOS, and Windows, on Node.js 22+. CI runs the suite across all three on Node 22 and 24; see compatibility for exactly what each platform is tested to do.

Learn more

Getting started · Commands · Configuration
What rollback can and can't restore · Risk taxonomy
Security policy · Threat model · Contributing

Support VibeRevert

VibeRevert is Apache-2.0 open source. Sponsoring funds continued cross-platform testing, security work, rollback and recovery testing, and helping pay for independent review. Sponsorship does not influence risk findings or release decisions. → Sponsor VibeRevert · what your support funds

License

Apache-2.0. See NOTICE and the license audit.

Available Tools

8 tools

check_repoB

Run safety checks against the working tree or staged diff and return the resulting ReportFile (or summary when large). Side-effecting (class B per D99.V): always persists the ReportFile under .viberevert/.

ParametersJSON Schema

Name	Required	Description	Default
`task`	No
`since`	No
`staged`	No
`threshold`	No

TDQS

B3.4/5.0

Behavior4/5

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

The description explicitly notes that the tool is side-effecting and always persists a ReportFile, which is critical behavioral information, and no annotations are provided to cover this. It also mentions that the return value may be a summary when large, adding transparency. This is helpful but does not go into deeper details like exact file paths or side effects on the environment.

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 concise and front-loaded with the main action and return type. The mention of side effects and persistence is valuable. However, one sentence might be dense, potentially combining multiple ideas, but it remains clear and easy to parse.

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 has 4 parameters with zero schema descriptions, no output schema, and no annotations, the description is incomplete because it does not explain parameter usage or the full behavior. However, the mention of side effects and large output handling adds some completeness haven't fully addresses the parameter gap.

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

Parameters2/5

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

The schema coverage is 0%, so no parameters are described in the schema. The description mentions 'working tree or staged diff' but does not explicitly connect these to parameters like 'since' or 'staged'. The enum for threshold is not explained, and the meaning of 'task' and 'since' remains unclear, so the description fails to compensate for the lack of schema documentation.

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

Purpose4/5

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

The description clearly states the tool's function: run safety checks against working tree or staged diff and return a report. It also distinguishes from siblings like classify_risk or list_risky_files by mentioning the ReportFile output and the scope of checks. However, it omits any detailed scope of what the safety checks actually include.

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 tool is described as running safety checks, which implies it should be used to assess code changes for risks, but there is no explicit guidance on when to use it versus alternatives like classify_risk or list_risky_files. The description does not mention exclusions or alternative tools, so while the context is somewhat clear, it lacks explicit direction.

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

classify_riskA

Project a check report's findings into per-severity counts (critical, high, medium, low). Read-only (class A per D99.V); no threshold input -- returns the full per-level histogram.

ParametersJSON Schema

Name	Required	Description	Default
`report`	No
`session`	No

TDQS

A3.9/5.0

Behavior4/5

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

Explicitly states 'Read-only' and 'no threshold input', providing key behavioral context. Since no annotations exist, the description carries the burden and addresses safety and side-effect concerns adequately, though other traits (e.g., performance) are omitted.

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 succinct sentences with no redundancy. The structure flows logically from purpose to behavioral notes, making it easy to parse.

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, the description adequately describes the return (per-level histogram) and mentions the lack of threshold filtering. It covers core functionality, though parameter details are missing.

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

Parameters2/5

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

Schema has 0% coverage for parameters 'report' and 'session'. The description hints that 'report' is a check report but does not explain 'session' or clarify expected formats, leaving significant ambiguity.

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?

Clear verb+resource: 'Project a check report's findings into per-severity counts' precisely describes the operation and output. Distinct from siblings by its focus on severity histograms.

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?

Implicitly indicates when to use (when severity counts are needed) and mentions 'no threshold input' to clarify scope, but does not explicitly contrast with alternative tools like 'list_risky_files'.

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

create_checkpointA

Create a standalone VibeRevert checkpoint capturing the current working tree state. Returns the new checkpoint id and creation timestamp. Side-effecting (class B per D99.V); writes a checkpoint directory under .viberevert/checkpoints/. When name is supplied, uses the D22 name-uniqueness lock; nameless checkpoints skip the lock entirely.

ParametersJSON Schema

Name	Required	Description	Default
`name`	No

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations provided, the description fully carries the burden of disclosing side effects. It explicitly states the operation is side-effecting (class B), writes under '.viberevert/checkpoints/', and explains the name-uniqueness lock behavior. It also discloses the return values (id and timestamp). This is a high level of transparency for a mutation 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-loaded with the core purpose, then quickly covers returns, side effects, and conditional behavior. Every word earns its place; there is no redundancy or filler. The structure is logical: purpose → output → side effect → conditional nuance.

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 tool with a single optional parameter and no output schema, the description is complete. It covers the primary action, the return format (id and timestamp), the location of side effects (checkpoint directory), and the lock behavior under a specific condition. No critical information is missing, such as error cases or prerequisites, which are not needed given the simplicity of the operation.

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?

The input schema has no description for the 'name' parameter (0% coverage), but the description compensates by explaining that supplying 'name' triggers the D22 name-uniqueness lock, implying that 'name' is the checkpoint name and affects uniqueness. This adds meaningful semantics beyond the schema's pattern and maxLength constraints, though it could be more explicit about the checkpoint naming purpose.

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 ('Create'), the resource ('a standalone VibeRevert checkpoint'), and the specific action ('capturing the current working tree state'). It also mentions the returned values (checkpoint id and creation timestamp), making the purpose unambiguous. The term 'standalone' differentiates it from potential sibling operations like start_session or check_repo, though none are directly similar.

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 provides clear context on usage: it's a side-effecting operation (class B) that writes a checkpoint directory, and it details the conditional lock behavior when 'name' is supplied. While it doesn't explicitly state when to use it versus alternatives, the sibling tools are distinct and no direct alternative exists. The lock condition effectively guides parameter usage (when to supply 'name' and when not).

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

explain_diffA

Render a CommonMark explanation of a check report alongside the report's metadata. Reads an existing ReportFile (read-only, class A per D99.V); does not run new checks.

ParametersJSON Schema

Name	Required	Description	Default
`report`	No
`session`	No
`threshold`	No

TDQS

A3.7/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It explicitly states the tool is read-only and does not run new checks, which covers safety and side effects. It also references a class A security classification (per D99.V), adding context. However, it does not describe potential errors, return format details, or dependencies beyond reading a report.

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 that efficiently convey the core function and key behavioral caveats. It is front-loaded with the primary purpose and contains no redundant information.

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 no annotations, no output schema, and 0% parameter coverage in the description, the tool is incomplete for an agent to use correctly. The description covers the primary action and read-only nature but lacks parameter semantics and output expectations. For a simple read-only tool, it might suffice if parameters were self-explanatory, but they are not.

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

Parameters1/5

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

The description provides no explanation of the parameters (report, session, threshold). Schema description coverage is 0%, and the schema itself has no descriptions. The tool requires three parameters with no guidance on their meaning or format, making correct invocation difficult.

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 a specific verb ('Render') and resource ('CommonMark explanation of a check report'), clearly indicating the tool's function. It also distinguishes itself from siblings by stating it does not run new checks, differentiating it from check_repo and similar tools.

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 implies usage context by stating it reads an existing ReportFile and is read-only, which suggests it should be used after checks have been run. However, it does not explicitly name alternative tools or provide a detailed when-to-use vs. when-not-to-use, but the 'does not run new checks' caveat gives clear guidance.

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

generate_fix_promptA

Render a fix-prompt from a VibeRevert check report. Returns the rendered prompt text, the absolute path to the persisted sibling fix-prompt.txt, and the source report id. Side-effecting (class B per D99.V); writes the sibling fix-prompt.txt via atomic temp+rename. The on-disk sibling is always the full untruncated text (D81); the MCP wire response's prompt_text is capped at 262144 bytes (D99.U) -- when truncated, the response carries truncated:true + bytes_omitted.

ParametersJSON Schema

Name	Required	Description	Default
`report`	No
`session`	No

TDQS

A3.5/5.0

Behavior5/5

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

The description explicitly discloses side effects: 'Side-effecting (class B per D99.V); writes the sibling fix-prompt.txt via atomic temp+rename.' It also transparently explains output truncation behavior: 'the MCP wire response's prompt_text is capped at 262144 bytes (D99.U) -- when truncated, the response carries truncated:true + bytes_omitted.' This goes beyond typical annotations and fully informs about side effects and output limitations.

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 dense but well-structured, starting with the main purpose, then the return values, then side effects, and finally truncation details. Each clause adds necessary information, and while it is somewhat long, it avoids redundancy and is appropriately sized for the complexity of the behavior it describes.

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?

The description covers behavioral aspects thoroughly (side effects, truncation) and mentions return values, but it lacks explanation of the input parameters and when to use the tool. Given the simple schema (two string fields) and no annotations, the description is moderately complete but leaves gaps in parameter semantics and usage context.

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

Parameters1/5

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

The description does not relate the input parameters (`report` and `session`) to their meaning or usage. It mentions 'from a VibeRevert check report' but never explicitly states that the `report` parameter is the report ID or that `session` refers to a session. This leaves the schema fields completely unexplained.

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's function: 'Render a fix-prompt from a VibeRevert check report.' It uses a specific verb ('Render') and a specific resource ('fix-prompt'), and distinguishes itself from sibling tools by focusing on fix-prompt generation from check reports.

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?

The description does not provide any guidance on when to use this tool versus alternatives. It lacks context or prerequisites, such as 'use when a check report is available' or comparisons to other tools like create_checkpoint. The only usage hint is implicit in the tool's purpose, but no explicit direction is given.

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

get_policyA

Return the project's resolved policy slice from .viberevert.yml: block/warn risk thresholds, check toggles, frameworks, and rollback exclude patterns. Applies M C defaults (D57) before returning. Read-only (class A per D99.V); does not run checks or mutate state.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden and handles it well: it explicitly declares 'Read-only (class A per D99.V); does not run checks or mutate state' and discloses the defaults-application behavior ('Applies M C defaults (D57) before returning'). This adds safety and resolution context beyond any structured annotation.

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?

Three tight sentences with zero waste: first sentence states the verb+resource+contents, second explains the resolution behavior, third covers the safety profile. Each sentence earns its place; the description is front-loaded with purpose and contains no redundant filler.

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 zero-param, read-only tool with no output schema, the description is nearly complete: it lists the return content, the defaults-resolution behavior, and the safety profile. The only minor gap is that it doesn't describe the exact output structure/format of the returned policy slice, but for this simple tool the component list suffices.

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?

The tool has zero parameters, so the rubric baseline is 4. The description compensates by describing the return-value content (the policy components), which gives the agent a clear picture of what it will receive even without an output 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 uses a specific verb+resource ('Return the project's resolved policy slice from .viberevert.yml') and enumerates the exact contents (risk thresholds, check toggles, frameworks, rollback exclude patterns). It clearly distinguishes from siblings — none of create_checkpoint, check_repo, explain_diff, classify_risk, or list_risky_files describe retrieving a resolved policy.

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 context — it's a policy-lookup tool that's safe because it doesn't run checks or mutate state — but it never explicitly states when to choose this vs alternatives, and no sibling tool is named for comparison. The guidance is implicit rather than explicit.

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

list_risky_filesA

Project a check report into a per-file risky-files list (path, max_severity, finding_count) sorted by [max_severity DESC, finding_count DESC, path ASC]. Read-only (class A per D99.V). Capped at 500 entries per D99.U.

ParametersJSON Schema

Name	Required	Description	Default
`report`	No
`session`	No

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of disclosure. It explicitly states the tool is read-only (class A per D99.V) and capped at 500 entries (per D99.U), which are important behavioral constraints. It also discloses the sorting behavior, adding value beyond what annotations would typically provide.

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 only two sentences, with the primary function front-loaded in the first sentence and constraints in the second. Every word adds value, no redundancy or fluff.

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 or annotations, the description does a good job of specifying the return format (list of fields) and sorting, but it leaves the 'session' parameter unexplained and provides no usage context relative to sibling tools. The references to D99.V and D99.U are opaque without external knowledge, creating additional ambiguity.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. While 'report' is implicitly clarified as the 'check report', the 'session' parameter is never explained, leaving its purpose and relationship to the report ambiguous. This is a significant gap for an agent trying to invoke the tool.

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's function: projecting a check report into a per-file risky-files list with explicit output fields (path, max_severity, finding_count) and sorting order. This specific verb+resource+output format differentiates it from sibling tools like check_repo or classify_risk.

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 context implies the tool is used after a check report exists ('Project a check report'), but it does not explicitly state when to use this tool over alternatives, nor does it provide any when-not-to-use guidance. No alternative tools are named.

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

start_sessionA

Start a new VibeRevert session: create the inner checkpoint, capture pre-session git status, and acquire the active-session lock. Returns the new session id, checkpoint id, and start timestamp. Side-effecting (class B per D99.V); writes session state and uses the D22 start lock during execution.

ParametersJSON Schema

Name	Required	Description	Default
`task`	No

TDQS

A4.6/5.0

Behavior5/5

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

No annotations are provided, so the description carries full weight. It does an excellent job of disclosing side effects: it states it is 'side-effecting (class B per D99.V)', writes session state, and uses the 'D22 start lock' during execution. It also specifies what resources are affected (checkpoint, git status, lock) and provides a reference to a classification system (D99.V) for risk assessment.

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 concise, three sentences, and front-loads the primary action. It efficiently packs essential details: what it does, what it returns, and what side effects to expect. Every sentence adds value, from the core function to the side-effect warning.

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 complexity (multiple internal steps: checkpoint, git status, lock) and lack of output schema, the description covers the key aspects. It explains the side effects, returns, and even classifies the side-effect level. It could potentially specify what happens if the lock is already held, but that's a minor omission given the details provided.

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?

The input schema has one parameter 'task' with only a pattern requiring non-space characters. The description doesn't explicitly define 'task', but it mentions that the session creation is the main action. Since there's only one parameter and it's not described in the schema beyond the pattern, the description could have hinted at what 'task' means. However, given the schema coverage is 0%, the description's silence on 'task' is a minor gap, but the low complexity (1 param) mitigates the impact. The description adds value by explaining the side effects but not the parameter semantics.

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's purpose: starting a VibeRevert session. It specifies the concrete actions (create inner checkpoint, capture git status, acquire lock) and the return values (session id, checkpoint id, start timestamp). While the sibling tools are listed, the description itself includes enough specificity to distinguish it from potential siblings like create_checkpoint.

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 implies when to use this tool (start of a session) and notes it acquires a lock, which hints at concurrency management. It doesn't explicitly say when not to use it or name alternative tools, but the context of session initialization and the lock acquisition gives clear usage context. The mention of 'start lock' suggests a prerequisite or constraint.

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.

8 tool updatesAug 19, 2026
- First observedcheck_repo
- First observedclassify_risk
- First observedcreate_checkpoint
- First observedexplain_diff
- First observedgenerate_fix_prompt
- First observedget_policy
- First observedlist_risky_files
- First observedstart_session

Install Server

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

TDQS

A3.9/5.0

Scored 2026-08-19 15:55 across 8 tools

Disambiguation4/5

Most tools have clearly distinct roles (create checkpoint, run checks, configure policy, start session), and the report-consuming tools produce different outputs. However, create_checkpoint and start_session overlap in checkpoint creation, and explain_diff, classify_risk, and list_risky_files all operate on check reports, requiring careful reading to choose the right one.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern: create_checkpoint, check_repo, explain_diff, classify_risk, list_risky_files, get_policy, start_session, generate_fix_prompt. There is no mixed casing, vague single-word verbs, or inconsistent naming style.

Tool Count5/5

Eight tools is a well-scoped surface for a checkpoint and safety-reporting server. Each tool covers a recognizable stage of the workflow, and none feel like duplicates or padding.

Completeness2/5

The server can create checkpoints, start sessions, run checks, and analyze reports, but there is no end/abort session tool, no revert or rollback operation despite the server being named VibeRevert, and no way to manage checkpoints beyond creating them. These are significant gaps that leave core workflows incomplete.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Frogeye Security Scanner A
io.github.frogeye-ai
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
Security Penetration Testing
2
MCP FortressOAuth
io.github.mcp-fortress
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Security Testing & QA Tools Penetration Testing
2
UI Verify A
io.github.igrlk
MCP server for visual regression testing: triage a PR's UI diffs from your coding agent.
Testing & QA Tools CI/CD & DevOps
9118
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21

Related MCP Servers

grippy-code-review
Version Control Code Analysis AI & Machine Learning
Project-Navi
A
license
Not graded
quality
C
maintenance
Open-source AI code review MCP server for local git diff auditing with deterministic security rules and AI-powered analysis using any OpenAI-compatible model.
Updated 2 months ago (2026-06-29 11:07 UTC)
4
MIT
uacos
Code Analysis Coding Agents
caotiensinh
A
license
Not graded
quality
B
maintenance
Local-first code intelligence and safety layer for AI coding agents. MCP server exposes dependency graph, impact analysis, and AST-compressed repo context, backed by typed local memory, patch-scope safety gates, and git-independent transaction rollback.
Updated 14 days ago (2026-08-26 14:52 UTC)
1
MIT
MCP Shield
Security Code Analysis CI/CD & DevOps
rob925
A
license
C
quality
B
maintenance
Security scanner and MCP server that catches dangerous patterns in MCP servers and AI agent projects, such as leaked secrets, shell execution, and prompt-injection text. Runs as both a CLI and MCP server with CI-friendly severity gates.
Updated 2 months ago (2026-07-10 14:06 UTC)
2
1
MIT
gitl
Version Control Code Analysis CI/CD & DevOps
akomyagin
A
license
Not graded
quality
A
maintenance
AI code reviews and git activity digests with machine-readable risk scoring, available as an MCP server for use within an agent session.
Updated 18 days ago (2026-08-22 19:43 UTC)
1
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/madeinplutofabio/vibe-revert'

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