Local MCP broker that exposes one compact entry for many upstream servers.
Copy the AI prompt to install this server into Claude Code, Cursor, or another agent β or use 1-click editor setup below.
π‘ Paste the JSON block into your client's configuration file under mcpServers, then restart the application.
mcp-broker is a local Model Context Protocol process broker for MCP clients.
Think PgBouncer for MCP: one stable local endpoint in front of many upstream MCP servers. The broker owns upstream startup, reuse, cleanup, profile exposure, status, and safe tool routing.
The core idea is simple: do not make every agent session load every upstream tool definition before the user asks a task.
AI coding sessions with many MCP servers tend to accumulate the same problems:
mcp-broker puts a small broker facade in front of those upstreams. It is not a hosted workflow builder; it is local infrastructure for keeping MCP clients small, predictable, and under one config contract.
The client sees a small set of broker tools:
The upstream MCPs still exist. They are discovered and called through the broker when a task needs them.
On 2026-05-24, the measured Codex setup went from many raw MCP and hosted app tool definitions to one broker facade plus a pruned codex_apps cache.
| Surface | Before | After | Reduction |
|---|---|---|---|
| Direct Codex MCP server entries | 11 | 1 | 90.91% |
| MCP tool definitions | 414 | 4 | 99.03% |
Hosted codex_apps tool definitions | 195 | 39 | 80.00% |
| Combined always-loaded tool definitions | 609 | 43 | 92.94% |
| Combined serialized tool payload bytes | 1,026,171 | 185,877 | 81.89% |
Combined o200k_base tool tokens | 276,989 | 45,281 | 83.65% |
The 92.94% number is a tool-definition count reduction. The 83.65% number is a token reduction for canonical serialized tool payloads measured with tiktoken o200k_base.
See docs/context-reduction-measurement.md for evidence and caveats.
$HOME/mcp/mcp-broker, outside the repo.Core differentiators:
Use mcp-broker if you:
This repo is not an enterprise MCP control plane. It is local desktop infrastructure for developer-agent workflows.
Implemented:
config/broker.private.yaml, created from config/broker.example.yaml.config/broker.schema.json.runtime.root..gemini/config/mcp_config.json, including its MCP
allowed-server policy.Wiring status:
/mcp acceptance..gemini/config/mcp_config.json.Public release status:
make release-version-check; publication proof is tracked in docs/distribution.md.mcpb/manifest.json for local directory review.See ROADMAP.md for public-facing release work.
mcp-broker has three runtime layers:
| Layer | Responsibility |
|---|---|
| Client shim | Presents one stdio MCP server entry to each MCP client and forwards JSON-RPC over the broker socket. |
| Broker daemon | Owns profile gates, namespace routing, upstream lifecycle, status, logging, and cleanup. |
| Upstream MCP servers | Run as configured stdio, HTTP, streamable HTTP, or SSE connectors with shared or per-session process policy. |
The config file is the contract. Profiles decide exposure, upstreams define transport and lifecycle behavior, and smoke probes define safe read calls for validation.
| Approach | Best fit | Tradeoff |
|---|---|---|
| Raw MCP client config | Small setups with a few tools. | Every session loads the full tool list and each client repeats config. |
| Simple MCP proxy | Forwarding one server to one client. | Does not own upstream lifecycle, profile budgets, or cross-client cleanup. |
| Hosted app connectors | SaaS tools managed by the client provider. | Local MCP state and cross-client parity remain outside user control. |
mcp-broker | Local developers with many upstream MCPs across MCP clients. | Adds a local daemon and config contract that must be installed and monitored. |
The quickstart flow should look like this:
In an MCP client, /mcp should show one mcp-broker entry. Use broker_status
to inspect profile-visible upstream state.
Prerequisites:
launchctl for LaunchAgent use.python3.make.npx for npm-based upstream MCP servers.Package installs:
Homebrew installs the same console scripts as the Python package. Package installs do not write MCP client config; client wiring stays an explicit Makefile action.
Docker is for container-friendly configs:
Local stdio clients and MCPB-style installs use the package-owned lifecycle:
Create the local venv, install dependencies, and verify runtime layout:
Create private config from the public template:
config-init creates the destination directory when needed and copies the public
template as the starting point. It does not import local MCP inventory, user
paths, or secrets.
Edit config/broker.private.yaml for local upstreams. Keep secret values out of config. Use environment variable names or files under:
Run the quality gate:
Validate the configured YAML contract:
Start the broker:
Check status:
No reviews yet β be the first to share how this listing worked for you.
Showcase your server listing on GitHub or your project documentation. Embed this dynamic SVG badge to highlight official listing status and live engagement.
[](https://allmcps.com/mcp/mcp-broker)<a href="https://allmcps.com/mcp/mcp-broker"><img src="https://allmcps.com/api/badge/mcp-broker?style=directory" alt="MCP Broker on AllMCPs" /></a>