Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
GITBASH_BASHNoPoints 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_RISKYNoThe 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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.1/5.0

Scored across 4 tools

Disambiguation4/5

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.

Naming Consistency3/5

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.

Tool Count4/5

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.

Completeness4/5

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

Maintenance

ActivityMaintained
ResponsivenessNo issues