Skip to main content
Glama

Commit pending changes

commit
Idempotent

Create a named checkpoint that records your uncommitted file writes on a branch as one history entry under a chosen message. Use it when the user asks for a snapshot.

Instructions

Commit the files you have written on this branch that are not yet committed, as one commit under message (author Claude). Only your own paths land: a collaborator's unsaved typing stays out of it and reaches history as their own autosave. Call it when the user asks for a named checkpoint — every write already commits on its own as it lands, so {committed:false} is the normal answer, not a failure: it means they landed already, and the result names the current head and your latest commits on the branch. For a multi-file change you are making right now, use batch_write instead — it writes and commits it in one step under its own message. message titles the commit and replaces the per-file titles those writes would have had.

Input Schema

NameRequiredDescriptionDefault
branchNoBranch name (defaults to 'main'). Every result, error results included, echoes {branch, head} — head is the branch's current commit (after a write, the commit that write made). Pass the branch explicitly whenever you are not on main.
messageYesCommit message stating the intent of the checkpoint, at most 200 characters.
projectNoProject id. Optional when the access token is scoped to exactly one project.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Adds substantial behavioral context beyond the annotations: only the caller's own paths are committed, a collaborator's unsaved typing is excluded and reaches history as their own autosave, and a {committed:false} result is a normal no-op that still reports the current head and latest commits. These details explain side effects and result interpretation in a way the annotations do not.

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 front-loaded with the core action and then uses each subsequent sentence to convey a distinct operational nuance: path ownership, normal no-op results, batch_write alternative, and message semantics. Despite its density, no sentence is redundant.

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 three parameters with full schema descriptions, annotations covering safety and idempotency, and no output schema, the description is complete enough to use correctly. It explains the unusual no-op outcome, return information such as head and latest commits, and the key behavioral boundary around collaborator paths.

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 100%, so the baseline is 3, but the description adds meaning for the required message parameter by explaining that it titles the commit and replaces per-file titles from prior writes. Branch and project semantics remain mostly in the schema, so this is a modest enhancement rather than full parameter 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: commit files written on this branch that are not yet committed, under a message and author Claude. It clearly scopes the operation to the caller's own paths and distinguishes itself from batch_write for multi-file changes being made right now.

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

Usage Guidelines5/5

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

Explicitly says to call it when the user asks for a named checkpoint, explains that every write already commits so {committed:false} is normal rather than a failure, and points to batch_write as the alternative for a current multi-file change. This leaves little ambiguity about when and when not to use the tool.

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