What can you do with this server?

A local MCP server that exposes a controlled set of native Git operations for managing repositories programmatically. * Inspect repository status (git_status): Read branch, HEAD, index/worktree state, and a worktree snapshot ID — without any mutation. * View diffs (git_diff): Retrieve a byte-limited diff of worktree changes (vs. index) or staged changes (vs. HEAD). * Create and switch branches (git_switch_create): Create a new branch and switch to it, with exact branch/HEAD preflight checks. * Attach detached HEAD to a branch (git_switch_attach): Attach a clean detached worktree to an existing local branch sharing the same HEAD. * Stage files (git_add): Stage declared paths in a normal stage session or as part of conflict resolution in a merge session. * Unstage files (git_restore_staged): Destructively unstage paths owned by a stage session, restoring them from HEAD in the index. * Restore worktree files (git_restore_worktree): Destructively restore tracked worktree paths from the current index, protected by a snapshot guard. * Commit staged changes (git_commit): Commit the index owned by a stage session with a supplied message; native pre-commit and commit-msg hooks run, with hook failure details redacted. * Fetch from remote (git_fetch): Fetch from origin and record observed remote refs in a fetch session. * Merge remote refs (git_merge): Merge an expected fetched origin tracking ref; conflicts initiate an owned merge session with a list of conflicted paths. * Continue a merge (git_merge_continue): Complete a conflicted merge session after all conflicts have been resolved and staged. * Abort a merge (git_merge_abort): Destructively abort an in-progress merge session and restore the original state. * Push to remote (git_push): Push the current branch to origin using an expected remote HEAD for atomic lease comparison. * Replay durable operation results (git_operation_get): Retrieve the stored result of a previous mutation request by its UUID, enabling safe replay without re-executing the mutation.

Which integrations are available for this server?

Provides tools for performing native Git operations such as status, diff, branch creation, staging, committing, fetching, merging, and pushing.

How do I use git-mcp-server?

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., "@git-mcp-server check the current git status" 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.

git-mcp-server

by saitolume

Overview Schema Related Servers Score Discussions

TypeScript

Local

git-mcp-server

git-mcp-server is a local stdio Model Context Protocol (MCP) server for a small, explicit set of native Git operations. It is a development preview, not an npm stable release or a general shell.

Status

Version 0.1.0-beta.3 is the npm development preview of @saitolume/git-mcp-server and is distributed only under the beta tag. The latest tag and an npm stable release are not available. A stable release remains a separate gate: it needs an exact stable MCP SDK, provider acceptance across a broader set of clients, and hosted CI evidence.

Related MCP server: git-mcp-server

Requirements

The built runtime requires Node.js >=22, native Git 2.39.0 or later on PATH, and a trusted local Git repository. Building from source requires Node.js

=22.13 and pnpm@11.15.1.

Run the beta

Start the published development preview with the explicit beta tag:

npx --yes @saitolume/git-mcp-server@beta

Do not omit @beta; this preview does not use the latest tag.

Build from source

Clone this repository, then enter its directory and run:

pnpm install --frozen-lockfile
pnpm build

MCP configuration

Configure an MCP client to start the explicit npm beta:

{
  "mcpServers": {
    "git": {
      "command": "npx",
      "args": ["--yes", "@saitolume/git-mcp-server@beta"]
    }
  }
}

For a source build, run the built server with node /absolute/path/dist/cli.js. Use an absolute path to the checkout because an MCP client's working directory may be undefined.

After installing a build that contains a new tool, fully restart the MCP server process and the client session that launched it so the client discovers the new tool schema. For this unreleased source change, check out the implementing commit, run pnpm install --frozen-lockfile && pnpm build, keep the absolute dist/cli.js configuration above, and restart both processes.

Tools

Tool	Purpose
`git_status`	Read repository identity, branch, HEAD, index/worktree state, and a worktree snapshot ID.
`git_diff`	Return a byte-limited worktree or staged diff for declared paths.
`git_switch_create`	Create and switch to a branch after exact attached-or-detached branch and HEAD preflight.
`git_switch_attach`	Attach a clean detached worktree to an existing same-HEAD local branch after exact current and target preflight.
`git_add`	Stage declared paths, or mark declared conflict paths resolved.
`git_restore_staged`	Destructively unstage declared paths owned by a stage session.
`git_restore_worktree`	Destructively restore declared paths after a worktree snapshot guard.
`git_commit`	Commit the exact active stage session with the supplied message; native `pre-commit` and `commit-msg` rejection returns a redacted `HOOK_FAILED`.
`git_fetch`	Fetch `origin` and record observed remote refs in a fetch session.
`git_merge`	Merge an expected fetched `origin` tracking ref, or return a conflict session.
`git_merge_continue`	Complete a declared merge session after resolved paths are staged.
`git_merge_abort`	Destructively abort a declared in-progress merge session.
`git_push`	Push an expected local branch head after checking the expected remote head; it remains fast-forward-only.
`git_push_force_with_lease`	Destructively replace the same-name branch on `origin` only with an exact caller-observed remote-head lease.
`git_commit_range_validate`	Run the native `commit-msg` hook against every commit in one exact linear `base..HEAD` range.
`git_reword`	Recreate an exact linear range with replacement messages, either on the current branch or a new local branch, while proving each tree is unchanged.
`git_commit_amend`	Replace only the current unsigned commit with an owned stage session and guarded worktree snapshot.
`git_operation_get`	Read the durable result for a request ID.

Typical workflow

Call git_status. To create a branch from an attached branch, pass its exact name as git_switch_create.expected_branch; when git_status returns branch: null, pass expected_branch: null to require that exact detached HEAD before creating the branch. Then explicitly call git_add for the paths intended for a commit, and finally call git_commit. For remote work, call git_fetch, then git_merge; when a merge reports conflicts, resolve the listed paths, call git_add, and call git_merge_continue. Use git_merge_abort only when the declared merge must be abandoned. If transport is interrupted after a request, use the same request ID with git_operation_get to replay its durable result; do not repeat the mutation.

To attach a managed worktree to an existing claimed local branch, first use git_status and require branch: null. Call git_switch_attach with exactly repository, a new request_id, expected_branch: null, the returned full expected_head, the local branch name, and its full expected_branch_head. The target branch must exist, its expected and observed HEAD must equal the detached worktree HEAD, and it must not be checked out in another worktree. The current operation state must be none; the index and complete worktree, including untracked paths, must be clean; and no bridge session may be active.

Guarded history recovery examples

Every object ID below is a full object ID and every request_id is a fixed example UUID. Replace the repository path, IDs, branch, messages, and request IDs with values from your own trusted repository. Build the implementing source commit with pnpm install --frozen-lockfile && pnpm build, retain the absolute dist/cli.js command, then restart the MCP server and client session before calling these new tools.

First validate the exact current range; validation executes the repository's native commit-msg hook for every commit, in order:

{
  "tool": "git_commit_range_validate",
  "arguments": {
    "repository": "/absolute/path/to/repository",
    "request_id": "018f47d2-7b2a-7d75-b9dd-5ea8abca0100",
    "expected_branch": "feature/history-example",
    "expected_head": "2222222222222222222222222222222222222222",
    "base": "1111111111111111111111111111111111111111"
  }
}

For the current-branch route, reword the complete ordered range, then use the separate destructive delivery tool with the remote head you just observed. The force permission is a caller approval policy: a client or user may authorize this tool, but the bridge never decides to discard remote commits. An exact remote CAS is mandatory; provider or branch protection may still reject the update.

Take a fresh observation immediately before delivery and use that exact remote head as the lease. If the remote CAS drifts, stop with the drift evidence preserved: perform no automatic refresh or retry. An explicit human decision is required before a new observation may be used to discard an externally added commit.

{
  "tool": "git_reword",
  "arguments": {
    "repository": "/absolute/path/to/repository",
    "request_id": "018f47d2-7b2a-7d75-b9dd-5ea8abca0101",
    "expected_branch": "feature/history-example",
    "expected_head": "2222222222222222222222222222222222222222",
    "base": "1111111111111111111111111111111111111111",
    "commits": [{
      "commit": "2222222222222222222222222222222222222222",
      "message": "feat(history): clarify recovery"
    }],
    "destination": { "mode": "current_branch" }
  }
}

{
  "tool": "git_push_force_with_lease",
  "arguments": {
    "repository": "/absolute/path/to/repository",
    "request_id": "018f47d2-7b2a-7d75-b9dd-5ea8abca0102",
    "expected_branch": "feature/history-example",
    "expected_head": "3333333333333333333333333333333333333333",
    "expected_remote_head": "2222222222222222222222222222222222222222"
  }
}

For the replacement-branch route, create and switch to a new local branch while leaving the original branch unchanged. It can then use ordinary git_push, which remains fast-forward-only and does not replace published history:

{
  "tool": "git_reword",
  "arguments": {
    "repository": "/absolute/path/to/repository",
    "request_id": "018f47d2-7b2a-7d75-b9dd-5ea8abca0103",
    "expected_branch": "feature/history-example",
    "expected_head": "2222222222222222222222222222222222222222",
    "base": "1111111111111111111111111111111111111111",
    "commits": [{
      "commit": "2222222222222222222222222222222222222222",
      "message": "feat(history): clarify replacement route"
    }],
    "destination": { "mode": "new_branch", "branch": "feature/history-reworded" }
  }
}

{
  "tool": "git_push",
  "arguments": {
    "repository": "/absolute/path/to/repository",
    "request_id": "018f47d2-7b2a-7d75-b9dd-5ea8abca0104",
    "expected_branch": "feature/history-reworded",
    "expected_head": "3333333333333333333333333333333333333333",
    "expected_remote_head": null
  }
}

To amend only the current commit, first create the normal stage session with git_add, retain its exact stage and snapshot IDs, and then call:

{
  "tool": "git_commit_amend",
  "arguments": {
    "repository": "/absolute/path/to/repository",
    "request_id": "018f47d2-7b2a-7d75-b9dd-5ea8abca0105",
    "expected_branch": "feature/history-example",
    "expected_head": "2222222222222222222222222222222222222222",
    "stage_id": "stage-example-20260801",
    "worktree_snapshot_id": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
    "message": "fix(history): amend the owned staged change"
  }
}

Signed source commits are rejected; signing remains disabled_by_policy. Commit messages are redacted from durable request records, although the original message remains part of the request hash used for replay. Native commit-msg, pre-commit, reference-transaction, and pre-push hooks remain enabled; hook rejection is a redacted HOOK_FAILED result. The existing git_push remains fast-forward-only for backward compatibility. These additions are unreleased: do not infer an npm release, tag, or latest availability from this source change.

Safety boundaries

Use only trusted repositories. Inputs are explicit repository-relative paths and mutations require expected branch and HEAD preconditions. Only git_switch_create accepts a null expected branch to allow branch creation from detached HEAD. git_switch_attach requires a literal null expected branch and never accepts an attached starting state. Other mutations require an attached branch name. Attach never creates a branch, resets, forces, accesses a remote, stashes dirty state, or accepts an arbitrary ref; its only mutation is native git switch --no-guess <branch>. Native hooks are enabled and may run repository-controlled code. Commits use --no-gpg-sign; the server does not bypass hooks. Review destructive restore, merge-abort, merge, and push operations before approving them.

The server is not an isolation boundary for intentionally malicious hooks running as the same operating-system user. Hook-failure redaction is a bounded result contract for trusted repositories, not a sandbox for hostile hook code.

Exact worktree snapshots fail closed when the index contains assume-unchanged or skip-worktree entries. Clear those flags before using status-derived mutation guards; Git may otherwise omit changed tracked paths from porcelain status. The bridge checks the visibility map on both sides of the status read and includes every tracked path in the content proof. Amend reconciliation captures native HEAD with the bridge-selected absolute Git executable before the repository post-commit hook, then requires that exact commit object afterward; Git's native message cleanup remains supported while post-commit metadata or message substitution fails closed. Push execution binds the prepared endpoint through a random child-only alias so ambient Git URL rewrite rules cannot retarget the approved operation after preflight. This does not change the caller-visible remote, refspec, lease, or native pre-push hook contract.

When a native pre-commit or commit-msg hook rejects a commit, git_commit returns status: "failed" with error.code: "HOOK_FAILED". The fixed error contains only error.details.hook, whose value is allowlisted to pre-commit or commit-msg. Raw hook stdout and stderr, the hook exit status, and file contents are not returned or persisted in the operation result. The commit HEAD remains unchanged and the stage session remains available for a corrected retry. If the hook changed the index before rejecting the commit, the existing index guard prevents retry until the caller restores an exact stage-session state.

State directories

The server stores locks, durable operations, sessions, and audit records in a private state root:

Platform	State root
macOS	`~/Library/Application Support/git-mcp-server`
Linux	`$XDG_STATE_HOME/git-mcp-server`, or `~/.local/state/git-mcp-server` when unset

Platform support

macOS and Linux are supported with Node.js >=22 and a POSIX-style filesystem. Windows is not supported or promised.

Development

This development preview uses the exact beta MCP SDK versions declared in package.json. Run pnpm check for the local build and test contract, and pnpm pack --dry-run --json to inspect the package payload without publishing. The beta package remains separate from the npm stable-release gates described in Status. See the provider checklist and architecture.

Security

Do not report vulnerabilities in public issues. Use GitHub Private Vulnerability Reporting as described in SECURITY.md.

Support and contributions

This project does not accept Issues, pull requests, or support requests. Please do not submit a contribution or request assistance through this source repository.

License

Distributed under the MIT License.

Available Tools

10 tools

git_addgit-mcp-server: Stage pathsA

Operation: Stage only declared literal paths in a normal stage session or owned merge session. Returns: request_id, repository_id, mode, stage_id or merge_session_id, opaque index_tree, staged paths, and unresolved paths. Defaults: omitting both IDs selects normal first-add mode; stage_id and merge_session_id are mutually exclusive. Excludes: ordinary directories, globs, pathspec magic, unrequested paths, and unowned merge paths.

ParametersJSON Schema

Name	Required	Description
`paths`	Yes	Explicit literal paths to stage; every path must satisfy the selected stage or merge session policy.
`stage_id`	No	Optional existing normal-stage session ID. Omit for the first normal add; mutually exclusive with merge_session_id.
`repository`	Yes	Absolute path to the exact target Git worktree for this mutation.
`request_id`	Yes	Client-generated UUID that makes this mutation durable and idempotent for exact replay.
`expected_head`	Yes	Exact current local HEAD object ID expected before mutation; mismatch rejects without Git mutation.
`expected_branch`	Yes	Exact current local branch name expected before mutation; mismatch rejects without Git mutation.
`merge_session_id`	No	Optional owned merge-session ID for conflict resolution. Omit for normal stage mode; mutually exclusive with stage_id.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	No
`error`	No
`status`	Yes
`warnings`	Yes
`operation`	Yes
`request_id`	No
`repository_id`	No
`observed_after`	No
`observed_before`	No

TDQS

A4.6/5.0

Behavior5/5

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

The description goes beyond annotations by detailing return values, preconditions (expected_branch/expected_head), and constraints on paths. No contradiction with annotations; readOnlyHint=false is consistent with a mutation operation.

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 a single dense paragraph with clear labeled sections (Operation, Returns, Defaults, Excludes). Every sentence adds value without redundancy.

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

Completeness4/5

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

Given the complexity and the presence of an output schema, the description covers the main aspects: operation, modes, preconditions, and exclusions. Minor missing details like definition of 'owned merge session' could be inferred.

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%, so the description adds value by explaining the interaction between stage_id and merge_session_id, and the default behavior. This nuance is not present in 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 verb 'Stage' and the resource 'literal paths' in two specific modes (normal and merge session). It also explicitly lists exclusions, distinguishing this tool from siblings like git_commit or git_merge.

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 explains the default mode when IDs are omitted and the mutual exclusivity of stage_id and merge_session_id. It also lists excluded path types. However, it does not explicitly compare with sibling tools or state when not to use this tool.

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

git_commitgit-mcp-server: Commit staged changesA

Operation: Commit the exact index owned by one stage_id with native hooks and signing disabled. Returns: request_id, repository_id, commit and tree object IDs, hook_changed_paths, and signing policy; a rejected pre-commit or commit-msg hook returns HOOK_FAILED with only its allowlisted hook kind. Defaults: all inputs are required, native hooks run, and signing stays disabled. Excludes: raw hook output or exit status, amend, arbitrary index content, implicit staging, push, and hook bypass.

ParametersJSON Schema

Name	Required	Description
`message`	Yes	Commit message passed only on standard input; it must contain 1 through 100000 characters.
`stage_id`	Yes	Owned normal-stage session ID whose exact index content will be committed.
`repository`	Yes	Absolute path to the exact target Git worktree for this mutation.
`request_id`	Yes	Client-generated UUID that makes this mutation durable and idempotent for exact replay.
`expected_head`	Yes	Exact current local HEAD object ID expected before mutation; mismatch rejects without Git mutation.
`expected_branch`	Yes	Exact current local branch name expected before mutation; mismatch rejects without Git mutation.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	No
`error`	No
`status`	Yes
`warnings`	Yes
`operation`	Yes
`request_id`	No
`repository_id`	No
`observed_after`	No
`observed_before`	No

TDQS

A5/5.0

Behavior5/5

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

Annotations indicate a write operation (readOnlyHint=false) and lack idempotency (idempotentHint=false). The description adds crucial detail: native hooks run, rejected hooks return HOOK_FAILED, the commit is durable via request_id, and the return fields include hook_changed_paths and signing policy. 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 a single, well-structured paragraph with front-loaded core purpose ('Commit'), followed by operation details, return info, defaults, and exclusions. Every sentence is informative without any 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 six required parameters and an output schema, the description covers purpose, behavioral nuances (hook interaction, return values), exclusions, and defaults. The output schema exists to define return types, so the description need not repeat them. It fully addresses the tool's complexity.

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%, and the description adds extra context for each parameter, such as 'message passed only on standard input', 'stage_id is owned normal-stage session', and 'request_id makes mutation durable and idempotent'. This goes beyond the schema's parameter 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?

The description clearly states the tool commits the exact index of a given stage_id with native hooks and signing disabled. It uses a specific verb ('Commit') and resource ('index owned by one stage_id'), and distinguishes from sibling tools like git_add (staging) and git_push (pushing).

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

Usage Guidelines5/5

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

The description explicitly lists defaults (all inputs required, native hooks run, signing disabled) and exclusions (no raw hook output, amend, implicit staging, push, hook bypass). This helps the agent understand when to use this tool versus alternatives like git_push.

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

git_fetchgit-mcp-server: Fetch remoteA

Operation: Fetch origin heads into the fixed origin-tracking namespace under a constrained policy. Returns: request_id, repository_id, fetch_id, before and after refs, sanitized remote identity, and fetch time. Defaults: origin, standard upload-pack, and no tags, prune, or submodules. Excludes: caller remote or refspec, custom helper, merge, tag updates, nested repository mutation, and retry.

ParametersJSON Schema

Name	Required	Description
`repository`	Yes	Absolute path to the exact target Git worktree for this mutation.
`request_id`	Yes	Client-generated UUID that makes this mutation durable and idempotent for exact replay.
`expected_head`	Yes	Exact current local HEAD object ID expected before mutation; mismatch rejects without Git mutation.
`expected_branch`	Yes	Exact current local branch name expected before mutation; mismatch rejects without Git mutation.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	No
`error`	No
`status`	Yes
`warnings`	Yes
`operation`	Yes
`request_id`	No
`repository_id`	No
`observed_after`	No
`observed_before`	No

TDQS

A3.6/5.0

Behavior3/5

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

The description adds value beyond annotations by listing what the tool excludes and defaults, but does not fully disclose side effects beyond the schema. Given openWorldHint=true, more detail on potential side effects (e.g., updating remote tracking branches) would improve transparency. No contradiction with annotations found.

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 exceptionally concise, using three clear bullet-like lines. It front-loads the operation purpose and efficiently communicates defaults and exclusions without wasted words.

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

Completeness4/5

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

Given the tool's complexity, the description covers the operation, return fields, defaults, and exclusions. The presence of an output schema reduces the need to describe return values. However, it could mention prerequisites (e.g., remote configured) and error conditions for fuller completeness.

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 input schema covers all parameters (100% coverage), so the baseline is 3. The description provides general operation context but does not add specific parameter-level explanations beyond what the schema already offers.

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

Purpose4/5

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

The description clearly states 'Fetch origin heads into the fixed origin-tracking namespace', specifying the verb, resource, and scope. It distinguishes from sibling tools like git_push and git_merge by focusing on fetching without merging or pushing, though it could be more explicit about when to use it over alternatives.

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 implies usage by providing defaults and exclusions, but it does not explicitly state when to use this tool versus siblings. It gives context (e.g., no tag updates, no custom refspec) that helps an agent understand constraints, but lacks clear when-to-use/when-not-to-use guidance.

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

git_mergegit-mcp-server: Merge remote refA

Destructive

Operation: Merge the exact remote_ref and object bound to one fetch_id. Returns: request_id, repository_id, head, nullable merge_session_id, and conflicted paths. Defaults: allow fast-forward or a native merge commit; conflicts create an owned session. Excludes: rebase, arbitrary local refs or unobserved object IDs, and external merge sessions.

ParametersJSON Schema

Name	Required	Description
`fetch_id`	Yes	Bridge-issued fetch session ID that binds the allowed remote-tracking observation.
`remote_ref`	Yes	Exact origin remote-tracking ref observed in fetch_id; arbitrary local refs are forbidden.
`repository`	Yes	Absolute path to the exact target Git worktree for this mutation.
`request_id`	Yes	Client-generated UUID that makes this mutation durable and idempotent for exact replay.
`expected_head`	Yes	Exact current local HEAD object ID expected before mutation; mismatch rejects without Git mutation.
`expected_branch`	Yes	Exact current local branch name expected before mutation; mismatch rejects without Git mutation.
`expected_remote_object`	Yes	Exact Git object ID that fetch_id observed at remote_ref.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	No
`error`	No
`status`	Yes
`warnings`	Yes
`operation`	Yes
`request_id`	No
`repository_id`	No
`observed_after`	No
`observed_before`	No

TDQS

A4.5/5.0

Behavior5/5

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

Beyond annotations (destructiveHint: true), the description details that conflicts create an owned session, returns nullable merge_session_id, and excludes external sessions, providing full behavioral context.

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?

Two sentences: first states operation and returns, second covers defaults and exclusions. No redundancy, front-loaded.

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 output schema exists, description covers necessary behavioral aspects and return fields. All required params are in schema.

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?

Schema coverage is 100%, so baseline is 3. Description adds little beyond schema (e.g., defaults mention fast-forward/merge commit) but does not elaborate parameter usage.

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 explicitly states the action (merge), the resource (remote_ref and object bound to fetch_id), and distinguishes from siblings by excluding rebase, arbitrary local refs, and external merge sessions.

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 defaults and conflict behavior but does not explicitly compare to sibling tools like git_merge_continue or git_push, leaving room for ambiguity in when to use this tool.

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

git_merge_abortgit-mcp-server: Abort mergeA

Destructive

Operation: Abort the exact owned merge_session_id and restore its original merge state. Returns: request_id, repository_id, and the restored head object ID. Defaults: all inputs are required and owned cleanup follows durable completion. Excludes: external merge sessions, generic reset, unrelated paths, and retry.

ParametersJSON Schema

Name	Required	Description
`repository`	Yes	Absolute path to the exact target Git worktree for this mutation.
`request_id`	Yes	Client-generated UUID that makes this mutation durable and idempotent for exact replay.
`expected_head`	Yes	Exact current local HEAD object ID expected before mutation; mismatch rejects without Git mutation.
`expected_branch`	Yes	Exact current local branch name expected before mutation; mismatch rejects without Git mutation.
`merge_session_id`	Yes	Owned conflicted merge-session ID to abort; external merge state is rejected.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	No
`error`	No
`status`	Yes
`warnings`	Yes
`operation`	Yes
`request_id`	No
`repository_id`	No
`observed_after`	No
`observed_before`	No

TDQS

A4.1/5.0

Behavior4/5

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

Annotations indicate destructiveHint: true, and the description confirms the destructive nature by stating it aborts a merge and restores state. It adds specific context about requiring an 'owned' merge session and durable cleanup, which goes beyond the annotation hints.

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

Conciseness4/5

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

The description is two sentences long and conveys key information efficiently. It is front-loaded with the main action, though the phrasing 'exact owned merge_session_id' is somewhat dense. No superfluous content.

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

Completeness4/5

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

Given the five required parameters and the presence of an output schema, the description adequately covers the tool's behavior, including return fields (request_id, repository_id, restored head). It provides enough context for an agent to understand the tool's purpose and constraints.

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?

All 5 parameters have schema descriptions, achieving 100% coverage. The description does not add significant new meaning beyond the schema, only reiterating that inputs are required. This meets the baseline for schema-rich tools.

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 verb 'Abort' and the resource 'merge_session_id', specifying that it restores the original merge state. This distinguishes it from siblings like git_merge_continue and git_merge, which serve different purposes.

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 excludes 'external merge sessions, generic reset, unrelated paths, and retry', providing some guidance on when not to use. However, it does not explicitly contrast with alternatives like git_merge_continue or git_restore_worktree, leaving room for clearer usage context.

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

git_merge_continuegit-mcp-server: Continue mergeA

Destructive

Operation: Continue the exact owned merge_session_id after all conflicts are resolved. Returns: request_id, repository_id, and resulting head and commit object IDs. Defaults: all inputs are required, native hooks run, and signing stays disabled. Excludes: external merge sessions, unresolved conflicts, arbitrary commits or refs, and retry.

ParametersJSON Schema

Name	Required	Description
`repository`	Yes	Absolute path to the exact target Git worktree for this mutation.
`request_id`	Yes	Client-generated UUID that makes this mutation durable and idempotent for exact replay.
`expected_head`	Yes	Exact current local HEAD object ID expected before mutation; mismatch rejects without Git mutation.
`expected_branch`	Yes	Exact current local branch name expected before mutation; mismatch rejects without Git mutation.
`merge_session_id`	Yes	Owned conflicted merge-session ID to continue after all unresolved paths are staged.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	No
`error`	No
`status`	Yes
`warnings`	Yes
`operation`	Yes
`request_id`	No
`repository_id`	No
`observed_after`	No
`observed_before`	No

TDQS

A4.2/5.0

Behavior4/5

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

Annotations indicate destructiveHint=true, readOnlyHint=false. The description adds details about defaults (all inputs required, native hooks run, signing disabled) and return values, providing context 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?

Three sentences: action, returns, defaults, exclusions. No wasted words, front-loaded core purpose.

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

Completeness4/5

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

Given 5 required params, destructive nature, and presence of output schema, the description covers purpose, usage, behavior, and exclusions adequately. Could add more on safety guarantees but sufficient.

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?

Schema coverage is 100% with descriptions. The description adds minimal extra meaning ('owned', 'after all unresolved paths are staged') but mostly reiterates schema info.

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 verb 'Continue' and the resource 'owned merge_session_id' with the condition 'after all conflicts are resolved'. It distinguishes from siblings like git_merge and git_merge_abort.

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 'Excludes' line explicitly lists scenarios where the tool should not be used (external sessions, unresolved conflicts). It implies usage after conflict resolution, though alternatives are not named directly.

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

git_operation_getgit-mcp-server: Get operationA

Read-onlyIdempotent

Operation: Read the result stored for request_id. Returns: the stored terminal result, including original status, data, request_id, and repository_id when present. Defaults: lookup only; no repository input is required. Excludes: Git execution, repository mutation, repository lock acquisition, retry, and result reconstruction.

ParametersJSON Schema

Name	Required	Description	Default
`request_id`	Yes	UUID of a previously durable Git mutation whose exact terminal result should be returned.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	No
`error`	No
`status`	Yes
`warnings`	Yes
`operation`	Yes
`request_id`	No
`repository_id`	No
`observed_after`	No
`observed_before`	No

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds details: 'no repository input required', 'lookup only', and lists exclusions, providing behavioral context beyond 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?

Three sentences: purpose+returns, defaults, exclusions. Front-loaded with key action. No unnecessary words. Efficient structure.

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

Completeness4/5

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

Output schema exists, so return values are covered. Description specifies what is returned, defaults, and exclusions. Adequate for a simple read-only tool, though could mention when to use in relation to sibling tools (implied but not explicit).

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?

Schema coverage is 100% and schema description of request_id is detailed. Description adds 'Read the result stored for request_id' but essentially restates schema's purpose. No new semantic meaning beyond what schema provides.

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 'Read the result stored for request_id' - specific verb 'Read' and resource 'result'. Distinguishes from sibling git mutation tools which perform actions; this only reads stored results.

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?

States 'Defaults: lookup only; no repository input required' and lists exclusions like 'Git execution, repository mutation'. Provides context for when to use (retrieve result) and when not to (perform git operations), though could be more explicit about use case for checking previous mutations.

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

git_pushgit-mcp-server: Push branchA

Operation: Push current branch HEAD to the same branch on origin using expected-remote CAS and ancestry proof. Returns: request_id, repository_id, local_head, and remote_head object IDs. Defaults: origin and current branch are fixed, an internal exact lease is used, and null expectation means absence. Excludes: non-fast-forward updates, caller force or refspec, tags, delete, and automatic retry.

ParametersJSON Schema

Name	Required	Description
`repository`	Yes	Absolute path to the exact target Git worktree for this mutation.
`request_id`	Yes	Client-generated UUID that makes this mutation durable and idempotent for exact replay.
`expected_head`	Yes	Exact current local HEAD object ID expected before mutation; mismatch rejects without Git mutation.
`expected_branch`	Yes	Exact current local branch name expected before mutation; mismatch rejects without Git mutation.
`expected_remote_head`	Yes	Exact expected origin branch head for atomic lease comparison, or null only when the branch is expected absent.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	No
`error`	No
`status`	Yes
`warnings`	Yes
`operation`	Yes
`request_id`	No
`repository_id`	No
`observed_after`	No
`observed_before`	No

TDQS

A4.3/5.0

Behavior5/5

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

Beyond annotations, the description discloses exclusions (non-fast-forward, force, tags, delete, retry), defaults (fixed origin/branch, internal lease), and behavior for null expectations, providing substantial context.

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?

Three succinct sentences covering operation, returns, and constraints. However, technical jargon ('CAS', 'ancestry proof') may reduce clarity for some agents.

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

Completeness4/5

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

Covers operation, return values, and constraints. Missing explanation of 'internal exact lease' but paired with high schema coverage and output schema, it is largely complete.

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?

Schema coverage is 100% with good descriptions; the description adds only minor context (fixed origin/branch) but does not enhance parameter meaning 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 verb 'Push' and the resource 'current branch HEAD to the same branch on origin', distinguishing it from sibling tools like git_fetch 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 implicitly defines when to use this tool (for pushing), but does not explicitly exclude alternatives or provide when-not-to-use guidance, though sibling context helps.

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

git_restore_worktreegit-mcp-server: Restore worktree pathsA

Destructive

Operation: Restore declared tracked worktree paths from the current index after validating the supplied snapshot guard. Returns: request_id, repository_id, restored paths, and a new worktree_snapshot_id. Defaults: all inputs are required and the current index is the only content source. Excludes: index mutation, untracked paths or deletion, directories, globs, and unrequested paths.

ParametersJSON Schema

Name	Required	Description
`paths`	Yes	Explicit tracked worktree paths to restore from the current index after the snapshot guard is validated.
`repository`	Yes	Absolute path to the exact target Git worktree for this mutation.
`request_id`	Yes	Client-generated UUID that makes this mutation durable and idempotent for exact replay.
`expected_head`	Yes	Exact current local HEAD object ID expected before mutation; mismatch rejects without Git mutation.
`expected_branch`	Yes	Exact current local branch name expected before mutation; mismatch rejects without Git mutation.
`worktree_snapshot_id`	Yes	Exact complete worktree snapshot guard previously returned by git_status.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	No
`error`	No
`status`	Yes
`warnings`	Yes
`operation`	Yes
`request_id`	No
`repository_id`	No
`observed_after`	No
`observed_before`	No

TDQS

A4.6/5.0

Behavior5/5

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

Annotations indicate destructiveHint=true, and the description goes beyond by detailing what is restored (tracked worktree paths), what is validated (snapshot guard), what is excluded (index mutation, untracked paths, deletion, etc.), and what is returned. No contradiction 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, using only three short sentences structured as Operation, Returns, Defaults, and Excludes. Every sentence adds essential information with no redundancy.

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

Completeness4/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 required parameters, destructive, snapshot guard requirement), the description covers purpose, return fields, defaults, and exclusions. With an output schema available, it is nearly complete, though it could briefly mention typical usage scenarios (e.g., after a conflict resolution) for full clarity.

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?

All 6 parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds value by stating 'all inputs are required' and 'the current index is the only content source,' providing operational 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 the tool restores 'declared tracked worktree paths from the current index' after validating a snapshot guard, using specific verbs and resources. It distinguishes from siblings by focusing on worktree restoration, unlike git_add, git_commit, or git_merge.

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 clear context: the operation requires a validated snapshot guard and only works on tracked paths from the index. It lists exclusions (index mutation, untracked paths, etc.) to help decide when not to use, but does not explicitly name alternatives or when to prefer this over siblings.

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

git_switch_creategit-mcp-server: Create branchA

Operation: Create and switch to one new branch from the exact expected_branch and exact expected HEAD. Returns: request_id, repository_id, the created branch, and unchanged head; no session identifier. Defaults: a string expected_branch requires that attached branch, while null requires detached HEAD. Excludes: existing branch checkout, force or reset, branch or HEAD mismatch, dirty or untracked state, and remote access.

ParametersJSON Schema

Name	Required	Description
`branch`	Yes	New local branch name to create from the exact expected HEAD; existing or invalid refs are rejected.
`repository`	Yes	Absolute path to the exact target Git worktree for this mutation.
`request_id`	Yes	Client-generated UUID that makes this mutation durable and idempotent for exact replay.
`expected_head`	Yes	Exact current local HEAD object ID expected before mutation; mismatch rejects without Git mutation.
`expected_branch`	Yes	Exact current local branch expected before branch creation, or null to require detached HEAD; mismatch rejects without Git mutation.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	No
`error`	No
`status`	Yes
`warnings`	Yes
`operation`	Yes
`request_id`	No
`repository_id`	No
`observed_after`	No
`observed_before`	No

TDQS

A4.5/5.0

Behavior4/5

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

With all annotations set to false, the description adds significant behavioral context: returns, default behavior (string vs null for expected_branch), and conditions for rejection (mismatch, dirty state). It does not claim idempotency, consistent with annotations. The description reveals the mutation's preconditions and side effects.

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 a single dense paragraph with clear sections (Operation, Returns, Defaults, Excludes). Every sentence carries essential information, with no repetition or filler.

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 (5 required params, output schema present), the description covers operation, return values, default behavior, and failure conditions. The output schema handles return details, so the description is complete for agent decision-making.

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 value by explaining the default behavior for expected_branch ('string requires attached branch, null requires detached HEAD') and clarifying the branch parameter's purpose 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 verb ('Create and switch') and resource ('one new branch') with precise conditions ('from the exact expected_branch and exact expected HEAD'). It distinguishes from sibling tools by specifying that it only creates a new branch from a specific state, excluding checkout, merge, etc.

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 lists what is excluded (existing branch checkout, force/reset, mismatch, dirty state, remote access), providing clear when-not-to-use guidance. However, it does not explicitly name alternatives like git_commit or git_merge, though the exclusions implicitly differentiate.

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

A4.3/5.0

Disambiguation5/5

Each tool targets a distinct Git operation (branch creation, staging, fetch, commit, merge, push, result retrieval) with no overlap. The merge-related tools (merge, continue, abort) are clearly differentiated by their stage in the merge lifecycle.

Naming Consistency5/5

All tool names follow a consistent 'git_' prefix + snake_case verb_noun pattern (e.g., git_switch_create, git_restore_worktree, git_merge_continue). The naming is predictable and easy to parse.

Tool Count5/5

With 10 tools, the set is well-scoped for a focused Git workflow (branch, stage, commit, fetch, merge, push). It avoids bloat while covering essential operations, and each tool serves a clear purpose.

Completeness4/5

The tool surface covers core development operations (add, commit, push, fetch, merge, branch creation) but lacks common operations like log, diff, or stash. While the set is coherent for a linear workflow, minor gaps reduce coverage.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

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
Git Diff Mcp
io.github.varvararatta
MCP server for git_diff_mcp
Version Control Developer Tools
2
Arlet
dev.arlet
Create, deploy, and operate MCP servers directly from your GitHub repositories.
Developer Tools CI/CD & DevOps
2
siGit
si.sigit
MCP server for siGit (sigit.si): browse repos, search code, manage PRs/issues, web search.
Version Control Developer Tools
221

Related MCP Servers

Git MCP
Version Control Developer Tools Code Execution
kjozsa
F
license
A
quality
D
maintenance
MCP server for managing Git operations on local repositories, allowing users to list repositories, get and create tags, list commits, push tags, and refresh repositories through a standardized interface.
Updated a year ago (2025-03-05 10:13 UTC)
6
3
git-mcp-server
File Systems Shell Access Version Control
sndworldgh
A
license
Not graded
quality
C
maintenance
A secure, git-aware MCP server for working with local repositories, enabling file management, shell commands, and full git operations within allowed directories.
Updated 2 months ago (2026-07-10 09:38 UTC)
607
1
GPL 3.0
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
git-context-mcp
Version Control Developer Tools
CarloMeazza
F
license
Not graded
quality
D
maintenance
A secure MCP server for local Git operations with path traversal protection, input validation, and 15 supported Git commands.
Updated 7 months ago (2026-02-14 07:51 UTC)
607

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/saitolume/git-mcp-server'

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