Skip to main content
Glama
prashant-ai-lab

git-mcp

by prashant-ai-lab
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

git-mcp

An MCP server that lets an AI agent inspect and interact with a local Git repository.

Features

  • Git tools: status, log, branches, create commits (via GitPython)

  • File tools: list, read, write, inspect files in the workspace

  • Agent-ready: exposes everything as MCP tools that an LLM agent (LangGraph) can call

Related MCP server: Git MCP Server

Install

uv sync

Installs the server plus its LangGraph client dependencies.

Run the server

uv run project-mcp

Or as a stdio MCP server (what MCP clients spawn):

uv run python -m project_mcp.server

You can attach any MCP client — e.g. MCP Inspector (npx @modelcontextprotocol/inspector) with command uv run python -m project_mcp.server.

Tools

Git

  • get_status — current branch and working-tree changes

  • get_log — recent commit history

  • get_branches — local and remote branches

  • git_diff — working-tree / staged / between-commit diffs

  • git_add — stage changes (explicit paths or all)

  • git_commit — commit staged changes

  • git_push — push the current branch to a remote

  • create_commit — stage-and-commit shortcut

Files

  • list_dir — list directory entries

  • read_file — read file content (optional truncation)

  • write_file — write content to a file

  • file_info — size, type, and modification metadata

Example: LangGraph agent with an LLM (v2)

examples/langgraph_client.py is a LangGraph agent that spawns the MCP server over stdio, exposes its tools to a model, and answers your questions by calling them.

It talks to OpenRouter by default (no OpenAI key needed) and works with any OpenAI-compatible /v1/chat/completions endpoint.

Configure

cp .env.example .env
# edit .env -> set API_TOKEN (required)

.env is loaded from the project root (gitignored). Settings:

  • API_TOKEN — your OpenRouter API key (https://openrouter.ai/keys), or a bearer token for another endpoint.

  • MODEL_URL — OpenAI-compatible base URL. Defaults to https://openrouter.ai/api/v1; override for HF endpoints, llama.cpp (http://localhost:8080/v1), vLLM (http://localhost:8000/v1), LiteLLM, etc.

  • MODEL_NAME — model id. Default openrouter/free (route to a free model). Others: openai/gpt-4o-mini, z-ai/glm-5.2:free, etc.

Run

Ask via CLI arg:

uv run python examples/langgraph_client.py "What is the current git status?"
uv run python examples/langgraph_client.py "Show me the last 3 commits"

Or interactively (no arg → prompts you):

uv run python examples/langgraph_client.py
Ask about the repo:

The client uses langchain-mcp-adapters, which pins the MCP SDK to v1 (mcp<2).

Example: guarded agent with an LLM intent classifier + safety gate (v3)

examples/langgraph_client_v3.py is the v3 agent. It sits between the LLM and the tools and runs every tool call through an intent classifier and a permission/safety gate:

Intent
  |
  v
Permission/Safety Gate
  |-- read          -> automatic
  |-- modify file   -> approval (interactive y/N)
  |-- git add       -> approval (interactive y/N)
  |-- commit        -> approval (interactive y/N)
  `-- push          -> BLOCKED (only --allow-push unlocks it)

How it works:

  1. LLM intent classifier (project_mcp.safety.IntentClassifier) classifies each tool call (name + args) into one of read / modify_file / git_add / commit / push. It asks the configured model first and falls back to a deterministic rule map when no model is configured or the answer is unparseable.

  2. Safety gate (project_mcp.safety.PermissionGate) enforces the policy:

    • read → allowed automatically.

    • modify_file / git_add / commit → prompts [y/N] in an interactive terminal. Denied in non-interactive runs unless --yes is passed.

    • push → blocked by default; only --allow-push explicitly lifts the block.

    • unknown intent → treated like an approval-gated write.

  3. The agent can only reach the MCP server if the gate returns allow; otherwise it gets a PERMISSION DENIED tool message to explain itself.

Run

# read-only: no prompt (auto-allowed)
uv run python examples/langgraph_client_v3.py "What is the current git status?"

# write path: interactive y/N approval (or --yes to auto-approve)
uv run python examples/langgraph_client_v3.py "Add notes.txt and commit it"
uv run python examples/langgraph_client_v3.py "Add notes.txt and commit it" --yes

# push: blocked unless explicitly unlocked
uv run python examples/langgraph_client_v3.py "Push to origin"                  # BLOCKED
uv run python examples/langgraph_client_v3.py "Push to origin" --allow-push     # allowed

The gate lives in the client (the standard-official place for interactive approval). The same IntentClassifier / PermissionGate classes are reusable: wire them into any agent loop, or point --yes at a non-interactive CI run.

Observability (Opik)

Set OPIK_API_KEY in .env (or OPIK_URL for a self-hosted Opik server) and the v3 agent auto-instruments Comet Opik:

  • Every LangGraph run is a trace tagged main-llm — agent reasoning + MCP tool inputs/outputs.

  • Every gate decision is a guardrail-typed span tagged security with {tool, args} as input and {intent, permission, allowed, reason} as output.

uv add opik          # dependency already in pyproject.toml
cp .env.example .env # already done? set OPIK_API_KEY
uv run python examples/langgraph_client_v3.py "What changed?"   # -> logged to Opik

Disable tracing per-run with --no-trace. If neither OPIK_API_KEY nor OPIK_URL is set, every observability helper is a no-op and the agent runs identically (zero added latency/calls).

Development

uv run pytest

Layout:

src/project_mcp/       package source (server, git_tools, file_tools, safety)
tests/                 pytest tests (unit + stdio MCP integration)
examples/              LangGraph agent clients (v2 plain, v3 guarded)
.env.example           model endpoint config template

Summary: v1 vs v2 vs v3

This project shows three ways to consume the same MCP server.

v1 — MCP Inspector

  • A lightweight GUI/debugging client that inspects a server interactively.

  • Lets you browse tools, see schemas, and fire individual calls by hand.

  • Good for validating a server's surface before wiring an agent.

  • Connection: stdio spawn of project_mcp.server via inspector config.

v2 — LangGraph + OpenRouter

  • A programmatic agent that connects to the server, grabs its tools, and lets an LLM decide which to call to answer a user question.

  • Adds an actual model (OpenRouter openrouter/free by default) on top of the MCP tool surface.

  • Reusable pattern: MCP server → LangChain tools → LangGraph ReAct agent with any open-source/OpenAI-compatible model.

  • Uses langchain-mcp-adapters, hence mcp<2.

v3 — LLM intent classifier + permission/safety gate

  • Same agent loop as v2, plus a guard layer between the model and the tools.

  • Every tool call is classified into an intent (read / modify_file / git_add / commit / push) by a dedicated LLM pass, then checked against the safety policy: reads run automatically, writes/adds/commits need approval, and pushes are blocked unless explicitly unlocked (--allow-push).

  • The classification + gating logic lives in project_mcp.safety and is fully unit-tested, so another client or UI can reuse the same gate.

Note: langchain-mcp-adapters currently only supports MCP SDK v1, which is why the project stays on mcp<2. If you need the newer MCP SDK v2 (MCPServer API), the LangChain adapter has no stable release for it yet.

Available Tools

8 tools
create_commitD
ParametersJSON Schema
NameRequiredDescriptionDefault
pathsNo
add_allNo
messageNo
repo_pathNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

file_infoD
ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_branchesD
ParametersJSON Schema
NameRequiredDescriptionDefault
repo_pathNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_logD
ParametersJSON Schema
NameRequiredDescriptionDefault
countNo
repo_pathNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_statusD
ParametersJSON Schema
NameRequiredDescriptionDefault
repo_pathNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list_dirD
ParametersJSON Schema
NameRequiredDescriptionDefault
pathNo.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

read_fileD
ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes
max_charsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

write_fileD
ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes
contentYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.1/5.0
Disambiguation5/5

The tools fall into two clear groups—Git operations (get_status, get_log, get_branches, create_commit) and file operations (list_dir, read_file, write_file, file_info)—with no meaningful overlap. Each name points to a distinct resource and action, so an agent should rarely misselect.

Naming Consistency4/5

Most tools follow a consistent verb_noun pattern (get_status, get_log, get_branches, create_commit, list_dir, read_file, write_file). file_info is the one outlier because it uses noun_info rather than a verb, but the rest of the set remains predictable.

Tool Count5/5

Eight tools is a well-scoped size for a lightweight Git and file manipulation server. Each tool covers a distinct, useful operation without redundancy or bloat.

Completeness4/5

The set supports a coherent workflow: inspect repository state, browse/edit files, and create commits. It lacks branch creation/checkout and diff/staging operations, but the core status/log/branches/commit/file surface is functional for basic Git workflows.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • GitPilot MCP

    DarkRyan721
    A
    license
    Not graded
    quality
    Not graded
    maintenance
    A lightweight MCP server that enables AI assistants to manage local Git repositories by executing commands like status, add, and commit. It streamlines development workflows by providing repository context and diffs directly to the assistant.

  • Git MCP Server

    wty0512
    A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that provides tools for interacting with Git repositories, enabling AI assistants to manage repositories, branches, commits, and files through a standardized interface.
    7,389
    1
    Apache 2.0

  • MCP Git Manager

    AMEOBIUS-space
    A
    license
    Not graded
    quality
    C
    maintenance
    An MCP server that gives AI agents git repository access: status, log, diff, branch, commit, push, pull, tag, stash, remotes — 24 tools, zero dependencies, pure Python stdlib (subprocess).
    MIT

  • git-summary-mcp

    yifanyifan897645
    A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that gives AI assistants deep understanding of your local Git repositories, providing instant repo overviews, change summaries, blame analysis, changelogs, branch health checks, and history search.
    62
    MIT

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/prashant-ai-lab/git-mcp'

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