Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
作者提供的说明(英文原文)
One MCP endpoint for all your servers: a few meta-tools, Keychain secrets, sandbox, audit, OAuth.
这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。
我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。
选择你使用的 AI 应用,然后复制设置。
你用的是哪个应用?
在上方选择你的应用。我们会记住它,下次按钮会显示“安装到 …”。
链接指向作者自己的文件;我们不托管也不重新打包它。打开文件后,Claude Desktop 会进行安装。
在终端中运行这条命令
浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
这个服务器在你的电脑上运行,而 ChatGPT 只能连接互联网上的服务器。请选择其他应用。
你的选择通过 Cookie 保存在这台设备上,无需账户。
这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同,请以 README 为准。
它在你的电脑上运行;安装后,工具列表会显示在你的 AI 应用中。
我们检查的是任何人都能看到的信息;我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月6日
注册名称已通过域名 soflution.com 验证(注册中心会核实域名所有权)
我们还没有从 GitHub 读取这个仓库
我们还没有从 GitHub 读取这个仓库
它在你的电脑上运行,没有互联网端点
在你的电脑上运行,改用本地设置
它在你的电脑上运行;我们只能读取互联网端点的工具列表
与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时,星标数才计入。
它在 1 项适用的基础检查中通过了 1 项。我们没有阅读代码。在添加密钥或令牌之前,请先看看这个服务器要求哪些权限,并使用只具备所需权限的密钥。
注册中心没有列出必需的密钥,不过有些服务器会在首次使用时要求你登录。
它在你的电脑上运行。你的 AI 应用会在需要时启动它,数据不会经过作者的服务器(除非它自己调用在线服务)。
GitHub 仓库最后更新于–,最新版本(5.11.0)于6天前进入注册中心。
支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。你的电脑上还需要有 MCPB。
同一分类中有:Spec Driven Development, Remote Desktop Commander, topo^alpin
同一分类中其他作者的服务器,按星标数排序。
如何看卡片:★ 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.
Avalanche bulletins and mountain weather forecasts for any place in the Alps.
按原文从作者的仓库复制。PopNx MCP 没有审查或背书其内容。HTML、图片和脚本已被移除。链接会离开本站。
McpHub sits between your AI editors and all your MCP servers.
Your agents see 3 tools instead of hundreds , every call goes through the same security guards ,
and your servers run once, sandboxed , shared by Cursor, Claude, Windsurf and VS Code.
Install · Connect your editor · How it works · Code mode · Security · Dashboard · Library · Linux and sync · Configuration · FAQ
-99.9% tokens spent on tool definitions 1,054,593 → 918 on a 928-tool setup 1 process for every editor servers start once, survive editor restarts 8 layers of security Keychain, pinning, sandbox, audit... 0 runtime dependencies a single signed Rust binary
| Each server wired into each editor | Through McpHub | |
|---|---|---|
| Tool definitions in every prompt | all of them (hundreds of thousands of tokens) | 3 tools, schemas loaded on demand |
| Server processes | one copy per editor | one shared copy |
| Secrets | plain text in every editor config | macOS Keychain, ${NAME} references |
| A server silently changes a tool | nobody notices | quarantined until you approve |
A malicious npm server reads ~/.ssh | it can | blocked by the macOS sandbox |
| Remote servers with OAuth | one mcp-remote process each, tokens in plain files | native HTTP, tokens in the Keychain, auto refresh |
| Who called what | unknown | audit log with redacted arguments |
| Finding a new server | search GitHub, copy a JSON snippet, paste a token | Library of the official MCP Registry: trust score, one-click add, secrets straight to the Keychain |
| Your agent needs a tool you lack | you install it by hand | the agent installs it itself from the registry, sandboxed, if it is trusted enough |
| A second machine, a Linux server | redo everything, copy tokens around | same binary, bubblewrap sandbox, encrypted sync of servers and secrets |
curl -fsSL https://raw.githubusercontent.com/Soflutionltd/McpHub/main/get.sh | bash
The script downloads the latest binary for your machine (signed universal binary on macOS, x64 or arm64 on Linux), verifies its SHA-256 checksum and installs it to ~/.local/bin/McpHub. Then:
McpHub dashboard # Library tab: add servers from the official MCP Registry (or McpHub add)
McpHub generate # index every tool once McpHub install # start the daemon at login (LaunchAgent on macOS, systemd --user on Linux)
Manual download
McpHub-macos-universal.tar.gz and its checksum.shasum -a 256 -c McpHub-macos-universal.tar.gz.sha256tar -xzf McpHub-macos-universal.tar.gz && install -m 755 McpHub ~/.local/bin/McpHubxattr -d com.apple.quarantine ~/.local/bin/McpHubLinux (amd64, arm64) and Windows (amd64) archives are attached to every release too. On Linux the sandbox uses bubblewrap and secrets live in ~/.McpHub/secrets.env (mode 600, hidden from sandboxed servers), see Linux servers and sync. Windows has no sandbox.
Build from source
git clone https://github.com/Soflutionltd/McpHub.git
cd McpHub make install # cargo build --release, install, sign
make install signs with your Developer ID certificate when one is present, so macOS keeps its permissions from one version to the next. Linux and Windows build from source (cargo build --release); the macOS sandbox and Keychain features are macOS only.
Once the daemon runs (McpHub install), McpHub keeps itself up to date. Editors connected by URL (Cursor, Claude Code, VS Code, Windsurf) need nothing: they talk to the updated daemon.
latest.json (version and SHA-256 of each file) signed with minisign; the public key is compiled into McpHub. On macOS the new binary must also carry Soflution's Developer ID signature. Anything else is refused."settings": { "autoUpdate": false } turns it off; McpHub update installs the latest release right away, McpHub update --check only reports it. Development builds and named instances never update themselves (the main instance updates the shared binary).mcphub.mcpb uses the installed McpHub when there is one, so it follows the same updates; otherwise it runs the binary it ships with.The daemon listens on http://127.0.0.1:24680. Your token is in ~/.McpHub/auth-token.
Cursor , ~/.cursor/mcp.json
{
"mcpServers": { "McpHub": { "url": "http://127.0.0.1:24680/mcp", "headers": { "Authorization": "Bearer " } } } }
Claude Code
claude mcp add --transport http mcphub http://127.0.0.1:24680/mcp \
--header "Authorization: Bearer $(cat ~/.McpHub/auth-token)"
Claude Desktop , claude_desktop_config.json
{
"mcpServers": { "McpHub": { "command": "/Users/you/.local/bin/McpHub", "args": ["stdio"] } } }
VS Code , .vscode/mcp.json
{
"servers": { "mcphub": { "type": "http", "url": "http://127.0.0.1:24680/mcp", "headers": { "Authorization": "Bearer " } } } }
Windsurf and other SSE clients
Use http://127.0.0.1:24680/sse with the same Authorization header.
One profile per client. Give each editor its own view: http://127.0.0.1:24680/mcp/cursor only shows what the cursor profile allows (see Profiles).
client/ is a small Node MCP server that sits between your editor and the daemon. It talks to the running daemon (SSE, token from ~/.McpHub/auth-token) and falls back to McpHub stdio. It exposes six tools:
mcphub_bootstrap: call once per conversation. Resolves the project from the workspace, returns its aliases and allowed servers, and recalls compact MemoryPilot context, also for folders without a project entry.mcphub_search, mcphub_call: same as the daemon, plus suggestions on a misspelled tool or server, and the input schema on argument errors.mcphub_batch: up to 20 independent calls in one round-trip.mcphub_status, mcphub_savings: server health and an honest context-size comparison.Per-project policy lives in ~/.McpHub/projects.json (or the path in MCPHUB_PROJECTS), see client/projects.example.json. For a workspace listed there, only its allowedServers are reachable, and a call aimed at another Supabase project, App Store app or Cloudflare project is refused. Without the file there is no policy; an unreadable file is an error, never silently ignored.
Each release ships the client as a single file, mcphub-client.mjs, which the daemon keeps up to date in ~/.McpHub/client/ (Node 20 or later, no npm install). Editors pick up a new version the next time they start the server:
{
"mcpServers": { "McpHub": { "command": "node", "args": ["/Users/you/.McpHub/client/mcphub-client.mjs"] } } }
From a clone instead: cd client && npm ci, then point args at /path/to/McpHub/client/index.js.
npm test runs smoke tests against the local daemon (MemoryPilot and supabase configured), with a throwaway project file.
Connecting to a client's Stripe (or Supabase, Cloudflare…) should not log you out of your own, and your own agent should never reach theirs by mistake. Two levels, from light to strict:
1. Client-owned servers (same McpHub). Add the client's server under its own name (stripe-acme, with its own OAuth token or restricted key, since tokens are stored per server name) and list it in the client project's ownedServers:
"acme": {
"workspaces": ["/Users/you/Clients/Acme"], "aliases": { "product": "Acme" }, "allowedServers": ["MemoryPilot", "context7"], "ownedServers": ["stripe-acme"] }
An owned server only answers, appears in mcphub_search and in mcphub_status when working_dir is inside that client's workspace; the project argument alone is not enough. A server owned by two projects is a start-up error. This guard lives in the Node client: an editor connected straight to the daemon still sees every server, so give it a profile with "excludeServers": ["*-acme"].
2. A separate instance (nothing shared). For clients who require it, run a second McpHub with its own folder, port, Keychain service, auth token and LaunchAgent:
export MCPHUB_INSTANCE=acme MCPHUB_PORT=24690
McpHub add # writes ~/.McpHub-acme/config.json McpHub oauth login stripe # token stored under Keychain service McpHub-acme McpHub install # Launc
只显示了开头部分;其余内容请在仓库中阅读