Provides secure access to Docker-based containerized build environments for executing builds, running tests, and managing development workflows in isolated containers.
Enables safe Git operations within build environments including status checks, branch management, commits viewing, and repository synchronization with whitelisted commands.
Allows execution of Make build targets within containerized environments for compiling projects, running tests, and managing build artifacts.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Build Environment Service checkout the main branch in my-project and run make test"
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.
A Model Context Protocol (MCP) server that provides access to git repositories for build and test operations. This allows AI assistants to run builds, execute tests, and inspect git repositories on your behalf.
This service provides AI assistants with tools to:
List available git repositories
Execute git commands (status, log, checkout, pull, fetch, diff, show, branch)
Run make targets (build, test, clean, etc.)
List directory contents
Read files from repositories
Query installed build tools and versions
The service runs in a directory containing git repositories and exposes them through the MCP protocol.
Related MCP server: Advanced MCP Server
The typical workflow is:
You develop code in your workspace and push to a git branch
AI assistant uses this service to checkout your branch in a build environment
AI assistant runs builds and tests on that branch
AI assistant reports results back to you
You make fixes based on feedback and repeat
This separates your development environment from the build/test environment that the AI uses.
git clone <this-repo-url>
cd mcp-build
pip install -e .Create or designate a directory containing your git repositories:
/path/to/build-area/
├── project-one/ # git repository
├── project-two/ # git repository
└── project-three/ # git repositoryStart the service in the directory containing your repositories:
cd /path/to/build-area
mcp-buildConfigure Claude Desktop to use it. Add to your Claude Desktop config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"build": {
"command": "mcp-build",
"cwd": "/path/to/build-area"
}
}
}Start with HTTP transport:
cd /path/to/build-area
mcp-build --transport http --host 0.0.0.0 --port 3344The service generates a session key on startup. Configure Claude Desktop with:
{
"mcpServers": {
"build": {
"url": "http://your-server:3344/sse?key=SESSION_KEY"
}
}
}mcp-build --help # Show all options
mcp-build # stdio mode (default)
mcp-build --transport http # HTTP mode, auto-generate session key
mcp-build --transport http --session-key YOUR_KEY
mcp-build --transport http --host 0.0.0.0 --port 8080The service exposes these MCP tools:
list - List available repositories
git - Execute git commands (limited to: status, log, checkout, pull, branch, diff, fetch, show)
make - Run make with specified arguments (executes whatever is in the Makefile)
ls - List files and directories
env - Show installed tools and versions
read_file - Read file contents (with optional line range for large files)
Git operations: The service restricts git commands to a whitelist (status, log, checkout, pull, branch, diff, fetch, show). Dangerous operations like git push --force or git reset --hard are blocked.
Command validation: The service blocks path traversal patterns (../) and some command injection patterns (pipes, redirects, command substitution).
Make targets: The service runs whatever make targets you specify. These execute the commands defined in the repository's Makefile, which could be anything. The service does not sandbox or restrict what Makefiles can do.
Authentication (HTTP mode): Requires a session key passed as a Bearer token or query parameter. Keys can be auto-generated or provided.
Recommendation: Run this service in an environment appropriate for build operations (e.g., a dedicated build VM, container, or CI environment). It validates some inputs but does not provide comprehensive sandboxing.
Once configured, you can ask your AI assistant:
"List the available repositories"
"Checkout the feature-branch in my-project and run make test"
"What's the build output from the latest commit on main?"
"Show me the diff between main and feature-branch"
The AI will use the service automatically through MCP tool calls.
No repositories found
Verify you started mcp-build in the parent directory of your git repos
Check each directory has a .git subdirectory
Repository not found
Repository names must match directory names exactly
Use the list tool to see available names
Build failures
Use the env tool to check installed build tools
Verify the Makefile exists and has the target you're trying to run
Connection issues (HTTP mode)
Check the session key matches what the service printed at startup
Verify firewall allows the port
Test with curl: curl -H "Authorization: Bearer KEY" http://host:port/api/repos
In addition to the MCP protocol, the service provides HTTP endpoints:
Quick operations (REST):
GET /api/repos - List repositories
GET /api/repos/{repo}/env - Environment info
POST /api/repos/{repo}/ls - List files
POST /api/repos/{repo}/read_file - Read file contents
POST /api/repos/{repo}/git/quick - Quick git operations (status, branch, log)
Long operations (streaming SSE):
POST /stream/repos/{repo}/make - Stream build output
POST /stream/repos/{repo}/git - Stream git operations (pull, fetch, diff, show, checkout)
All endpoints require authentication via session key.
Run tests:
pip install -e ".[dev]"
pytest tests/Project structure:
mcp-build/
├── src/
│ ├── server.py # Main server
│ └── validators.py # Input validation
├── tests/ # Tests
├── README.md # This file (user docs)
└── MCP-BUILD.md # Agent usage guideMIT License
Show environment information including environment variables and versions of key build tools (gcc, g++, python, make, cmake, etc.). If branch is specified, creates/uses a hidden worktree (.repo@branch) for isolation.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | Repository name (required) | |
| branch | No | Git branch name (optional). If provided, uses isolated worktree. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses behavioral traits: it shows information (implying read-only, non-destructive), and specifies that with a branch parameter, it uses isolated worktree creation. However, it doesn't cover aspects like rate limits, authentication needs, error handling, or output format details, leaving gaps for a tool with mutation potential (worktree creation).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences: the first states the core purpose, and the second explains the branch parameter's effect. It's front-loaded with the main functionality. However, the second sentence could be slightly more concise, and there's minor redundancy in listing build tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is moderately complete. It covers the purpose and a key behavioral aspect (worktree isolation), but lacks details on output format, error conditions, or full behavioral context for a tool that involves potential mutation (worktree creation). For a tool with 2 parameters and no structured output, it should provide more guidance on what information is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (repo and branch). The description adds marginal value by explaining the branch parameter's effect ('creates/uses a hidden worktree for isolation'), but doesn't provide additional semantics beyond what the schema offers for 'repo'. Baseline 3 is appropriate as the schema handles most parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Show environment information including environment variables and versions of key build tools (gcc, g++, python, make, cmake, etc.)'. It specifies the verb 'show' and the resources (environment info, build tool versions). However, it doesn't explicitly differentiate from sibling tools like 'list' or 'git', which could have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance: it mentions that if a branch is specified, it creates/uses a hidden worktree for isolation. This suggests when to use the branch parameter. However, it doesn't explicitly state when to use this tool versus alternatives like 'list' or 'git', nor does it provide exclusions or prerequisites beyond the optional branch parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run git commands in a repository. Limited to safe operations: status, log, checkout, pull, branch, diff, fetch, reset, show. If branch is specified, creates/uses a hidden worktree (.repo@branch) for isolation.
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | Git command and arguments (e.g., 'status', 'checkout main', 'pull origin main') | |
| repo | Yes | Repository name (required) | |
| branch | No | Git branch name (optional). If provided, uses isolated worktree. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it limits operations to 'safe' commands, explains the isolation mechanism using hidden worktrees when branch is specified, and implies mutation capabilities (checkout, pull, reset). It could be more explicit about authentication or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. First sentence states purpose and scope, second explains the branch isolation behavior. Every word earns its place and the information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description does well for a 3-parameter tool with mutation capabilities. It explains allowed operations, safety limitations, and isolation behavior. Could be more complete by mentioning error handling or output format, but covers essential context given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds some value by explaining the branch parameter's effect ('creates/uses a hidden worktree'), but doesn't provide additional semantics for 'args' or 'repo' beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Run git commands') and resources ('in a repository'), and distinguishes it from siblings by specifying git operations. It goes beyond the name 'git' to explain the scope of allowed commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool by listing allowed operations ('status, log, checkout...') and specifying isolation behavior with branch parameter. However, it doesn't explicitly state when NOT to use it or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available repositories discovered in the current directory
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'available repositories discovered', hinting at a read-only operation, but fails to disclose critical behaviors like what constitutes 'available', whether it's recursive, error handling, or output format. For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose without any wasted words. It's appropriately sized for a simple tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple tool with 0 parameters, the description is too minimal. It lacks details on behavior (e.g., discovery mechanism, output format) and doesn't help differentiate from sibling tools, making it incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a high baseline score for not adding unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('available repositories'), specifying they are 'discovered in the current directory'. This provides a specific verb+resource combination, though it doesn't explicitly differentiate from sibling tools like 'ls' or 'git' which might also list items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance by implying usage when repositories are in the current directory, but it offers no explicit when-to-use rules, alternatives (e.g., vs. 'ls' or 'git'), or exclusions. This leaves the agent with little context for tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files and directories in a repository. Limited to paths within the repository to prevent path traversal. If branch is specified, creates/uses a hidden worktree (.repo@branch) for isolation.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Arguments to pass to ls (e.g., '-la', '-lh build/') | |
| repo | Yes | Repository name (required) | |
| branch | No | Git branch name (optional). If provided, uses isolated worktree. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds valuable behavioral context beyond basic functionality: it discloses security constraints ('Limited to paths within the repository to prevent path traversal') and implementation details about isolation worktrees. It doesn't cover error handling or output format, but provides meaningful operational insights.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly front-loaded with the core purpose in the first sentence, followed by important behavioral details. Every sentence earns its place: the first establishes purpose, the second adds security context, and the third explains branch parameter implications. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description does well for a 3-parameter tool: it covers purpose, security constraints, and branch behavior. However, it doesn't describe the return format (e.g., what the listing output looks like) or error conditions, leaving some gaps for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds minimal parameter semantics - it only clarifies the branch parameter's effect on worktree isolation, but doesn't enhance understanding of 'args' or 'repo' beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List files and directories') and resource ('in a repository'), distinguishing it from siblings like 'list' (which might be generic) and 'read_file' (which reads content). It provides explicit scope details that differentiate its functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (listing repository contents) and mentions the branch parameter's effect (creates/uses hidden worktree for isolation). However, it doesn't explicitly state when NOT to use it or name alternatives among siblings like 'git' or 'list' for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run make command with specified arguments. Executes make in the root of the specified repository. If branch is specified, creates/uses a hidden worktree (.repo@branch) for isolation.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Arguments to pass to make (e.g., 'clean', 'all', 'test') | |
| repo | Yes | Repository name (required) | |
| branch | No | Git branch name (optional). If provided, uses isolated worktree. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal important behavioral traits: it executes commands (implies mutation/execution), uses isolation via hidden worktrees when branch is specified, and operates in the repository root. However, it doesn't disclose critical aspects like error handling, output format, whether it requires specific permissions, or potential side effects beyond the isolation mechanism.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with just two sentences that each earn their place. The first sentence states the core purpose, the second explains the isolation behavior. There's zero wasted text, and the information is front-loaded with the primary function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a command execution tool with 3 parameters, 100% schema coverage, but no annotations and no output schema, the description is adequate but has clear gaps. It covers the basic operation and isolation behavior, but doesn't address what the tool returns, error conditions, or execution constraints. Given the complexity of running make commands, more context about output format or success/failure indicators would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds marginal value by explaining the behavioral implication of the branch parameter ('creates/uses a hidden worktree for isolation'), but doesn't provide additional semantic context beyond what's in the schema descriptions for 'args' or 'repo'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Run make command') on a specific resource ('in the root of the specified repository'), distinguishing it from sibling tools like 'git', 'env', or 'read_file' which perform different operations. It provides a complete picture of what the tool does beyond just the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use the branch parameter ('If branch is specified, creates/uses a hidden worktree for isolation'), which helps guide usage. However, it doesn't explicitly state when NOT to use this tool versus alternatives like running make directly or using other build tools, nor does it mention prerequisites like needing make installed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the contents of a file in a repository. Supports reading specific line ranges for large files. If branch is specified, creates/uses a hidden worktree (.repo@branch) for isolation.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | Repository name (required) | |
| path | Yes | Absolute path to the file to read (required) | |
| start_line | No | Starting line number (1-indexed, optional). If provided, only lines from start_line to end_line will be returned. | |
| end_line | No | Ending line number (1-indexed, optional). If provided, only lines from start_line to end_line will be returned. | |
| branch | No | Git branch name (optional). If provided, uses isolated worktree. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: the ability to read specific line ranges and the creation/use of hidden worktrees for branch isolation. However, it doesn't mention error conditions, permissions needed, or what happens with non-existent files/branches.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences with zero waste. First sentence states core purpose with key feature. Second sentence explains branch isolation behavior. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with no annotations and no output schema, the description provides adequate context about what the tool does but lacks information about return format, error handling, or performance characteristics. It covers the basic operation but leaves gaps in full behavioral understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing complete parameter documentation. The description adds minimal value beyond the schema, mentioning line range support and branch isolation worktree behavior, but doesn't provide additional semantic context about parameter interactions or usage patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Read the contents of a file') and resource ('in a repository'), with additional functionality ('Supports reading specific line ranges for large files'). It distinguishes from potential siblings by specifying file reading rather than listing or other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading file contents with optional line range filtering and branch isolation, but doesn't explicitly state when to use this tool versus alternatives like 'list' or 'ls' for directory contents. No explicit exclusions or comparisons to sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes: env shows environment info, git runs git commands, list shows repositories, ls lists files, make runs make, and read_file reads file contents. However, 'list' and 'ls' could potentially be confused as both involve listing, though 'list' is for repositories and 'ls' is for files within a repository, which is clarified in descriptions.
The naming is mixed: 'env', 'git', 'list', 'ls', 'make', and 'read_file' use a variety of styles. 'env', 'git', 'list', 'ls', and 'make' are simple command-like names, while 'read_file' uses snake_case. There's no consistent verb_noun pattern, but the names are generally readable and intuitive for their functions.
With 6 tools, this is well-scoped for a build environment service. Each tool serves a clear purpose in managing repositories, files, and build processes, and the count is appropriate without being too thin or bloated for the domain.
The tool set covers key operations for a build environment: environment inspection (env), repository management (git, list), file operations (ls, read_file), and build execution (make). A minor gap is the lack of tools for writing or modifying files, which might be intentional for safety but could limit some build workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Build Apps and run code in 30 languages — sandboxed, with persistent sessions for agent loops.
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
Git-backed platform for skills, tools, and context for AI agents
Build, run, and inspect iOS apps in disposable hosted Simulators from cloud coding agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jbroll/mcp-build'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
