What can you do with this server?

This server provides an MCP-based Git workflow assistant that integrates with GitHub, Leantime project management, and Slack. All tools are deterministic — the AI agent (Claude Code, Codex) supplies the intelligence for commit messages, branch names, and PR writing. Workflow Prompts * /ai-git:aicommit — Stage-aware commit with AI-generated conventional commit message * /ai-git:aibranch — Create a branch automatically from a Leantime ticket * /ai-git:aipr — Create or update a GitHub PR with AI-written title/body + Slack notification * /ai-git:aireview — Fetch PR diff, perform AI code review, and post it as a PR comment Git Tools * git_status — Current branch, ahead/behind status, staged/unstaged/untracked files * git_staged_diff — Full git diff --cached output for writing commit messages * git_log_for_pr — Commits on current branch since base branch, for PR context * git_commit — Commit staged changes with an agent-authored message * git_create_branch — Create/switch to a branch named type/ - (auto-derived from ticket) * git_create_or_update_pr — Push branch and open or edit a GitHub PR (requires gh CLI) * git_undo_last_commit — Soft-reset the last commit without losing work Leantime Tools * leantime_list_my_tickets — List up to 100 tickets assigned to you (or a specific user) * leantime_get_ticket — Fetch full ticket details plus a pre-formatted PR-ready markdown block * List Leantime users to find user IDs Slack Tools * Post PR creation/update notifications to a configured Slack channel * Send arbitrary messages via a Slack webhook

Which integrations are available for this server?

Provides tools for git operations including checking status, viewing staged diffs, committing changes, creating branches, and undoing commits. Allows creating or updating GitHub pull requests with AI-written titles and bodies, optionally linking to Leantime tickets.

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ai-git aicommit with hint about fixing typo" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

ai-git

by khanhld2109

Overview Schema Related Servers Score Discussions

TypeScript

Remote

ai-git-mcp

An MCP server that reimplements the ai-git-fish workflows — aicommit, aibranch, aipr — with Leantime integration, without fish shell and without DeepSeek. Wire it up once and the same workflows work in Claude Code and Codex.

Why no AI inside the server?

ai-git-fish calls DeepSeek to generate commit messages and PR text. But Claude Code and Codex are already the AI. So this server contains no LLM: every tool is deterministic. The agent reads the diff/ticket through a tool, writes the prose itself, and passes it into the next tool. No paying for AI twice, no losing context, and the agent understands your code better than DeepSeek.

Agent (Claude/Codex)  ──calls tools──>  ai-git-mcp  ──>  git / gh CLI
        │                                    │
        └── writes commit/PR/slug            └──>  Leantime JSON-RPC (/api/jsonrpc)

Related MCP server: local-git-mcp

Requirements

On the machine that runs the agent:

Node.js ≥ 18 (node -v)
git in PATH (git --version)
GitHub CLI gh, authenticated (gh auth login) — needed only for aipr
A Leantime instance + API key — needed only for the ticket tools

You do not need to clone this repo. npx fetches and builds it for you (see below).

Installation

1. Get your Leantime credentials

Value	Where to find it
`LEANTIME_BASE_URL`	Your Leantime URL, e.g. `https://leantime.example.com`
`LEANTIME_API_KEY`	Leantime → your profile → API Keys → generate one
`LEANTIME_USER_ID`	Your numeric user id — see the tip below

Finding your LEANTIME_USER_ID the easy way (replaces ai-git-fish's installer fzf picker): set just LEANTIME_BASE_URL + LEANTIME_API_KEY first, restart, then ask the agent to run leantime_list_users. It prints every user with their id — copy yours into the env and restart. (Or: open your profile and read the id from the URL, e.g. .../users/editUser/5 → 5.)

2. Add the server to your client

Pick your client. The npx -y github:BenBen2109/ai-git-mcp command downloads this repo, builds it once, caches it, and runs it — no manual clone or build.

Option A — one command:

claude mcp add ai-git \
  -e LEANTIME_BASE_URL=https://leantime.example.com \
  -e LEANTIME_API_KEY=your-key \
  -e LEANTIME_USER_ID=123 \
  -- npx -y github:BenBen2109/ai-git-mcp

Option B — edit .mcp.json (project root) or ~/.claude.json (global):

{
  "mcpServers": {
    "ai-git": {
      "command": "npx",
      "args": ["-y", "github:BenBen2109/ai-git-mcp"],
      "env": {
        "LEANTIME_BASE_URL": "https://leantime.example.com",
        "LEANTIME_API_KEY": "your-key",
        "LEANTIME_USER_ID": "123"
      }
    }
  }
}

Edit ~/.codex/config.toml:

[mcp_servers.ai-git]
command = "npx"
args = ["-y", "github:BenBen2109/ai-git-mcp"]
env = { LEANTIME_BASE_URL = "https://leantime.example.com", LEANTIME_API_KEY = "your-key", LEANTIME_USER_ID = "123" }

Pin a version by appending a tag/branch/commit: github:BenBen2109/ai-git-mcp#v1.0.0. The first launch is slower (it builds once); later launches use the npx cache.

3. Restart and verify

Restart the client (or reload the MCP config). Then check the server is connected:

Claude Code: run /mcp — ai-git should show 14 tools and 4 prompts.
Codex: the ai-git tools appear in the tool list at startup.

Configuration (env)

Variable	Required	Meaning
`LEANTIME_BASE_URL`	ticket tools	e.g. `https://leantime.example.com`
`LEANTIME_API_KEY`	ticket tools	sent as the `x-api-key` header
`LEANTIME_USER_ID`	recommended	numeric id used to filter your tickets
`LEANTIME_PICK_LIMIT`	optional	max tickets listed (default 30)
`SLACK_WEBHOOK_URL`	Slack tools	Incoming Webhook URL; the channel is fixed on the Slack side
`PR_PREVIEW_URL_TEMPLATE`	optional	Deploy-preview URL with a `{pr}` placeholder, e.g. `https://frontend-preview-{pr}--anymatemeproject.netlify.app`. Adds a Preview line to the Slack PR message
`SLACK_USER_MAP`	optional	JSON map of name/login → Slack member ID, e.g. `{"khanhld":"U012ABC"}`, for @-mentions
`SLACK_PR_REVIEWERS`	optional	Who to @-mention on every PR — comma list of names (from the map), raw Slack ids, or `here`/`channel`

The git-only tools (git_status, git_staged_diff, git_commit, git_log_for_pr, git_create_branch, git_create_or_update_pr, git_undo_last_commit) work without any Leantime config. See .env.example.

Usage — slash commands

Three workflows, exposed as MCP prompts. In Claude Code type the slash command; in Codex just say it in plain language (e.g. "run aicommit") — the agent calls the same tools either way.

`/ai-git:aicommit [hint]` — stage-aware commit

Reads your staged diff, writes a Conventional Commit message, shows it to you, then commits.

# stage what you want first
git add -p

# then, in the agent:
/ai-git:aicommit
/ai-git:aicommit drop the debug logging   # optional hint to steer the message

→ git_staged_diff → (agent writes message) → git_commit

`/ai-git:aibranch [type]` — branch from a Leantime ticket

Lists your tickets, you pick one, it creates/switches to type/<id>-<slug> (slug auto-derived from the ticket headline, Vietnamese diacritics handled).

/ai-git:aibranch          # type defaults to "feat" → feat/1234-add-login
/ai-git:aibranch fix      # → fix/1234-add-login

→ leantime_list_my_tickets → (you pick) → git_create_branch

If LEANTIME_USER_ID isn't set (or you want someone else's tickets), the agent calls leantime_list_users first, you pick a person, and it lists that user's tickets via assignee_id — the equivalent of ai-git-fish's fzf user picker.

`/ai-git:aipr [hint]` — open or update a GitHub PR

Pushes the branch and creates (or updates) its PR with an AI-written title and body. If the branch is named type/<id>-<slug>, the Leantime ticket is auto-linked and embedded.

/ai-git:aipr
/ai-git:aipr focus on the migration   # optional hint to steer the PR

→ git_status + git_log_for_pr → (agent writes title/body) → git_create_or_update_pr → slack_post_pr

After the PR is created/updated, it sends a formatted notification to the team Slack channel (via SLACK_WEBHOOK_URL). If Slack isn't configured, that step is skipped with a note.

`/ai-git:aireview <pr> [spec]` — review a PR and post the review

Fetches the PR + diff, reviews it against the team checklist (Functionality, Security, Error Handling, Code Quality, Performance, Style), writes the review in English following a fixed format, and posts it as a PR comment. Optionally validates against a Redmine spec URL.

/ai-git:aireview https://github.com/org/repo/pull/42
/ai-git:aireview https://github.com/org/repo/pull/42 https://redmine.example.com/issues/1234

Prefer the full PR URL — it tells gh which repo the PR is in. A bare number (42) only resolves when repo_path is the PR's repository.

→ git_pr_view → (agent reviews, + Redmine spec via the agent's redmine tools if given) → git_pr_comment

Boundaries: never approves or merges, never changes code without approval.

Tools reference

All tools return JSON. Each accepts an optional repo_path (defaults to the server's working directory) unless noted.

Leantime

Tool	Params	Returns
`leantime_list_users`	—	`{ count, users: [{ id, name, username, isConfigured }] }` (setup helper to find your `LEANTIME_USER_ID`)
`leantime_list_my_tickets`	`limit?` (1–100), `assignee_id?`	`{ count, assigneeId, filtered, tickets: [{ id, headline, statusLabel, projectName, assignee, dueDate, url, description }] }` (description is a ~200-char snippet, like the fzf preview; `filtered:false` means no `LEANTIME_USER_ID` and no `assignee_id` → all tickets)
`leantime_get_ticket`	`id`	`{ found, id, headline, description, statusLabel, dueDate, url, markdown }`

Git — read-only

Tool	Params	Returns
`git_status`	`repo_path?`	`{ branch, ahead, behind, staged[], unstaged[], untracked[] }`
`git_staged_diff`	`repo_path?`, `max_bytes?`	`{ diff, files: [{ path, status }], isEmpty, truncated }`
`git_log_for_pr`	`base?`, `repo_path?`	`{ base, count, commits: [{ sha, subject, body }] }`
`git_pr_view`	`pr`, `max_bytes?`, `repo_path?`	`{ number, title, body, state, author, baseRefName, headRefName, url, additions, deletions, changedFiles, files[], diff, diffTruncated }`

Git — write

Tool	Params	Returns
`git_commit`	`message`, `repo_path?`	`{ sha, shortStat }`
`git_create_branch`	`ticket_id`, `type?`, `slug?`, `repo_path?`	`{ branch, created }`
`git_create_or_update_pr`	`title`, `body`, `ticket_id?`, `base?`, `draft?`, `repo_path?`	`{ url, number, action }`
`git_pr_comment`	`pr`, `body`, `repo_path?`	`{ url }` — posts a comment (e.g. a review); never approves/merges
`git_undo_last_commit`	`repo_path?`	`{ undoneSha, message }`

Slack

Tool	Params	Returns
`slack_post_pr`	`title`, `url`, `number?`, `author?`, `ticket_id?`, `mention?`	`{ ok }` — posts Author / PR / Preview / Ticket / Feat / Reviewers (@-mentions) to the webhook channel
`slack_send_message`	`text`, `mention?`	`{ ok }` — plain Slack mrkdwn message, optional @-mentions

@-mentions: Slack only pings by member id (<@U…>), not by display name. Set SLACK_USER_MAP to map names → ids, then list reviewers in SLACK_PR_REVIEWERS (or pass mention per call). here/channel work without any map.

Notes:

git_commit fails with an actionable message if nothing is staged.
git_create_branch auto-derives the slug from the ticket headline when slug is omitted.
git_create_or_update_pr pushes HEAD, detects an existing PR for the branch (edits it) or creates a new one, and appends the ticket markdown block when ticket_id is given.
git_undo_last_commit is a soft reset — your changes stay staged, nothing is lost.

Troubleshooting

Symptom	Fix
`Leantime is not configured`	Set `LEANTIME_BASE_URL` + `LEANTIME_API_KEY` in the server `env`.
`Not a git repository`	Run the agent from inside a git repo, or pass `repo_path`.
`Nothing staged to commit`	`git add` your changes first.
`gh ... failed` on `aipr`	Run `gh auth login`; ensure the repo has a GitHub remote.
`npx` is slow on first run	Expected — it builds once, then caches. Pin a tag to stabilise.
Slash commands missing in Codex	Codex prompt support varies; just say "run aicommit" instead.

Local development

git clone https://github.com/BenBen2109/ai-git-mcp
cd ai-git-mcp
npm install
npm run build      # → dist/index.js
npm test           # vitest
npm run dev        # tsx watch (live reload)

Local-path config (instead of npx):

{ "mcpServers": { "ai-git": {
  "command": "node",
  "args": ["/absolute/path/to/ai-git-mcp/dist/index.js"],
  "env": { "LEANTIME_BASE_URL": "...", "LEANTIME_API_KEY": "...", "LEANTIME_USER_ID": "..." }
}}}

Credits

Leantime client and ticket formatting (HTML/entity decoding, status labels, PR markdown block) are ported from ai-git-fish by DucTam2411.

Available Tools

9 tools

git_commitGit CommitA

Commit the currently staged changes with the given message (the agent-authored Conventional Commit).

Fails with an actionable message if nothing is staged.

Args:

message (string): the full commit message (subject + optional body)
repo_path (string, optional): repository path (default: server cwd)

Returns JSON: { sha, shortStat }

ParametersJSON Schema

Name	Required	Description	Default
`message`	Yes	Full commit message
`repo_path`	No	Path to the git repository. Defaults to the server's working directory.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations indicate not read-only, not destructive, not idempotent. The description adds that it commits staged changes, fails with an actionable message if nothing is staged, and returns JSON { sha, shortStat }. This goes beyond annotations by explaining failure mode and return format. No contradiction.

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 very concise, with a clear header, failure condition, an Args section, and return format. It uses bullet points for parameters and a simple structure. Every sentence adds value.

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 the simple tool (2 params, no output schema), the description covers the purpose, failure condition, default for optional param, and return type. It is complete enough for an agent to use correctly without additional context.

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 covers 100% of parameters, but the description adds that the message should be a 'Conventional Commit' and that repo_path defaults to server CWD. This adds meaningful usage context beyond the schema definitions.

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?

The description clearly specifies the action (commit) and resource (staged changes), and distinguishes from sibling tools like git_undo_last_commit or git_staged_diff by using the unique verb 'commit'. It also adds context about Conventional Commit format.

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

Usage Guidelines4/5

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

The description states a failure condition if nothing is staged, implying it should only be used when there are staged changes. However, it does not explicitly mention when to use alternatives like git_undo_last_commit or git_create_branch. The sibling list provides context but the description itself lacks explicit exclusions.

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

git_create_branchGit Create BranchA

Idempotent

Create (or switch to) a branch named type/<ticket_id>-<slug> (the aibranch workflow).

If slug is omitted, the ticket headline is fetched from Leantime and slugified (Vietnamese diacritics handled).

Args:

ticket_id (string|number): Leantime ticket id
type (string, optional): branch type prefix (default "feat")
slug (string, optional): explicit slug; auto-derived from the ticket headline if omitted
repo_path (string, optional): repository path (default: server cwd)

Returns JSON: { branch, created }

ParametersJSON Schema

Name	Required	Description
`ticket_id`	Yes	Leantime ticket id
`type`	No	Branch type prefix, e.g. feat/fix/chore (default feat)
`slug`	No	Explicit slug; auto-derived from ticket headline if omitted
`repo_path`	No	Path to the git repository. Defaults to the server's working directory.

TDQS

A4.5/5.0

Behavior4/5

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

Description adds value beyond annotations by detailing the auto-derivation of slug from Leantime, handling of Vietnamese diacritics, and the return format. Annotations already indicate idempotent and non-destructive, which aligns with the description's 'create or switch' behavior.

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?

Well-structured with a clear workflow statement followed by an argument list. Slightly verbose with the args list being redundant given schema, but front-loaded purpose makes it effective. Could be more concise by trimming repetitive elements.

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 no output schema, the description provides the return format. Covers the entire workflow including external dependency (Leantime), defaults, and edge cases (slug omission). Completes the picture for an agent to use the tool independently.

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

Parameters5/5

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

Schema coverage is 100%, yet the description enriches understanding by explaining the naming pattern and the interaction between ticket_id and slug (auto-derived from Leantime). Provides meaning beyond parameter names and schema descriptions.

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?

Clearly states 'Create (or switch to) a branch named `type/<ticket_id>-<slug>' and references the 'aibranch workflow'. Distinguishes from sibling tools like git_commit or git_create_or_update_pr by its specific branch creation purpose.

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

Usage Guidelines4/5

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

Explains the branch naming convention, how slug is derived from Leantime ticket, and defaults for type and repo_path. Does not explicitly mention when not to use or compare to alternatives, but the context is sufficiently clear for an agent to infer appropriate usage.

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

git_create_or_update_prGit Create Or Update PRA

Push the current branch and create or update its GitHub PR (the aipr workflow). Requires gh authenticated.

The agent supplies title and body. If ticket_id is given, the Leantime ticket markdown block is appended to the body. Detects an existing PR for the branch and edits it, otherwise creates a new one.

Args:

title (string): PR title
body (string): PR body (markdown)
ticket_id (string|number, optional): Leantime ticket to embed
base (string, optional): base branch for a new PR
draft (boolean, optional): open as draft (new PRs only)
repo_path (string, optional): repository path (default: server cwd)

Returns JSON: { url, number, action: "created" | "updated" }

ParametersJSON Schema

Name	Required	Description
`title`	Yes	PR title
`body`	Yes	PR body in markdown
`ticket_id`	No	Leantime ticket id to embed
`base`	No	Base branch (new PRs only)
`draft`	No	Open as draft (new PRs only)
`repo_path`	No	Path to the git repository. Defaults to the server's working directory.

TDQS

A4.5/5.0

Behavior4/5

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

The description adds behavioral context beyond annotations, such as the push action, authentication requirement, and the detect-edit-or-create logic. Annotations already indicate mutability (readOnlyHint=false, idempotentHint=false), so the description enriches without contradiction.

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 concise and well-structured: a lead sentence, prerequisite, behavior summary, and an Args section. Every sentence adds value without redundancy.

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 the tool's complexity (6 params, no output schema), the description is thorough. It covers the workflow, prerequisites, parameter details, return format, and integration with Leantime. It is complete for an agent to invoke correctly.

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%, but the description adds meaning for ticket_id (appends Leantime block), base (for new PRs), draft (new PRs only), and repo_path (default cwd). It improves clarity beyond the schema alone.

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?

The description clearly states the tool pushes the current branch and creates or updates its GitHub PR, with a specific verb and resource. It distinguishes from sibling tools like git_commit and git_create_branch by focusing on PR management.

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

Usage Guidelines4/5

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

The description provides context for when to use the tool, including prerequisites (gh authenticated) and behavioral details (detects existing PR or creates new one). It lacks explicit alternatives or when-not-to-use guidance, but the sibling context makes differentiation clear.

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

git_log_for_prGit Log For PRA

Read-onlyIdempotent

List commits on the current branch since the base branch, for writing a PR title/body (the aipr workflow).

If base is omitted, it is auto-detected (origin/HEAD, else main/master). Read-only.

Args:

base (string, optional): base branch/ref to compare against
repo_path (string, optional): repository path (default: server cwd)

Returns JSON: { base, count, commits: [{ sha, subject, body }] }

ParametersJSON Schema

Name	Required	Description	Default
`base`	No	Base branch/ref
`repo_path`	No	Path to the git repository. Defaults to the server's working directory.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already mark readOnlyHint, destructiveHint, idempotentHint. The description adds valuable auto-detection behavior and return format details, which go beyond the annotations. No contradiction.

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?

Four sentences with no wasted words. The purpose is front-loaded, and each sentence adds distinct value. The structure is efficient and easy to parse.

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 the low complexity (2 params, no output schema), the description covers the use case, auto-detection, read-only nature, and return format. It provides enough context for correct invocation without gaps.

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%, but the description adds extra meaning: base can be auto-detected, repo_path defaults to server cwd, and the args section clarifies optionality. This helps the agent understand parameter behavior beyond the schema.

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?

The description clearly states the tool lists commits on the current branch since the base branch, and explicitly ties it to the PR title/body workflow. This specificity distinguishes it from sibling tools like git_status or git_commit.

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

Usage Guidelines4/5

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

The description includes the use case ('for writing a PR title/body') and explains auto-detection of base if omitted. While it doesn't provide explicit 'when not to use' guidance, the context is sufficient for an agent to decide appropriately among siblings.

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

git_staged_diffGit Staged DiffA

Read-onlyIdempotent

Return the staged diff (git diff --cached) plus a per-file status list, for writing a commit message.

This is the first step of the aicommit workflow: read the diff, write a Conventional Commit message, then call git_commit. Read-only.

Args:

repo_path (string, optional): repository path (default: server cwd)
max_bytes (number, optional): truncate the diff above this size (default 100000)

Returns JSON: { diff, files: [{ path, status }], isEmpty, truncated }

ParametersJSON Schema

Name	Required	Description	Default
`repo_path`	No	Path to the git repository. Defaults to the server's working directory.
`max_bytes`	No	Truncate diff above this many bytes

TDQS

A4.5/5.0

Behavior4/5

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

Description reinforces the read-only annotations and adds details about return structure (diff, files, isEmpty, truncated) and truncation behavior. No contradictions with annotations.

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 extremely concise: two sentences for purpose and workflow, then parameter and return details. Every sentence adds value, and the structure front-loads the key information.

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?

Even without an output schema, the description fully details the return JSON structure. It covers purpose, parameters with defaults, return fields, and workflow integration, making it complete for a simple tool with two parameters.

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?

The description adds default values for both parameters (repo_path: server cwd, max_bytes: 100000) beyond the input schema, which only describes them without defaults. Schema coverage is 100%, so the addition is helpful but not essential.

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?

Description clearly states the tool returns the staged diff and per-file status for writing a commit message, distinguishing it from siblings like git_commit and git_status. The verb 'Return' and resource 'staged diff' are specific.

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

Usage Guidelines4/5

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

Explicitly positions the tool as the first step of the aicommit workflow, guiding the agent to call git_commit after. While it doesn't list when not to use it, the workflow context provides clear usage guidance.

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

git_statusGit StatusA

Read-onlyIdempotent

Report the current branch, upstream ahead/behind counts, and staged/unstaged/untracked files.

Use to orient before committing or opening a PR, and to parse a ticket id from a branch named type/<id>-<slug>. Read-only.

Args:

repo_path (string, optional): repository path (default: server cwd)

Returns JSON: { branch, ahead, behind, staged[], unstaged[], untracked[] }

ParametersJSON Schema

Name	Required	Description	Default
`repo_path`	No	Path to the git repository. Defaults to the server's working directory.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and destructiveHint false. The description adds that it is 'Read-only' and describes the return JSON structure (branch, ahead, behind, etc.), adding value beyond annotations.

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 concise, using bullet points for args and return. Every sentence adds value, with no wasted words.

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 the simple one-parameter tool, annotations, and full schema coverage, the description covers purpose, usage, and exact return format. It even includes an extra feature (ticket ID parsing).

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

Parameters3/5

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

The only parameter (repo_path) is fully described in the input schema (100% coverage). The tool description repeats the schema's info almost verbatim, adding minimal additional meaning.

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?

The description clearly specifies the tool reports branch, ahead/behind counts, and file statuses. It also mentions parsing ticket IDs from branch names. This distinguishes it from siblings like git_log_for_pr and git_staged_diff.

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

Usage Guidelines4/5

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

The description explicitly states 'Use to orient before committing or opening a PR, and to parse a ticket id', providing clear context. It lacks explicit when-not-to-use guidance but is otherwise strong.

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

git_undo_last_commitGit Undo Last CommitA

Destructive

Soft-reset the last commit (git reset --soft HEAD~1): removes the commit but keeps all its changes staged. Safe — no work is lost.

Args:

repo_path (string, optional): repository path (default: server cwd)

Returns JSON: { undoneSha, message }

ParametersJSON Schema

Name	Required	Description	Default
`repo_path`	No	Path to the git repository. Defaults to the server's working directory.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations provide destructiveHint: true, and the description elaborates that the commit is removed but changes remain staged, clarifying the 'destructive' aspect as safe. It adds context about the effect on workspace and git history beyond what annotations tell.

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 succinct, with the main action stated first, followed by the git equivalent, parameter details, and return format. No extraneous text.

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 simple tool with one parameter and clear annotations, the description covers behavior, safety, and return value format. No missing information needed for correct invocation.

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% for the one parameter, and the description adds value by stating the default behavior ('default: server cwd'). The schema already includes a description, so this is clear reinforcement.

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?

The description clearly states the action ('Soft-reset the last commit') and provides the exact git command, making the purpose unmistakable. It distinguishes from siblings like 'git_commit' and 'git_create_branch' by focusing on undoing a commit.

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

Usage Guidelines3/5

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

The description explains the safety aspect ('no work is lost') and gives the git command, but lacks explicit guidance on when to use this tool versus alternatives (e.g., when the commit has not been pushed, or contrast with hard reset). No mention of preconditions or exclusions.

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

leantime_get_ticketGet Leantime TicketA

Read-onlyIdempotent

Fetch one Leantime ticket's full detail, including an HTML-stripped description and a PR-ready markdown block.

Use this for context when writing a commit/PR, or to preview the markdown that gets embedded in a PR body. Read-only.

Args:

id (string|number): the ticket id

Returns JSON: { id, headline, description, statusLabel, dueDate, url, markdown } or { found: false }

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Ticket id

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already indicate read-only, idempotent, etc. Description adds behavior like HTML stripping, markdown generation, and the {found: false} case. No contradictions.

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?

Very concise: two short paragraphs plus example. Front-loaded with main purpose. Every sentence adds value.

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?

Despite no output schema, the description fully specifies return fields and the not-found case. Complete for a one-parameter read tool.

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

Parameters3/5

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

Input schema has 100% coverage with description 'Ticket id'. Description repeats parameter in Args without adding new semantics beyond the schema.

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?

The description clearly states the tool fetches one ticket's full detail with specific outputs (HTML-stripped description, PR-ready markdown), distinguishing it from sibling tools like leantime_list_my_tickets.

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

Usage Guidelines4/5

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

Explicitly says to use for context when writing commit/PR or previewing markdown, implying read-only nature. Does not explicitly state when not to use, but context is clear.

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

leantime_list_my_ticketsList My Leantime TicketsA

Read-onlyIdempotent

List Leantime tickets assigned to the configured user (LEANTIME_USER_ID), newest first.

Use this to let the user pick a ticket before creating a branch (the aibranch workflow). Read-only.

Args:

limit (number, optional): max tickets to return (1-100, default from LEANTIME_PICK_LIMIT or 30)

Returns JSON: { count, tickets: [{ id, headline, statusLabel, projectName, dueDate, url }] }

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max tickets to return

TDQS

A4.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it is read-only and specifies the sorting order (newest first), but does not add extensive behavioral detail beyond the annotations.

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 concise with three sentences, a structured argument list, and a return format. It is front-loaded with the core purpose and contains no fluff.

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?

The description covers purpose, usage context, parameter details, and return format. For a simple tool with one optional parameter and no output schema, it provides all necessary information.

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?

The input schema describes the 'limit' parameter with min, max, and description. The description adds the default value (from LEANTIME_PICK_LIMIT or 30) and clarifies the range, providing useful context beyond the schema.

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?

The description clearly states it lists tickets assigned to the configured user, sorted newest first. It distinguishes itself from sibling tools like leantime_get_ticket (singular) and git tools.

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

Usage Guidelines4/5

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

The description explicitly says to use this for the aibranch workflow (selecting a ticket before creating a branch). It doesn't explicitly state when not to use it or alternatives, but the given context is sufficient.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

9 tool updatesv1.0.0Jun 4, 2026
- First observedgit_commit
- First observedgit_create_branch
- First observedgit_create_or_update_pr
- First observedgit_log_for_pr
- First observedgit_staged_diff
- First observedgit_status
- First observedgit_undo_last_commit
- First observedleantime_get_ticket
- First observedleantime_list_my_tickets

Install Server

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

TDQS

A4.6/5.0

Disambiguation5/5

All 9 tools have distinct, non-overlapping purposes. Git operations (commit, branch, PR, diff, status, undo, log) are clearly separated from Leantime operations (get ticket, list tickets). No ambiguity in tool selection.

Naming Consistency5/5

All tools use snake_case with a consistent `<domain>_<verb>_<noun>` pattern (git_* and leantime_*). Verbs like create, get, list, log, commit, undo are used uniformly, making the naming predictable and easy to understand.

Tool Count5/5

9 tools is well-scoped for the integrated git+Leantime workflow. Each tool serves an essential step in the aibranch, aicommit, and aipr workflows without unnecessary duplication or bloat.

Completeness5/5

The tool set covers the entire intended workflow: branch creation from tickets, staging diff review, committing, PR log generation, PR creation/update, status checks, undo, and ticket retrieval. No critical gaps for the described use cases.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

neverinfamous-memory-journal-mcp
ai.smithery
A MCP server built for developers enabling Git based project management with project and personal…
Version Control Developer Tools Project Management
320
gread A
io.github.NitroRCr
An MCP server that gives your AI access to the source code and docs of all public github repos
Version Control Code Analysis Documentation Access
5361
Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
214
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2

Related MCP Servers

Jira - GitHub MCP Server
Version Control Project Management Developer Tools
garbvalley
A
license
Not graded
quality
D
maintenance
A modular MCP server integrating Jira and GitHub to automate developer workflows, enabling AI agents to manage issues, branches, commits, and pull requests directly from the IDE.
Updated 3 months ago (2026-06-18 00:26 UTC)
MIT
local-git-mcp
Version Control Developer Tools
jrokeach
A
license
Not graded
quality
D
maintenance
A lightweight MCP server that handles git operations on behalf of AI coding assistants, running as a local HTTP service without external network exposure by default.
Updated 5 months ago (2026-04-14 00:55 UTC)
MIT
mcp-gh-forge
Version Control Command Line
pluto-atom-4
F
license
B
quality
B
maintenance
A lightweight MCP server that acts as a secure proxy for AI assistants to run local Git operations and GitHub API macros simultaneously.
Updated 24 days ago (2026-08-12 21:11 UTC)
1
-
okffs
Version Control Project Management
neturely
A
license
Not graded
quality
A
maintenance
An MCP server that lets Claude Code manage GitHub issues, branches, and pull requests through natural language, automating the full development workflow from planning to closing.
Updated 16 days ago (2026-08-21 07:53 UTC)
108
2
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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

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

ai-git-mcp

Why no AI inside the server?

Requirements

Installation

1. Get your Leantime credentials

2. Add the server to your client

3. Restart and verify

Configuration (env)

Usage — slash commands

/ai-git:aicommit [hint] — stage-aware commit

/ai-git:aibranch [type] — branch from a Leantime ticket

/ai-git:aipr [hint] — open or update a GitHub PR

/ai-git:aireview <pr> [spec] — review a PR and post the review

Tools reference

Leantime

Git — read-only

Git — write

Slack

Troubleshooting

Local development

Credits

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`/ai-git:aicommit [hint]` — stage-aware commit

`/ai-git:aibranch [type]` — branch from a Leantime ticket

`/ai-git:aipr [hint]` — open or update a GitHub PR

`/ai-git:aireview <pr> [spec]` — review a PR and post the review