1MCP

What it does

1MCP (npm package @1mcp/agent, command `1mcp`) is an aggregating runtime. You list your other MCP servers in its configuration (for example with `1mcp mcp add context7 -- npx -y @upstash/context7-mcp`), start `1mcp serve`, and every client connects to that single process rather than having each server wired into it separately. Presets, tag filters and filter expressions decide which upstream servers a given client or project can see, and template servers can be started per client or per session from project context such as the repository checkout.

There are three ways in. Agents such as Codex or Claude Code can use CLI mode, where the agent shells out to `1mcp instructions`, `1mcp inspect` and `1mcp run` to find and call one tool at a time. Clients that only speak stdio launch `1mcp proxy`, which finds the running runtime and forwards traffic to it over HTTP, applying a `.1mcprc` project file if present. Clients that speak streamable HTTP can attach directly to http://127.0.0.1:3050/mcp, adding `?app=<name>` to identify themselves.

By default it exposes only the tools of the servers you configured. In the v0.39.2 source (src/core/capabilities/internalCapabilitiesProvider.ts) its own 14 management tools stay off unless `--enable-internal-tools` or `--internal-tools <groups>` is given, and the opt-in `--enable-lazy-loading` mode swaps the full tool table for three meta tools (`tool_list`, `tool_schema`, `tool_invoke`). Its docs show these tools reaching clients under qualified names such as `1mcp_1mcp_mcp_install`.

What it needs

Node.js ^20.19.0, ^22.12.0 or >=23.0.0 for the npm install (`npm install -g @1mcp/agent`); standalone binaries for Linux, macOS and Windows x64 need no Node. A running `1mcp serve` (HTTP, port 3050 by default) before any client connects: `1mcp proxy` and CLI mode only bridge to it. The runtimes your upstream servers use (npx, uvx and so on) on PATH; the Docker `latest` image bundles uv and bun, `lite` only npm, pnpm and yarn. On Linux the `flock` command for runtime locking.

Limits

Beyond managing servers it adds no abilities: what an assistant can do depends on the upstream servers you configure. Running `serve --transport stdio` directly is deprecated and slower to start; stdio clients are meant to use `1mcp proxy`, which needs a separate `serve` process already running. `proxy --url` sends no saved credentials, and stdio clients cannot complete an OAuth browser sign-in, so a protected runtime needs a named target context. Direct HTTP attachment gets no `.1mcprc` project context. Lazy loading shrinks the initial tool schemas but does not cut backend connections or processes. Its docs say the Windows binary `proxy` launch was not tested on a live Windows host.

Who it suits

Suits a developer who uses several MCP clients (Cursor, Claude Code, Codex) and wants one shared server inventory, with per-project presets or filters, rather than repeating each server's configuration in every client. It also fits teams that want to put OAuth in front of a pool of servers. It is more machinery than needed for someone running one or two servers in one client: it adds a long-running background process and a second layer of configuration, and a direct entry for each server is simpler there. It is a community project, not tied to any vendor's product.