ai-git

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.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.
Average 4.4/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 22 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ai-git-mcp MCP server](https://glama.ai/mcp/servers/khanhld2109/ai-git-mcp/badges/card.svg)](https://glama.ai/mcp/servers/khanhld2109/ai-git-mcp)

Score Badge

Copy to your README.md:

[![ai-git-mcp MCP server](https://glama.ai/mcp/servers/khanhld2109/ai-git-mcp/badges/score.svg)](https://glama.ai/mcp/servers/khanhld2109/ai-git-mcp)

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