Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
MCP_MODENoread / write / test / shipread
AUDIT_LOGNoAudit log path./audit.log
REPO_ROOTNoRepository root.
POLICY_RULESNoPolicy rules file./config/policy.yaml
SANDBOX_CPUSNoDocker sandbox CPUs2
SESSIONS_FILENoSession storage path./sessions.json
MAX_FILE_BYTESNoMax file read size (bytes)200000
SANDBOX_MEMORYNoDocker sandbox memory2g
MAX_PATCH_BYTESNoMax patch size (bytes)200000
SANDBOX_TMPFS_MBNoSandbox tmpfs size (MB)512
TEST_TIMEOUT_MAXNoMax test timeout (seconds)300
ALLOW_DIRTY_WORKTREENoAllow patch on dirty worktreefalse

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": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
repo_list_filesD
repo_read_fileD
repo_search_codeD
repo_git_statusD
repo_git_diffD
repo_apply_patchA

Atomically apply one validated unified text patch.

One patch may contain multiple repository text-file targets. All targets are validated before mutation and Git applies the patch as one locked operation, so a target failure does not leave a partial multi-file edit.

repo_git_commitA

Create one local Git commit for allowlisted pending changes.

Disabled unless ALLOW_GIT_COMMIT is enabled (GUI: allow Git commit). Requires write or test mode. Does not push, amend, reset, rebase, checkout, or skip hooks. Sensitive paths are never staged.

repo_run_testA

Run one or more allowlisted repository verification commands.

The allowlist covers test/build/lint/check profiles for common Python, Go, Node, Maven, and Gradle repositories. command_key preserves the original single-command API. command_keys runs a bounded sequential batch; the complete batch is validated before the first command starts.

Every started command returns command, exit_code, stdout, stderr, duration and truncation metadata. Timeout/output-limit termination is a structured failed result so captured evidence is not discarded.

Commands may emit MCP_IMAGE:<repository-relative-path> lines for PNG/JPEG files under the configured test artifact directory; screenshots are returned as native MCP image content.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

C2.7/5.0

Scored across 8 tools

Disambiguation5/5

Each tool targets a distinct operation: listing files, reading files, searching code, checking git status, viewing diffs, applying patches, committing, and running tests. No two tools have overlapping purposes, making selection unambiguous.

Naming Consistency5/5

All tools follow a consistent `repo_` prefix with verb_noun snake_case naming (e.g., list_files, read_file, git_status, run_test). The pattern is uniform and predictable across the entire set.

Tool Count5/5

Eight tools is well-scoped for a local repository MCP server, covering file exploration, git inspection, patch application, committing, and testing without excess. Each tool serves a clear purpose.

Completeness4/5

The surface covers the core workflow: explore files, inspect git state, modify via patch, commit, and run verification commands. Minor gaps exist such as git log/history and branch management, but the primary workflow is complete and patch-based editing covers file modifications.

Maintenance

ActivityMaintained
ResponsivenessNo issues