Skip to main content
Glama
Sign In
git-tools

git-tools

by craft-agent
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Stage chosen hunks

git_commit_stage
Idempotent

Stages exactly the named hunks from a git_commit_read listing into the Git index and uses the listing digest to reject stale diffs. Leaves the working tree untouched; stage binary files whole.

Instructions

Stage exactly the named hunks of a git_commit_read hunks listing into the index. Pass the listing's digest with the ids and the same paths: the call recomputes the diff and stages nothing when it differs from the listing, so a stale listing never stages other hunks. The working tree is untouched. Ids are positions in one listing, so list again after staging. A binary file cannot be staged by hunk; stage it whole with git add.

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": {
      "digest": "<digest>",
      "hunks": "<hunks>"
    },
    "name": "git_commit_stage"
  }
}

Input Schema

NameRequiredDescriptionDefault
hunksYesThe ids of the hunks to stage, from that listing; a repeated id is staged once.
pathsNoThe same files or directories the listing was made with, relative to the working tree root.
digestYesThe digest of the git_commit_read hunks listing the ids come from.

Output Schema

NameRequiredDescriptionDefault
rootYesThe absolute path of the working tree root.
filesYesEvery file the index now changes against HEAD, including what was staged before this call.
stagedYesThe ids of the hunks that were staged, ascending.

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?

Beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), it discloses the digest-verification mechanism and that a mismatch stages nothing, that the working tree is untouched, and that the operation is positional relative to one listing. These are exactly the behavioral facts the annotations cannot express.

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 action and input provenance, then failure behavior, then the binary exception. No sentence is redundant with the title or annotations.

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?

For a three-parameter mutating tool with full schema coverage and an output schema, the description covers provenance, staleness safety, side effects, id lifecycle, and the unsupported case. Nothing an agent needs in order to call it correctly is missing.

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 100%, so the baseline is 3, but the description adds the crucial cross-parameter coupling: digest, ids, and paths must all come from the same listing ('the same paths'), which the schema only hints at per-field. It does not restate the 'repeated id is staged once' dedup rule, which the schema already covers.

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 precise verb and resource ('Stage exactly the named hunks ... into the index') and anchors it to the sibling tool that produces the input (git_commit_read hunks listing). An agent can distinguish this from git_commit_read, git_commit_create, and git_rebase_split without opening any schema.

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 requires that ids come from a listing, instructs re-listing after staging because ids are positional, and names the alternative path for binaries ('stage it whole with git add'). It also states the stale-listing behavior, giving the agent the failure mode and recovery action.

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