Skip to main content
Glama
Sign In
Secure Git MCP

Secure Git MCP

by IvanAbramovichWork
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

git_commit

Commit staged changes only when the full staged set is permitted by project policy; use the configured repository or an explicitly allowed repository path.

Instructions

Commit only when the complete staged set is permitted. Omit repo_path to use the configured repository. Results and operations are restricted according to project policy.

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": {
      "message": "<message>"
    },
    "name": "git_commit"
  }
}

Input Schema

NameRequiredDescriptionDefault
messageYes
repo_pathNoOptional repository root. Omit to use the server's fixed repository. An explicit path must identify that same repository.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2026.10.19

TDQS

C2.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds that results and operations are restricted by project policy, which is useful context, but it remains vague about what that policy actually enforces or what happens on a failed commit.

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

Conciseness4/5

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

The description is three short sentences with no wasted words, and the central condition is reasonably front-loaded. It could be sharper, but it is tightly sized.

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

Completeness2/5

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

For a mutation tool with no output schema and incomplete parameter documentation, the description leaves important gaps: the required commit message is not explained, the policy restrictions are undefined, and failure/return behavior is unaddressed.

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

Parameters2/5

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

Schema description coverage is only 50%, and the required 'message' parameter is completely undocumented in both the schema and the description. The description does add useful semantics for repo_path beyond the schema, but it does not compensate for the missing message semantics.

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

Purpose3/5

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

The description uses the verb 'Commit' and references 'the complete staged set', so the basic action is inferable. However, it does not plainly state 'commit staged changes' and offers no differentiation from sibling tools like git_add, git_unstage, 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 Guidelines2/5

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

It gives a narrow policy condition ('only when the complete staged set is permitted') and explains repo_path omission, but it does not say when to use this tool versus git_add, git_status, or other siblings. There is no explicit when-not guidance or alternative routing.

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