# gh-aw-mcpg — MCP Gateway for Sandboxed Agents

> gh-aw-mcpg is a Docker-first MCP gateway that exposes backend MCP servers over HTTP so sandboxed agents call tools through one controlled entrypoint.

## Install

Merge the JSON below into your `.mcp.json`:

## Quick Use

1. Install / set up:
   ```bash
   docker pull ghcr.io/github/gh-aw-mcpg:latest
   ```
2. Start / smoke test:
   ```bash
   docker run --rm -i -e MCP_GATEWAY_PORT=8000 -e MCP_GATEWAY_DOMAIN=localhost -e MCP_GATEWAY_API_KEY=your-secret-key -v /var/run/docker.sock:/var/run/docker.sock -p 8000:8000 ghcr.io/github/gh-aw-mcpg:latest < config.json
   ```
3. Verify:
   - Open `http://127.0.0.1:8000/health` and confirm the gateway reports a healthy status JSON.

## Intro

gh-aw-mcpg is a Docker-first MCP gateway that exposes backend MCP servers over HTTP so sandboxed agents call tools through one controlled entrypoint.

- **Best for:** teams running agents in containers who need a single, auditable MCP entrypoint with guardrails
- **Works with:** Docker, HTTP-based MCP clients, containerized stdio MCP servers
- **Setup time:** 20 minutes

## Practical Notes

- One HTTP endpoint can route to multiple MCP backends (config-driven)
- Default quick start uses port 8000 and mounts `/var/run/docker.sock` to spawn backend servers
- GitHub stars/forks (verified): see Source & Thanks

A gateway matters when your agent environment is constrained:

- Your agent runs in a sandbox/container and shouldn't have direct network access to every tool.
- You want one place to apply policy (what repos can be read, what data can be written), logging, and health checks.

Operationally, treat the gateway as “MCP ingress”:

1. Put *all* tool access behind it (even if some tools are stdio-in-container).
2. Keep the configuration file in version control so changes are reviewable.
3. Rotate API keys and restrict backend credentials (e.g., GitHub tokens) the same way you would for CI.

If you're already using GitHub Agentic Workflows, this repo is designed as the MCP access layer for sandboxed runs.

### FAQ

**Q: What does it do?**
A: It proxies/routs MCP requests over HTTP to multiple configured backend MCP servers.

**Q: Why is Docker required in quick start?**
A: The gateway can spawn containerized stdio servers, so it mounts Docker socket to run them.

**Q: How do I secure it?**
A: Use API keys, restrict backend tokens, and keep guard/policy configuration under review.

## Source & Thanks

> Source: https://github.com/github/gh-aw-mcpg
> License: MIT
> GitHub stars: 126 · forks: 22

---

<!-- ZH -->

## 快速使用

1. 安装 / 设置：
   ```bash
   docker pull ghcr.io/github/gh-aw-mcpg:latest
   ```
2. 启动 / 冒烟测试：
   ```bash
   docker run --rm -i -e MCP_GATEWAY_PORT=8000 -e MCP_GATEWAY_DOMAIN=localhost -e MCP_GATEWAY_API_KEY=your-secret-key -v /var/run/docker.sock:/var/run/docker.sock -p 8000:8000 ghcr.io/github/gh-aw-mcpg:latest < config.json
   ```
3. 验证：
   - 打开 `http://127.0.0.1:8000/health`，确认能返回健康状态的 JSON。

## 简介

gh-aw-mcpg 是一个 Docker 优先的 MCP 网关：把多个后端 MCP server 统一通过 HTTP 暴露出来，让沙盒环境里的 Agent 只通过一个入口调用工具，并可叠加策略与审计。

- **适合谁：** 在容器/沙盒里跑 Agent、需要统一可审计 MCP 入口并加护栏的团队
- **可搭配：** Docker、HTTP 传输的 MCP Client、容器化 stdio MCP Server
- **准备时间：** 20 分钟

## 实战建议

- 一个 HTTP 入口可路由多个 MCP 后端（由配置文件驱动）
- Quick Start 默认使用 8000 端口，并挂载 `/var/run/docker.sock` 以拉起后端容器
- GitHub stars / forks（已核验）：见「来源与感谢」

当你的 Agent 环境受限（沙盒/容器）时，网关会变得很关键：

- Agent 不应该直接拥有访问所有工具/网络资源的权限；
- 你希望在一个统一入口上做策略（可读哪些 repo、可写到哪里）、日志与健康检查。

把它当作 “MCP 入口层” 来运维会更稳：

1. 所有工具访问都走网关（包括容器里的 stdio MCP）。
2. 配置文件进版本库，让改动可审查、可回滚。
3. API key 与后端凭据（例如 GitHub token）按 CI 的标准做最小权限与轮转。

如果你在用 GitHub Agentic Workflows，这个仓库就是为沙盒运行提供 MCP 访问层的。

### FAQ

**它具体做什么？**
答：把 MCP 请求通过 HTTP 代理/路由到多个后端 MCP server。

**为什么 Quick Start 需要 Docker？**
答：网关会拉起容器化的 stdio server，因此需要挂载 Docker socket。

**怎么做安全加固？**
答：使用 API key、收紧后端 token 权限，并把策略配置纳入审查流程。

## 来源与感谢

> Source: https://github.com/github/gh-aw-mcpg
> License: MIT
> GitHub stars: 126 · forks: 22


---
Source: https://tokrepo.com/en/workflows/gh-aw-mcpg-mcp-gateway-for-sandboxed-agents
Author: MCP Hub