Skip to main content
Glama
Sign In
Cloady

Cloady

Official
by Cloady
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Rebase Git Branch

rebaseGitBranch
Destructive

Replays the current branch's commits on top of a named branch in a development app, rewriting history; aborts and returns Git's error if the rebase fails.

Instructions

Replay the current branch's own commits on top of the named branch, rewriting them. Refused while another merge, rebase, revert or cherry-pick is in progress. If the rebase fails, it is aborted, the call fails, and the error carries git's report. 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": "rebaseGitBranch"
  }
}

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.6/5.0
Behavior5/5

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

The annotations already flag destructive=true and openWorld=true, and the description adds substantive detail beyond them: commits are rewritten, a failed rebase is auto-aborted with the call failing, the error carries git's own report, non-development apps return 403 read_only, and git runs inside the app's running container. This is exactly the kind of failure-mode and side-effect disclosure a destructive tool needs.

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?

Five tight sentences, front-loaded with the core action, then preconditions, then failure behavior, then environment constraint, then execution context. No sentence is redundant and no padding is present.

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 destructive, nested-body tool with no output schema, the description covers action, preconditions, error behavior, and environment gating. The only shortfall is that return shape ('returns its output') is described loosely and the non-branch parameters are not characterized, though no output schema exists to require it.

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 only 20%, so the description must compensate: 'the named branch' ties to requestBody.branch, and the development-only constraint effectively pins the env parameter to 'development'. It leaves workspaceSlug, appSlug, and region uninterpreted, but those are routine path/scope identifiers.

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 ('Replay the current branch's own commits on top of the named branch, rewriting them'), which precisely distinguishes it from mergeGitBranch, cherryPickGitCommit, and revertGitCommit. An agent can select it 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 precondition ('Refused while another merge, rebase, revert or cherry-pick is in progress') and an environment restriction ('Works only on a development app: any other app answers 403 read_only'). It does not explicitly name sibling alternatives such as mergeGitBranch, but the operative context for when to call it is clear.

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