Skip to main content
Glama
logly

mureo

by logly
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

rollback_apply

Undo a previous action by executing a rollback plan with security re-validation and confirmation.

Instructions

Execute the rollback plan for action_log[index]. The reversal call is re-dispatched through the same MCP handler used for forward actions, so it re-enters auth, rate-limiting, and input validation. On success, appends a new action_log entry tagged with rollback_of=index. Requires confirm=true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
indexYesIndex into action_log to reverse.
reasonNoWhy this change is being made: one or two sentences naming the evidence and the expected effect. Stored in the journal and on the action_log entry this call produces, for the operator and the next session.
confirmYesMust be true to actually execute the rollback. A second-factor against accidental or injected apply calls.
state_fileNoPath to STATE.json.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.20.0
    • addedInput schema / properties / reason
      Added value: +{
+  "description": "Why this change is being made: one or two sentences naming the evidence and the expected effect. Stored in the journal and on the action_log entry this call produces, for the operator and the next session.",
+  "maxLength": 500,
+  "type": "string"
+}
  2. Changed1 schema field changedv0.10.37
    • addedInput schema / additionalProperties
      Added value: +false
  3. Addedv0.9.12
  4. Removedv0.9.6
  5. Addedv0.9.2
  6. Removedv0.9.1
  7. Addedv1.0.5

TDQS

A4.4/5.0
Behavior5/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 does so effectively: it discloses that the call re-enters the same MCP handler (affecting auth, rate-limiting, validation), appends a new action_log entry tagged with rollback_of, and requires confirm=true. These are non-obvious behaviors that an agent needs to know.

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 three sentences, each adding distinct value: the action, the re-dispatch behavior, and the side effect plus requirement. It is front-loaded with the primary purpose and contains no filler or redundancy.

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?

The description covers the tool's effects and safety behavior thoroughly, but it does not specify the return value or expected output. Since there is no output schema, a brief note on what the call returns (e.g., the new action_log entry or a success flag) would make it more complete. Otherwise it is quite detailed.

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 all parameters are already documented in the schema. The description adds minimal parameter-specific meaning—it references action_log[index] and confirm=true, but both are already covered in the schema. No additional semantic value beyond the 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 states a specific verb (execute) and resource (rollback plan for action_log[index]), and clearly differentiates from siblings like rollback_plan_get by explaining the re-dispatch through the same handler. This makes the tool's unique purpose unambiguous.

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?

It implies the correct usage by explaining that the reversal call re-enters auth, rate-limiting, and input validation, signaling this is the proper way to roll back rather than direct state manipulation. However, it does not explicitly mention alternatives or conditions when not to use it, so it stops short of full guidance.

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