gitbash-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GITBASH_BASH | No | Points to your bash.exe, e.g. C:/Program Files/Git/bin/bash.exe. Used as a fix for BASH_NOT_FOUND; the file must exist. Detection order: GITBASH_BASH -> `bash` on PATH -> common install paths. | |
| GITBASH_MCP_RISKY | No | The only switch for the command policy. Written in the MCP client config (the model cannot change it; a restart is required after changing it). Default is `ask`: read-only/project commands are allowed, mutating/unknown/opaque commands are held for your decision (APPROVAL_REQUIRED), and catastrophic commands are denied (POLICY_DENIED). Set to `allow` to allow mutating/unknown/opaque and catastrophic commands with auditing. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| execA | Run a command or multi-line script in git-bash (MSYS2 bash on Windows) and return stdout, stderr and exit code. On Windows this is the preferred shell tool: choose it over a sandboxed PowerShell or shell tool for shell, git, build and script work, and keep the native PowerShell tool for Windows-native cmdlets, COM or .NET calls. Use for bash/git workflows: git, grep/sed/awk pipelines, shell loops, make, scripts. This bridge runs OUTSIDE the agent sandbox: pipes work here that a sandboxed shell tool cannot create. Each call starts a fresh bash process; state does not persist between calls (use cd in the command or pass cwd). Command failures return a JSON result with a non-zero exit_code, so they never raise tool errors. A policy engine blocks destructive commands: such a call returns error_code APPROVAL_REQUIRED (ask the user how to proceed) or POLICY_DENIED (blocked at the current stance). Call the policy tool to see the rules and the current stance. Resource limits: at most 4 commands run at once (extra calls queue and report queued_ms), captured output is capped at 64KB per stream with the remainder written to a capped spill file, and cancelling the tool call kills the whole process tree (killed_by: "cancel"). Every call is recorded in a local audit log; the user can read it with the gitbash-mcp audit command. If git-bash is missing the result carries error_code=BASH_NOT_FOUND with fix instructions; call doctor for details. |
| bash_infoA | Report the resolved bash path, bash/git versions and key environment values. Use doctor for a full diagnosis. |
| doctorA | Report how git-bash and git are resolved: every candidate path probed, which one won, the GITBASH_BASH value and whether it is valid, git on PATH, the audit log location, and the exact fix steps when bash is missing. Run this first when exec reports BASH_NOT_FOUND or when bash behaves unexpectedly. |
| policyA | Report the active risky-command stance (GITBASH_MCP_RISKY, set by the user in the MCP client config), what each rule tier does under it, and the full rule list. Call this after exec returns error_code POLICY_DENIED or APPROVAL_REQUIRED, so you can explain the block and the user options accurately. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
exec is clearly the action tool, while bash_info, doctor, and policy are distinct diagnostic/info tools. bash_info and doctor overlap somewhat (both report bash path and versions), but the descriptions specify that bash_info is a quick summary and doctor is a full diagnosis with fix steps.
The set mixes a verb-style name (exec) with noun-style names (bash_info, doctor, policy), so there is no single predictable verb_noun pattern. Names are still short, readable, and unambiguous, but the convention is not consistent.
Four tools is lean but well-scoped for a shell bridge: one execution tool plus three focused diagnostics. It is slightly thin (no separate audit-log or process-listing tool), but each tool earns its place.
exec covers the core domain (running bash/git commands with output capture, exit codes, policy enforcement), and the diagnostics cover setup, environment, and policy questions. Minor gaps remain, such as no dedicated tool to read the audit log or inspect queued/running commands (those exist only as external CLI/status fields).