Skip to main content
Glama

Git Commit

git_commit

Create a commit to save staged changes with your message. Record repository snapshots with options for custom authors, amendments, and GPG signing.

Instructions

Create a new commit with staged changes in the repository. Records a snapshot of the staging area with a commit message.

Commit Message Format: Pass commit messages as JSON string parameters. Multi-line messages are supported using standard JSON string escaping.

Examples:

  • Single line: { "message": "feat: add user authentication" }

  • Multi-line: { "message": "feat: add user authentication\n\nImplemented OAuth2 flow with JWT tokens.\nAdded tests for login and logout." }

Note: Do not use bash heredoc syntax. Literal escape sequences (\n, \t) in the message string are automatically normalized to their actual characters.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNoPath to the Git repository. Defaults to session working directory set via git_set_working_dir..
messageYesCommit message.
authorNoOverride commit author (defaults to git config).
amendNoAmend the previous commit instead of creating a new one. Use with caution.
allowEmptyNoAllow creating a commit with no changes.
signNoSign the commit/tag with GPG.
noVerifyNoBypass pre-commit and commit-msg hooks.
filesToStageNoFile paths to stage before committing (atomic stage+commit operation).
forceUnsignedOnFailureNoIf GPG/SSH signing fails, retry the commit without signing instead of failing.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
successYesIndicates if the operation was successful.
commitHashYesSHA-1 hash of the created commit.
messageYesThe commit message.
authorYesAuthor of the commit.
timestampYesUnix timestamp when the commit was created.
filesChangedNoNumber of files changed in this commit.
committedFilesYesList of files that were committed.
insertionsNoNumber of line insertions.
deletionsNoNumber of line deletions.
statusYesRepository status after the commit.
Behavior4/5

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

Beyond the readOnlyHint: false annotation, the description adds valuable behavioral details: it explains JSON string escaping requirements for multi-line messages, warns against bash heredoc syntax, and notes that escape sequences are automatically normalized. These are critical implementation details for correct invocation not inferable from the annotation alone.

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 well-structured with clear section headers (Purpose, Commit Message Format, Examples, Note). It is front-loaded with the core purpose, followed by specific formatting constraints and examples. Every sentence serves a purpose, with no redundant fluff.

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?

Given the complexity (9 parameters including GPG signing, amend, atomic staging) and the presence of an output schema, the description appropriately focuses on the non-obvious aspects: JSON string formatting for git messages. It covers the critical escaping behavior that an AI agent needs to construct valid parameters, making it complete for its context.

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?

With 100% schema coverage, the baseline is 3. The description adds significant value by providing concrete examples of single-line and multi-line commit message JSON formatting, and explaining the specific escaping behavior required. This supplements the schema's basic 'Commit message' description with essential syntax guidance.

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 creates a new commit with staged changes and records a snapshot of the staging area. It uses specific verbs (Create, Records) and identifies the resource (commit/snapshot), clearly distinguishing it from siblings like git_add, git_push, or git_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by mentioning 'staged changes,' suggesting files must be staged first, but lacks explicit workflow guidance. It does not state when to use git_add first versus using the filesToStage parameter, nor does it explicitly caution about using amend instead of regular commits in the main description text.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cyanheads/git-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server