MCP Aggregator

What is MCP Aggregator?

MCP Aggregator is a tool that combines multiple MCP servers into a single interface, acting as a bridge between an MCP client (like Cursor) and several backend MCP servers. It was primarily created to work around Cursor’s limitation of using only two MCP servers simultaneously.

How to use MCP Aggregator?

Install via the install script, go install, Docker, or the Makefile. Create a configuration file (JSON) that lists all backend MCP servers, then configure your MCP client to point to the aggregator binary (or Docker container) with the required environment variable MCP_CONFIG set to the config file path. Environment variables like MCP_LOG_LEVEL control debugging.

Key features of MCP Aggregator

• Combines multiple MCP servers into one stdio interface.
• Prefixes tool names from backend servers (e.g., shortcut_search_stories).
• Automatically sanitizes tool names by replacing dashes with underscores.
• Supports optional per-server tool filtering (e.g., to stay under Cursor’s 40-tool limit).
• Configurable via environment variables and a JSON config file.
• Debug logging with configurable levels (error, info, debug, trace).

Use cases of MCP Aggregator

• Bypass Cursor’s limit of two MCP servers by aggregating several.
• Maintain a single MCP configuration shared across multiple clients (Cursor, Windsurf, Gemini-CLI, etc.).
• Centralize secret management—API tokens live only in the aggregator config.
• Expose only a subset of tools from each backend server to avoid clutter and limits.

FAQ from MCP Aggregator

What is the primary reason for using MCP Aggregator?

It was built to work around Cursor’s limitation of using only two MCP servers at a time, allowing users to combine many servers without conflicts.

How does MCP Aggregator handle tool names for Cursor compatibility?

It automatically replaces dashes in tool names with underscores (e.g., get-user becomes get_user) and prefixes them with the server name, because Cursor cannot properly detect tools with dashes.

Can I limit which tools from each backend server are exposed?

Yes. You can add a tools object with an allowed list in your server configuration to filter which tools are exposed, helping to stay within Cursor’s 40-tool limit and avoid conflicts.

What are the installation options?

You can install via a curl-based install script (recommended, pre-compiled binary), go install from GitHub source, Docker pull, or building with the provided Makefile.

Where does the configuration live and what environment variables are needed?

Configuration is stored in a JSON file pointed to by the MCP_CONFIG environment variable. Optional variables include MCP_LOG_LEVEL, MCP_LOG_FILE, MCP_PROTOCOL_VERSION, and MCP_CURSOR_MODE.