git_commit

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

Annotations already mark the tool as write/destructive, and the description adds that the commit is local and only uses staged changes unless --all is used. It does not mention failure modes like missing git identity or 'nothing to commit', but given the annotation coverage, this is acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single well-structured sentence that front-loads the action and resource, then adds the optional flag behavior. Every word earns its place with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The core behavior, local scope, and staging precondition are all covered, and the schema provides all parameter details. It does not describe post-commit effects or verification steps, but these are not essential for basic invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters. The description restates the --all behavior but adds no extra semantic meaning beyond what the schema provides, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('Create') and resource ('local Git commit') and disambiguously distinguishes the too from siblings like git_push and git_add by specifying that it operates locally and from staged changes. It is fully aligned with the tool's name and purpose.

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

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

The description gives clear context: use this when you have staged changes and want a local commit, and it explains the optional --all behavior for staging tracked modifications. It does not explicitly mention alternatives, but the context is strong enough for an agent to select it.

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