/ Directory / Playground / 1MCP Agent
● Community 1mcp-app ⚡ Instant

1MCP Agent

by 1mcp-app · 1mcp-app/agent

Aggregate every MCP server you use into one endpoint — shared config, shared auth, namespaced tool names, and one place to update them all.

1mcp/agent is a unifying proxy for MCP servers. Configure it once with all your servers (filesystem, github, postgres, sentry, etc.), and your client (Claude Desktop / Cursor / Cline) only sees one MCP. Tools get namespaced (github__create_issue), the agent handles spawning/health-checks, and you can hot-reload config without restarting your client.

Why use it

Key features

Live Demo

What it looks like in practice

onemcp-agent.replay ▶ ready
0/0

Install

Pick your client

~/Library/Application Support/Claude/claude_desktop_config.json  · Windows: %APPDATA%\Claude\claude_desktop_config.json
{
  "mcpServers": {
    "onemcp-agent": {
      "command": "npx",
      "args": [
        "-y",
        "@1mcp/agent"
      ]
    }
  }
}

Open Claude Desktop → Settings → Developer → Edit Config. Restart after saving.

~/.cursor/mcp.json · .cursor/mcp.json
{
  "mcpServers": {
    "onemcp-agent": {
      "command": "npx",
      "args": [
        "-y",
        "@1mcp/agent"
      ]
    }
  }
}

Cursor uses the same mcpServers schema as Claude Desktop. Project config wins over global.

VS Code → Cline → MCP Servers → Edit
{
  "mcpServers": {
    "onemcp-agent": {
      "command": "npx",
      "args": [
        "-y",
        "@1mcp/agent"
      ]
    }
  }
}

Click the MCP Servers icon in the Cline sidebar, then "Edit Configuration".

~/.codeium/windsurf/mcp_config.json
{
  "mcpServers": {
    "onemcp-agent": {
      "command": "npx",
      "args": [
        "-y",
        "@1mcp/agent"
      ]
    }
  }
}

Same shape as Claude Desktop. Restart Windsurf to pick up changes.

~/.continue/config.json
{
  "mcpServers": [
    {
      "name": "onemcp-agent",
      "command": "npx",
      "args": [
        "-y",
        "@1mcp/agent"
      ]
    }
  ]
}

Continue uses an array of server objects rather than a map.

~/.config/zed/settings.json
{
  "context_servers": {
    "onemcp-agent": {
      "command": {
        "path": "npx",
        "args": [
          "-y",
          "@1mcp/agent"
        ]
      }
    }
  }
}

Add to context_servers. Zed hot-reloads on save.

claude mcp add onemcp-agent -- npx -y @1mcp/agent

One-liner. Verify with claude mcp list. Remove with claude mcp remove.

Use Cases

Real-world ways to use 1MCP Agent

Consolidate 20+ MCP servers behind one endpoint

👤 Power users with many MCPs configured ⏱ ~25 min intermediate

When to use: Your claude_desktop_config.json has 20+ entries and adding/removing servers is painful.

Prerequisites
  • 1mcp installed — npx -y @1mcp/agent (or persistent install via the docs)
Flow
  1. Move existing servers to 1mcp config
    Use onemcp-agent. Convert my current MCP client config into a 1mcp config file with each server prefixed by its name.✓ Copied
    → 1mcp.config.json with all servers + prefixes
  2. Point client at 1mcp
    Replace my client's MCP config with a single entry pointing at 1mcp; keep a backup.✓ Copied
    → Client now sees one server; tools listed with prefixes
  3. Hot-add a new server
    Add the new arxiv MCP to 1mcp config and reload — without restarting Claude Desktop.✓ Copied
    → New tools appear in the next list_tools refresh

Outcome: Sane single source of truth for all MCP servers; faster iteration.

Pitfalls
  • Tool names get long with prefix — Use short prefix aliases per server (gh, fs, pg) instead of full names

Run a team-shared MCP stack on a dev box

👤 Small dev teams using shared infra ⏱ ~45 min advanced

When to use: You want everyone on the team to share the same vetted MCP servers + secrets, not duplicate configs.

Prerequisites
  • Reachable host — Run 1mcp on a dev box exposing SSE/HTTP transport with auth
Flow
  1. Centralize config
    Configure 1mcp on the dev box with our team's MCP set + shared auth tokens. Expose via authenticated SSE.✓ Copied
    → Stack running; SSE endpoint requires bearer token
  2. Distribute one client config
    Generate per-developer client snippets pointing to the shared SSE URL with their personal bearer.✓ Copied
    → One snippet per developer

Outcome: Team gets vetted MCP fleet without each person managing 20 configs.

Pitfalls
  • Single host = single failure point — Document fallback to local config; or run replicas behind a load balancer

Quarantine an untrusted MCP behind 1mcp

👤 Security-aware users trying community MCPs ⏱ ~30 min advanced

When to use: You want to try a third-party MCP but not give it your full env or your full filesystem access.

Flow
  1. Run 1mcp in a container
    Set up 1mcp in a Docker container with minimal env; mount only ./scratch/. Add the untrusted MCP under a 'sandbox' prefix.✓ Copied
    → Container running; only sandbox/ tools visible from sandbox MCP
  2. Use it for one task
    Run the experimental task only with sandbox__ tools.✓ Copied
    → Task completes; nothing escaped the container

Outcome: Try untrusted servers without giving them keys to the kingdom.

Pitfalls
  • Forgetting that the MCP can still hit the network from inside the container — Use --network none or a restricted network namespace if egress matters

Combinations

Pair with other MCPs for X10 leverage

onemcp-agent + filesystem + github

Aggregator for your daily-driver server set

Configure 1mcp with filesystem (prefix fs) + github (prefix gh) + postgres (prefix pg). Use fs__read_file and gh__create_issue from one client.✓ Copied

Tools

What this MCP exposes

ToolInputsWhen to callCost
list_servers Health check / debug 0
reload_config config_path? After editing 1mcp.config.json 0
restart_server server_name When a child server is misbehaving 0
<prefix>__<tool> as per child tool All child tools surface with their prefix depends on child server

Cost & Limits

What this costs to run

API quota
Adds negligible overhead per call
Tokens per call
0 — proxy passes through; tools list cost is the sum of children
Monetary
Free
Tip
Disable rarely-used child servers via config flag instead of removing — keeps the prompt slim

Security

Permissions, secrets, blast radius

Minimum scopes: Whatever child servers need
Credential storage: Child server env vars centralized in 1mcp.config.json — protect that file
Data egress: Whatever child servers do — 1mcp itself doesn't egress unless configured to remote SSE
Never grant: World-readable config file with secrets

Troubleshooting

Common errors and fixes

Child server fails to start

Check 1mcp logs for that server's stderr; usually a missing env var or wrong command path

Verify: Try the child's command standalone in a terminal
Tool name collision

Add or shorten prefixes per server in config

Verify: list_servers shows current prefixes
Hot-reload doesn't pick up changes

Some changes require restart (transport mode, port). Run restart_server on the affected child or full 1mcp restart

Slow first response

Children spawn lazily by default — set 'eager: true' for hot servers

Alternatives

1MCP Agent vs others

AlternativeWhen to use it insteadTradeoff
metamcpYou want a UI-managed aggregator with team workflowsHeavier; more opinionated
mcp-router (TheLunarCompany/lunar)You need governance and audit logs (enterprise)Bigger surface; more setup

More

Resources

📖 Read the official README on GitHub

🐙 Browse open issues

🔍 Browse all 400+ MCP servers and Skills