# One MCP: a reverse proxy that puts every MCP server behind one endpoint > One MCP is a Go and React management platform that proxies stdio, SSE and streamable HTTP MCP services, groups them, and exports the group as an Anthropic Skill. It fits teams running several MCP servers; it is not a sandbox or a hosted service. **burugo/one-mcp** — A centralized reverse-proxy platform for MCP servers — manage, group, and export as Skills from a single endpoint. - Repository: https://github.com/burugo/one-mcp - Stars: 414 · Forks: 45 - Language: Go - License: MIT - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/burugo-one-mcp ## The problem One MCP solves for multi-server agent setups Every MCP client keeps its own list of servers. Claude Code has one, another agent has another, and each entry carries its own command, arguments and environment. Once you run five or six MCP servers, the same configuration is copied into every client, and a change to one server means editing every copy. One MCP inverts that. It runs as a single HTTP service on port 3000 by default, connects out to the MCP servers you register (stdio, SSE or streamable HTTP), and exposes them again through one endpoint. The client config points at One MCP instead of at each server. The web interface handles install, configuration and monitoring, and the repository also ships a marketplace listing alongside custom sources, so a server can be added without hand-writing JSON in every client. The audience is narrow but real: developers running more than one MCP server across more than one agent, and teams that want request rates and response times per service rather than a black box. A single-server hobby setup gains little from a proxy layer. ## How the proxy, groups and Skill export fit together The runtime is a Go binary (module one-mcp in go.mod, built on Gin and mark3labs/mcp-go) serving a React frontend compiled into the binary by the Dockerfile. State lives in SQLite by default, with MySQL and PostgreSQL supported through SQL_DSN. Redis is optional and the README says it replaces the local cache in production. Data flows in two directions. Inbound, an MCP client connects to One MCP rather than to the upstream server. Outbound, One MCP holds the connection or process for each registered service. Service groups are the second layer: several services are combined behind a single endpoint, and that group can be exported as an Anthropic Skill for Claude Code and Droid. That export is the feature with no obvious equivalent in a plain reverse proxy, because it turns a set of servers into one artifact an agent can load. Configuration resolves in a documented order: defaults, then ~/.config/one-mcp/config.ini, then environment variables, then command-line flags. The README states that One MCP only reads that one INI path for file-based config, and that Homebrew service values such as ONE_MCP_PORT and --port still override it. That is a clean model, but it also means a config.ini placed anywhere else is silently ignored. ## Installing One MCP with Docker and registering a first service The README calls Docker the recommended path. This command starts the container, publishes port 3000, and mounts a local data directory for the SQLite file. After it returns a container ID, the web interface is at http://localhost:3000. ```bash docker run --name one-mcp -d \ --restart always \ -p 3000:3000 \ -v $(pwd)/data:/data \ buru2020/one-mcp:latest ``` The repository's docker-compose.yaml does the same thing with two mounts and two environment variables. Note that it ships with JWT_SECRET set to a placeholder value, so it must be changed before anything is exposed beyond localhost. ```yaml services: one-mcp: image: docker.io/buru2020/one-mcp:latest ports: - "3000:3000" volumes: - ./data:/data - ./config:/root/.config/one-mcp environment: - JWT_SECRET=your-very-secret-key - SQLITE_PATH=/data/one-mcp.db ``` On macOS and Linux, Homebrew is the other documented route. The README shows the tap, the install, and a background service on port 3000, with a custom port available when 3000 is already taken. ```bash brew tap burugo/tap brew install one-mcp brew services start one-mcp ONE_MCP_PORT=3001 brew services restart one-mcp ``` The README states the default login is username root with password 123456. Change it immediately. From there, add an MCP service in the interface, choose its transport, and confirm it appears as reachable before you build a group around it. ## Where One MCP is the wrong tool The README describes proxying, grouping, monitoring and export. It does not describe sandboxing, resource limits or per-service isolation. If you plan to attach third-party MCP servers you do not trust, a proxy that runs them on your host is not a security boundary, and nothing in the documentation suggests it is meant to be one. Two smaller constraints matter. First, the config file location is fixed at ~/.config/one-mcp/config.ini; the README says so explicitly, which makes containerised config injection depend on mounting that exact path, as the compose file does. Second, the README does not document rollback, schema migration, or what happens to an existing SQLite database when you upgrade across releases such as v1.0.11 to v1.0.13. Back up the file before upgrading. There is also a single point of failure in the design itself. If One MCP is down, every client pointed at it loses every upstream server at once, including servers that would otherwise have run fine as separate stdio processes. For one or two servers, direct configuration in the client is simpler and has no such dependency. ## One MCP compared with a client-side MCP manager MCP Linker and similar tools take the opposite approach: they manage the JSON configuration files of MCP clients on your machine. Nothing runs in between. The client still launches each server directly, and the manager's job is to keep those entries consistent. One MCP sits in the request path. That is a larger commitment, and it buys things a config manager cannot: a single URL for every client, usage and response-time analytics per service, role-based access control with GitHub or Google OAuth, and the group-to-Skill export. It also costs things a config manager does not: an always-on process, a database to back up, and a shared failure domain. ToolHive, Hive MCP and Polyrouter appear in related searches around this project, and they are worth evaluating on the same axis. The question to ask is whether you want configuration managed at rest or traffic proxied in flight. One MCP is firmly the second. If your only pain is inconsistent client config files, a config manager is the smaller fix. ## Licence, maintenance and the real upgrade cost One MCP is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and licence text are retained. That is the permissive end of the spectrum, and it means embedding the proxy in an internal platform carries few obligations. It says nothing about the MCP servers you attach through it, each of which has its own licence. This is not legal advice; check your own obligations. The last push to the repository was on 2026-09-06, the same day v1.0.13 was released, with v1.0.12 on 2026-08-17 and v1.0.11 on 2026-08-02. Releases are roughly two to four weeks apart, so the project is moving, but the README does not document an upgrade procedure. The practical cost of upgrading is therefore: stop the service, copy the SQLite file, pull the new image or brew upgrade, restart, and check the services and groups still resolve. The Dockerfile builds the frontend and backend together and embeds the version from the VERSION file, so the binary and UI versions cannot drift apart, which removes one common class of upgrade problem. The compose file pins buru2020/one-mcp:latest rather than a version tag, so a restart can silently move you forward; pin a tag if you want upgrades to be deliberate. ## Conclusion Adopt One MCP if you already run several MCP servers and want one endpoint, a group exported as a Skill, and per-service usage data. Skip it if you need process isolation for untrusted MCP servers: the README describes proxying and monitoring, not sandboxing. Before rolling it out, verify the default credentials are changed, check that SQLITE_PATH points at a volume you back up, and confirm which transport each upstream service speaks, because the README lists stdio, SSE and streamable HTTP but does not document per-transport failure handling. ## FAQ ### What does MCP stand for in One MCP? MCP stands for Model Context Protocol. One MCP is a centralized proxy and management platform for MCP services, which it can install, configure and monitor from a single interface. ### Does ChatGPT use MCP? The README does not mention ChatGPT. It documents One MCP as a proxy for MCP services, with optional GitHub and Google OAuth for logging into the One MCP interface itself, which is unrelated to ChatGPT. ### Can one MCP server call another in One MCP? The README does not describe server-to-server calls. What it does describe is service groups, which combine multiple MCP services behind a single endpoint and can be exported as an Anthropic Skill for Claude Code and Droid. ### How is MCP different from an API in One MCP's case? The README does not compare MCP with plain APIs. It describes One MCP as a proxy that connects to MCP services over stdio, SSE or streamable HTTP and re-exposes them through one endpoint, with analytics on request rates and response times. ## Sources - [burugo/one-mcp on GitHub](https://github.com/burugo/one-mcp) - [Issues](https://github.com/burugo/one-mcp/issues) - [License: MIT](https://github.com/burugo/one-mcp/blob/main/LICENSE) - [README](https://github.com/burugo/one-mcp/blob/main/README.md) - [Releases](https://github.com/burugo/one-mcp/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/burugo-one-mcp