Skip to main content
Glama
Sign In
Cloady

Cloady

Official
by Cloady
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Revert Git Commit

revertGitCommit
Destructive

Undo a specific Git commit by creating a new commit that reverses its changes. Runs in a development app container, aborts failed reverts, and returns Git output.

Instructions

Add a new commit that undoes the given commit. Refused while another merge, rebase, revert or cherry-pick is in progress. If the revert fails, it is aborted and the call fails. Works only on a development app: any other app answers 403 read_only. Runs git in the app's running container and returns its output.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "workspaceSlug": "<workspaceSlug>",
      "appSlug": "<appSlug>"
    },
    "name": "revertGitCommit"
  }
}

Input Schema

NameRequiredDescriptionDefault
envNo
regionNo
appSlugYes
requestBodyNoThe JSON request body.
workspaceSlugYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.18.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only declare readOnly=false, destructive=true and openWorld=true, yet the description adds substantive operational detail: refusal during in-progress git operations, automatic abort on failure, the 403 read_only response on non-development apps, and that git is executed inside the app's running container with its output returned. This is exactly the extra context annotations cannot convey.

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?

Four short sentences, each carrying a distinct constraint: what it does, when it refuses, how failure is handled, and the environment gate. Nothing is repeated and the core action is front-loaded.

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 mutating git tool with no output schema, the description covers the failure mode, environment restriction and return content (git output). The one gap is the near-total silence on the input parameters beyond the development-environment hint, which matters given only 20% schema coverage.

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 only 20%, and the description never explains workspaceSlug, appSlug, region or env directly. It does add one meaningful semantic constraint by tying the operation to a development app, which effectively constrains env, but the remaining four parameters are left to the schema alone despite the low coverage.

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?

States a specific verb and resource ("Add a new commit that undoes the given commit"), which precisely distinguishes it from sibling git tools such as commitGitChanges, cherryPickGitCommit and rollbackDeploy. The agent knows exactly which operation is performed without opening the schema.

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?

Gives a clear pre-condition (refused while a merge, rebase, revert or cherry-pick is in progress) and a clear environment restriction (development apps only, other apps return 403 read_only). It stops short of explicitly naming when to prefer cherryPickGitCommit or rollbackDeploy instead, but the context is otherwise unambiguous.

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