Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
作者提供的说明(英文原文)
Local MCP broker that exposes one compact entry for many upstream servers.
这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。
我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。
选择你使用的 AI 应用,然后复制设置。
你需要
你用的是哪个应用?
在上方选择你的应用。我们会记住它,下次按钮会显示“安装到 …”。
打开 Claude Desktop → Settings → Developer → Edit Config,把下面的内容粘贴到 claude_desktop_config.json
{
"mcpServers": {
"broker": {
"command": "uvx",
"args": [
"mcp-broker"
]
}
}
}在终端中运行这条命令
claude mcp add broker -- uvx mcp-broker粘贴到项目中的 .cursor/mcp.json,或 ~/.cursor/mcp.json
{
"mcpServers": {
"broker": {
"command": "uvx",
"args": [
"mcp-broker"
]
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
粘贴到项目中的 .vscode/mcp.json
{
"servers": {
"broker": {
"type": "stdio",
"command": "uvx",
"args": [
"mcp-broker"
]
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
这个服务器在你的电脑上运行,而 ChatGPT 只能连接互联网上的服务器。请选择其他应用。
你的选择通过 Cookie 保存在这台设备上,无需账户。
这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同,请以 README 为准。
它在你的电脑上运行;安装后,工具列表会显示在你的 AI 应用中。
我们检查的是任何人都能看到的信息;我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月6日
注册名称已通过 GitHub 账户 doricstack 验证,该账户拥有此仓库
我们还没有从 GitHub 读取这个仓库
我们还没有从 GitHub 读取这个仓库
它在你的电脑上运行,没有互联网端点
在你的电脑上运行,改用本地设置
它在你的电脑上运行;我们只能读取互联网端点的工具列表
与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时,星标数才计入。
它在 1 项适用的基础检查中通过了 1 项。我们没有阅读代码。在添加密钥或令牌之前,请先看看这个服务器要求哪些权限,并使用只具备所需权限的密钥。
注册中心没有列出必需的密钥,不过有些服务器会在首次使用时要求你登录。
它在你的电脑上运行。你的 AI 应用会在需要时启动它,数据不会经过作者的服务器(除非它自己调用在线服务)。
GitHub 仓库最后更新于–,最新版本(2.1.1)于2个月前进入注册中心。
支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。你的电脑上还需要有 Python (uv)。
同一分类中有:Spec Driven Development, Remote Desktop Commander, Apify MCP Server
同一分类中其他作者的服务器,按星标数排序。
如何看卡片:★ GitHub 星标i三大支柱:评价 · 检查 · 使用情况i更新 = 最新版本发布到注册中心的时间i
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Extract data from any website with thousands of scrapers, crawlers, and automations on Apify Store ⚡
按原文从作者的仓库复制。PopNx MCP 没有审查或背书其内容。HTML、图片和脚本已被移除。链接会离开本站。
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.
Client profile
| | one local MCP entry v mcp-broker-client | | Unix socket v mcp-broker-daemon | | profile gates, namespace routing, status, cleanup v upstream MCP servers
The client sees a small set of broker tools:
broker_search_tools
broker_describe_tool broker_call_tool broker_status broker_close_session
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:
make config-init
make config-validate make broker-status make codex-facade-smoke
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:
pipx install mcp-broker
uv tool install mcp-broker brew tap ${HOMEBREW_TAP_REF} brew install mcp-broker
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:
docker build -t mcp-broker:local .
docker run --rm -i mcp-broker:local
Local stdio clients and MCPB-style installs use the package-owned lifecycle:
mcp-broker stdio --init-if-missing
Create the local venv, install dependencies, and verify runtime layout:
make setup
Create private config from the public template:
make config-init
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:
$HOME/mcp/mcp-broker/secrets/
Run the quality gate:
make quality-gate
Validate the configured YAML contract:
make config-validate
Start the broker:
make broker-start
Check status:
make broker-status
For the full install flow, see docs/install.md. For a clone-to-running adoption flow, see docs/adoption-guide.md#clone-to-running-path. For shared-runtime boundaries, see docs/shared-runtime-guardrails.md. P3.8 E2E proof covers tenant isolation, authz denial, quota denial, session affinity, audit events, rollback, degraded mode, local-only routing, and shared-eligible routing. Hosted execution remains unsupported in the public local broker.
Default runtime root:
$HOME/mcp/mcp-broker/
|- backups/ |- logs/ |- renders/ |- run/ |- secrets/ |- sockets/ - state/ - upstreams/
Runtime files are not repo files. Upstream OAuth state, browser state, secret files, sockets, logs, rendered client configs, backups, and daemon state belong under the runtime root.
See docs/runtime-layout.md.
Back up a client config:
make config-backup CLIENT=codex
Dry-run render:
make config-render CLIENT=codex CONFIG_RENDER_APPLY=0
Apply after reviewing the rendered file under $HOME/mcp/mcp-broker/renders/:
make config-render CLIENT=codex CONFIG_RENDER_APPLY=1
Rollback:
make config-rollback CLIENT=codex
Use CLIENT=claude or CLIENT=agy after that profile smoke passes and that client is intended to use the broker. For new JSON-based MCP clients, generate a starter block:
make profile-snippet NEW_PROFILE=local-client NEW_CLIENT_FORMAT=mcp-settings-json
See docs/add-profile.md for the full new-profile flow.
The compact facade keeps chat-facing profiles small:
| Tool | Purpose |
|---|---|
broker_search_tools | Search configured upstream tools by query. Results carry name, description, upstream, purpose, tags, and mutating flag; the heavy inputSchema is omitted and fetched on demand from broker_describe_tool. |
broker_describe_tool | Return schema and metadata for one upstream tool. |
| broker_call_tool | Call one upstream tool through br
只显示了开头部分;其余内容请在仓库中阅读