Skip to main content
Glama
vighriday

Veris

by vighriday
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

what_if_revert

Simulates reverting code changes by removing specified nodes from the dependency graph, then recomputes the diff and risk against the baseline to show what would be recovered.

Instructions

Counterfactual: removes the named nodes from the head graph, recomputes the diff and risk against the real baseline, and reports what changes. Answers 'what recovers if I revert this?'. Models deletion only — it cannot model reverting a modified body back to its prior form. Requires a resolvable baseline; returns an error rather than a fabricated one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nodeIdsYesNode ids to remove. Format: 'relative/path.ts::Symbol' or 'relative/path.ts::Class::method', as returned by export_behavioral_graph.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.0.1
    • changedInput schema / properties / nodeIds / description
      Previous value: -"Node identifiers to remove from the head graph for the counterfactual simulation. Format: 'filepath::SymbolName' or 'filepath::Class::method'. Get them from export_behavioral_graph."New value: +"Node ids to remove. Format: 'relative/path.ts::Symbol' or 'relative/path.ts::Class::method', as returned by export_behavioral_graph."
  2. Changed1 schema field changedv2.1.10
    • addedInput schema / properties / nodeIds / description
      Added value: +"Node identifiers to remove from the head graph for the counterfactual simulation. Format: 'filepath::SymbolName' or 'filepath::Class::method'. Get them from export_behavioral_graph."
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

The description transparently explains the operation: removing nodes, recomputing diff and risk, and reporting changes. It also discloses failure behavior (returns an error) and prerequisites (resolvable baseline). The counterfactual nature is explicitly labeled, avoiding misinterpretation as a destructive mutation.

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 yet information-dense. Each sentence contributes meaningful content: purpose, scope limitation, prerequisite, and failure behavior. There is no redundancy or unnecessary detail.

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?

The description provides complete context for an agent to decide when and how to use the tool: it defines the counterfactual scenario, specifies the exact operation, clarifies limitations, states requirements, and explains error handling. No critical information is missing.

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 already fully describes the nodeIds parameter, including its type and format. The description does not add additional semantic detail beyond referring to 'named nodes', which is already covered. With 100% schema coverage, the 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?

The description clearly states the tool's purpose: it removes named nodes from the head graph, recomputes diff and risk against the baseline, and reports changes. It also explicitly frames itself as a counterfactual analysis answering a specific question, which distinguishes it from other tools.

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?

The description provides direct usage guidance by stating the question it answers ('what recovers if I revert this?') and clearly delimits its scope: it models deletion only and cannot handle reverting modified bodies. It also states the prerequisite of a resolvable baseline and the failure behavior (returns an error rather than fabricating).

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

Deploy Server

Other Tools