Six failure modes are documented with their causes and fixes — including that Claude Desktop does not expand environment variables in config paths, and that editors can inject a byte-order mark that silently breaks the JSON. Those are the bugs that cost an afternoon and produce no error message. On the gateway itself: filtering tool exposure per client is the lever that keeps a growing server count from eating the context window before anyone asks a question.
A governance layer for teams that already run several MCP servers. Clients connect to one gateway instead of to each server, tool exposure is filtered per client so context does not grow with your server count, and every call is written to an audit trail. It also generates and registers new servers from a plain-English description.
- Python run in an isolated subprocess sandbox — `execute_code`
- A plain-English request written as code and then executed — `generate_and_execute`
- A described MCP server built as a full project, then registered and launched in the gateway — `generate_mcp_project`
- A REST surface alongside the MCP one: health, execute, register a server, list the catalogue, and generate a server from a prompt
- Sandbox limits on every execution: network isolation, a memory cap defaulting to 128 MB, a process cap of 64, a read-only filesystem except `/tmp`, no privilege escalation and non-root execution
- Six documented Windows MCP failure modes with their fixes, from the silent 60-second timeout to the byte-order-mark trap in JSON configs
Docker Desktop installed and running, Python 3.11+, Git, and an MCP client. Self-hosted — there is no account. Clone the repository, install `core/requirements.txt` into a virtual environment and start it with `python -m uvicorn main:app --reload --port 8009`, or build the container and run it. Clients connect to the SSE endpoint at `http://localhost:8009/sse`; the Docker deployment maps the gateway to port 8089. Optional API-key authentication and rate limiting switch on when the security module is present.