One MCP: a self-hosted proxy that merges MCP servers and exports them as Skills
A centralized reverse-proxy platform for MCP servers — manage, group, and export as Skills from a single endpoint.
At a glance
- What is it?
- One MCP is a Go and React management platform that sits in front of your Model Context Protocol servers, groups them behind one endpoint, and exports those groups as Anthropic Skills. The useful part is the grouping and export; the part to think about before adopting is that it becomes a single process every agent depends on.
- Who is it for?
- Adopt One MCP if you run several MCP servers across more than one machine or agent and you want them behind one address with usage analytics and a web UI for configuration. Skip it if you run one local stdio server, or if you cannot accept a central process that every agent session depends on.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 10 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem One MCP addresses: MCP configuration scattered across clients
Every MCP client keeps its own list of servers. Add a filesystem server to one agent and a search server to another, and the two configurations drift. Each client also speaks to each server directly, so nothing sits in the middle to record which tool was called, how often, or how long it took. The README describes One MCP as a centralized proxy that lets you discover, install, configure, and monitor MCP services from various providers, with a web interface on top. The intended user is someone running more than one MCP server, probably across stdio, SSE and streamable HTTP transports, who wants a single place to register them and a single endpoint to hand to clients. A second audience is the one implied by the mcp-convert-to-skill topic: people who want a set of MCP tools packaged as an Anthropic Skill for Claude Code or Droid rather than wired up server by server. If you run exactly one local stdio server, this platform adds a process and a database to solve a problem you do not have.
Service groups and Skill export: the mechanism that matters
The feature list names three transports for registered services: stdio, SSE and streamable HTTP. Those are the shapes an MCP server can take, and One MCP accepts all three, which means a locally spawned process and a remote HTTP endpoint end up in the same registry. Service Groups are the layer above: you combine multiple registered services into one group, and the group is exposed as a single endpoint. The README's own summary of the feature is that groups let you combine multiple MCP services and export them as Skills. So the data flow is: individual servers are registered and configured, a group selects a subset of them, and the group is published either as one MCP endpoint or as a Skill artifact for Claude Code and Droid. The README does not document the Skill file format, the manifest fields, or how tool name collisions inside a group are resolved. That is a real gap. If two grouped servers both expose a tool called search, nothing in the supplied material says what the exported Skill contains. Treat that as something to verify against your own servers before you build a workflow on top of grouping.
Running it: Homebrew, Docker and the config.ini priority order
Three installation paths are documented. Homebrew covers macOS and Linux: brew tap burugo/tap, then brew install one-mcp, then brew services start one-mcp for a background service on port 3000. Docker is described as recommended: docker run --name one-mcp -d --restart always -p 3000:3000 -v $(pwd)/data:/data buru2020/one-mcp:latest. Manual installation clones the repository, copies .env_example to .env, and runs bash ./run.sh. The README states the default login is username root with password 123456, which you should change before the instance is reachable by anything but localhost. Runtime configuration resolves in a documented order: built-in defaults, then ~/.config/one-mcp/config.ini, then environment variables such as PORT, SQLITE_PATH and ENABLE_GZIP, then command-line flags like --port. The README is explicit that only that one INI path is read, that the file is created automatically on first startup, and that Homebrew service values such as ONE_MCP_PORT and --port override config.ini. That last point is the one to remember: if you set ONE_MCP_PORT=3001 and also write PORT=3000 in config.ini, the environment variable wins. Database options are SQLite by default, with MySQL and PostgreSQL supported through SQL_DSN, and Redis is optional, described as a replacement for the local cache in production.
Authentication, analytics and the operational surface you inherit
One MCP ships multi-user support with role-based access control and OAuth login through GitHub and Google. The README gives the callback URLs to register: http://your-domain.com/oauth/github and http://your-domain.com/oauth/google, with the client credentials entered in the application preferences rather than in the environment file. The analytics feature tracks usage, request rates, response times and system health. Because the proxy sees every tool call, the analytics are only as complete as your clients' willingness to route through it. A client that still talks directly to a server bypasses both the proxy and the metrics, and the dashboard will not tell you that it happened. The same applies to the GITHUB_TOKEN setting: the README says it is optional and is used when querying npm package GitHub homepages, with rate limits applying if you leave it unset. That is a marketplace convenience, not a core function.
The failure mode: one process in front of every agent session
A centralized proxy is a single point of failure by construction. If the One MCP process stops, every client configured to point at it loses every grouped server at once, including ones that would otherwise have run fine locally as stdio processes. The README does not describe a high-availability mode, a fallback path, or what a client sees when the proxy is unreachable. Docker with --restart always and the Homebrew service wrapper both mitigate a crash, but neither helps during an upgrade, and the release cadence visible in the repository (v1.0.11, v1.0.12, v1.0.13 between early August and early September 2026) suggests you will be upgrading. There is also a configuration trap worth naming: the precedence order means a stale ONE_MCP_PORT or --port can silently override the config.ini you just edited, and since the README says One MCP creates a minimal default config.ini on first startup, it is easy to edit a file that is not the one taking effect. Finally, the supplied material does not state what happens to in-flight requests during a restart, so plan upgrades for a window when no agent is mid-task.
Where it sits against running MCP servers directly
The alternative is the default: each client spawns its own stdio servers and connects to remote ones directly, with no intermediary. That approach has no extra process, no database, and no shared credential store, and a crash in one server affects only the client that launched it. What it does not give you is a single endpoint, a shared registry, usage analytics, or Skill export. The difference in approach is not about protocol support, since both speak MCP; it is about where configuration lives. Direct setup keeps configuration inside each client, which is fine for one or two servers and painful at five. One MCP moves configuration into a server-side database with a web UI, which is better at scale and worse when the server is down. A second alternative for the Skill use case specifically is writing the Skill by hand against the MCP servers you already have, which avoids the proxy entirely but gives up the grouping and the analytics. Which one is right depends on whether you value the single endpoint more than you value the absence of a middle process.
Licence, upgrades and what maintenance actually involves
One MCP is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence with no copyleft obligation on your own code, but this is not legal advice and you should read the LICENSE file in the repository for the exact terms. The maintenance cost is the part that is easy to underestimate. You are running a Go binary plus a React frontend served from it, a database (SQLite, MySQL or PostgreSQL), and optionally Redis, and you are responsible for backing up whichever database you chose. With SQLite the state is a single file at the path given by SQLITE_PATH, which makes backup trivial but also means the file is the whole system's configuration. With MySQL or PostgreSQL you get a network database but you have added a dependency. Upgrades mean pulling a new image or brew package and restarting, which is the outage window described above. Choosing SQLite and a data volume you actually back up is the lowest-effort path, and the README's Docker example already mounts ./data for exactly that reason.
Editorial conclusion
Adopt One MCP if you run several MCP servers across more than one machine or agent and you want them behind one address with usage analytics and a web UI for configuration. Skip it if you run one local stdio server, or if you cannot accept a central process that every agent session depends on. Before deploying, change the default root credentials, confirm which database backend you will use and whether SQLite is enough, and check whether the Skill export format matches the client you actually use.
Community notes