Skip to main content
Glama
Sign In
Cloady

Cloady

Official
by Cloady
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Commit Git Changes

commitGitChanges
Destructive

Commits selected paths—staged or unstaged—or all changes in a Cloady development app, leaving other staged changes untouched.

Instructions

Commit the given paths, staged or not, and nothing else: changes staged at other paths stay staged. Paths are literal, never patterns, and a deleted path commits its deletion. Fails if any of the paths has no change. Without paths, commits every change, untracked files included. While a merge is in progress, git can only commit the whole merge, so the staged index is committed and paths is not used. The commit stays in the app's copy of the repository, which Cloady can't push to the remote. 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": "commitGitChanges"
  }
}

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?

Beyond the annotations, the description discloses many operational traits: paths are literal, deleted paths commit deletions, the call fails if any path has no change, untracked files are included when paths are omitted, merge behavior ignores paths, and the commit stays in the app's local repository and cannot be pushed. It also explains that execution happens in the app's running container and returns git output.

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 a single dense paragraph but is front-loaded with the core commit semantics and each subsequent sentence adds distinct operational information. There is little wasted wording for a tool with this many behavioral edge cases.

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 complex mutation with a nested request body and no output schema, the description covers the key behavioral risks and side effects, including merge handling, failure conditions, local-only commits, and development-app restriction. It is nearly complete, but the exact return shape and several top-level routing parameters remain unspecified.

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 description coverage is low at 20%, so the description must carry parameter meaning. It does this well for the central `paths` parameter, clarifying literal matching, deletion behavior, failure on unchanged paths, omission semantics, and merge-mode override, but it leaves top-level parameters such as `workspaceSlug`, `appSlug`, `env`, and `region` largely to name inference.

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 and resource: 'Commit the given paths... and nothing else.' It also clarifies scope precisely, including staged/unstaged paths and the no-paths behavior, which distinguishes it from adjacent Git operations like staging or discarding changes.

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 gives clear when-to-use behavior: provide paths to commit selected changes, omit paths to commit everything, and during a merge the staged index is committed instead. It also states the important exclusion that it only works on development apps and returns 403 `read_only` elsewhere, though it does not explicitly name sibling alternatives such as stageGitFiles.

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