
McpHub
com.soflution由 soflution.com 發布v5.11.0更新於 Oct 31, 2026
One MCP endpoint for all your servers: a few meta-tools, Keychain secrets, sandbox, audit, OAuth.
概覽
McpHub 是介於 AI 編輯器與所有 MCP 伺服器之間的本地閘道,只提供三個中繼工具(搜尋、呼叫、程式碼模式),並具備沙箱、密鑰管理與稽核。
- 可以做什麼
- 透過搜尋、呼叫、執行三個中繼工具,跨所有已設定的 MCP 伺服器尋找並呼叫工具
- 在程式碼模式中執行簡短 JavaScript 程式,於沙箱化的 Node 程序中串接多次工具呼叫
- 在儀表板管理伺服器:新增、啟用、停用、編輯,查看狀態、日誌、延遲與 token 節省
- 瀏覽官方 MCP Registry 資料庫,查看信任分數並一鍵安裝,也支援由代理自行安裝
- 以原生 OAuth 連線遠端伺服器,並將密鑰存入 macOS 鑰匙圈或密鑰檔案
- 依用戶端設定設定檔、唯讀模式、工具固定與隔離,並留下稽核日誌
- 適用情境
- 當你把大量 MCP 伺服器接進 Cursor、Claude、VS Code 或 Windsurf,想降低工具定義佔用的 token、讓多個編輯器共用同一個伺服器程序,並集中管理密鑰、沙箱與稽核時適用。也適合需要依專案或依客戶隔離伺服器與憑證的情境。
- 執行需求
- 需在本機安裝 McpHub 執行檔(macOS、Linux 或 Windows;macOS 沙箱與鑰匙圈功能僅限 macOS)。編輯器透過本機 HTTP 127.0.0.1:24680 加上 Bearer 權杖連線,或使用 stdio。程式碼模式需 Node.js 22.13 以上,選用的專案感知用戶端需 Node 20 以上。Linux 沙箱需 bubblewrap。所加入的伺服器可能各自需要 API 金鑰或 OAuth 登入。
安裝
在 SourceWeft 中
- 開啟 儀表板中的 McpHub,將其新增到工作區。
- 為需要使用其工具的對話啟用該服務。
Desktop only,透過 STDIO。 STDIO 服務會啟動本機處理程序,因此需要 SourceWeft 桌面主機。
其他 MCP 客戶端
參照 儲存庫 中的啟動說明。
README
[McpHub, one secure hub for all your MCP servers]
[Download for macOS] [Install in one line]
[Latest release] [MCP 2026-07-28] [Rust] [macOS and Linux] [MIT]
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
✨ At a glance
🚀 Install in one line
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:
Manual download
- Download
McpHub-macos-universal.tar.gzand its checksum. shasum -a 256 -c McpHub-macos-universal.tar.gz.sha256tar -xzf McpHub-macos-universal.tar.gz && install -m 755 McpHub ~/.local/bin/McpHub- Downloaded through a browser? Clear the quarantine flag:
xattr -d com.apple.quarantine ~/.local/bin/McpHub
Linux (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
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.
🔄 Updates
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.
- Signed. Every release publishes
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. - Gradual. A new version reaches 10% of installations on day one, everyone after 24 hours. The daemon checks at start-up, then every 6 hours. The only request is the download from GitHub: no telemetry, the rollout bucket is drawn from a random local id that never leaves your machine.
- Never in the middle of a call. The new binary is installed next to the old one; each daemon switches over as soon as no request is in flight (editors reconnect by themselves). If the new version fails to start three times, the previous one is restored and that version is skipped.
- Your choice.
"settings": { "autoUpdate": false }turns it off;McpHub updateinstalls the latest release right away,McpHub update --checkonly reports it. Development builds and named instances never update themselves (the main instance updates the shared binary). - Claude Desktop extension.
mcphub.mcpbuses the installed McpHub when there is one, so it follows the same updates; otherwise it runs the binary it ships with. - Windows. The binary is replaced in place and used from the next session start.
🔌 Connect your editor
The daemon listens on http://127.0.0.1:24680. Your token is in ~/.McpHub/auth-token.
Cursor, ~/.cursor/mcp.json
Claude Code
Claude Desktop, claude_desktop_config.json
VS Code, .vscode/mcp.json
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).
Project-aware client (optional)
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:
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.
Working on client accounts
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:
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:
A named instance never imports the servers declared in your editors, refuses the main port (24680), and its token is rejected by the main daemon (and the other way round). Point the editor of that client's workspace at it with the same variables:
MCPHUB_HOME and MCPHUB_VAULT_SERVICE override the folder and the Keychain service. Sandboxed servers of every instance are denied all ~/.McpHub* folders. Automatic start of a named instance is supported on macOS and Linux.
🧭 How it works
[Architecture: AI clients, the McpHub pipeline, local and remote servers]
- Your editor connects once to the McpHub daemon (Streamable HTTP, SSE or stdio).
- The agent sees three tools:
mcphub_search(BM25 search over every tool),mcphub_call(run one tool) andmcphub_run(code mode). - Each call is authenticated, filtered by the client profile, checked against the tool pins and permissions, then routed to the right server, which is started on demand and stopped when idle.
- Local servers run under the macOS sandbox with a minimal environment; remote servers are reached directly over HTTP with OAuth tokens kept in the Keychain.
- Every call lands in the audit log.
Token savings
[Tool definitions: 1,054,593 tokens directly, 918 tokens through McpHub]
Wiring dozens of MCP servers straight into an editor loads every tool schema into every conversation. On the setup above (35 servers, 928 tools) that is over a million tokens, more than any context window. McpHub replaces it with three small tools and loads a schema only when the agent actually needs it.
🧠 Code mode
[Without code mode: 25 round trips. With mcphub_run: one call]
For multi-step or bulk work, the agent sends a short JavaScript program with mcphub_run:
mcp.call(server, tool, args)returns the tool result,mcp.search(query)finds tools,console.logis captured.- The program runs in a separate Node.js process (22.13 or newer) started with
--permission: no files, no network, no subprocesses, inside a macOS sandbox. - Its only way out is
mcp.call, which goes through every McpHub guard (permissions, quarantine, profiles, audit). - Limits:
settings.codeMode→{ "timeoutSecs": 60, "maxCalls": 100 }, output capped at 1 MB.
🛡️ Security
MCP servers are third-party programs, often fetched on the fly with npx -y package@latest, running with your permissions. McpHub treats them accordingly.
Locked local API
/mcp,/sse,/messageand every/api/*route requireAuthorization: Bearer <token>(a 256-bit random token in~/.McpHub/auth-token, mode 600).- Requests whose
Hostis not127.0.0.1,localhostor[::1]are refused (DNS rebinding), as are requests with a foreignOrigin. No CORS headers: a web page cannot call the hub. - The dashboard opens through a one-time link (
McpHub dashboard) and keeps a per-session secret, never the main token.
Secrets in the macOS Keychain
config.json only holds ${GITHUB_TOKEN} references. Each server process starts with a minimal environment (system variables, its own env, and the names listed in inheritEnv), so no server ever receives the secrets of the others.
Tool pinning and poisoning detection
The first time McpHub sees a server, it records a SHA-256 fingerprint of every tool (name, description, input and output schemas, annotations) in ~/.McpHub/tool-pins.json. If a server later changes a definition (a "rug pull"), the tool is quarantined: hidden from the catalog and refused on call, until you check it:
Descriptions and schemas are scanned for invisible Unicode and classic injection phrases ("ignore previous instructions", "do not tell the user", ~/.ssh/id_rsa, mcp.json...). New tools appearing on an approved server are held back too.
With "pinning": "off" (or "warn"), changed definitions are accepted automatically but scanned again: a new description that trips the scan is still blocked when scan is block.
Automatic review of new tools ("newTools": "auto"). Instead of holding back every new tool, McpHub accepts a new tool on its own when it fits the server, and quarantines it when:
- its name breaks the server's naming convention (a
sync_datatool on a server whose tools all start withfl_); - it brings a sensitive capability the server did not have: a text parameter for a password, secret or API key, a code or command parameter on a tool that runs it, or a webhook / callback / upload URL. Capabilities are read from the tool's name and parameters, not from what its description mentions;
- its description shares almost no vocabulary with the rest of the server;
- with
"requireSignedCommits": true, the server runs from a local git checkout whose last commit is not signed by a trusted key (git log --format=%G?). A hijacked GitHub account can push code, but cannot sign it with a key that only lives on your machine.
There is no pop-up: blocked tools are listed under securityAlerts in mcphub_status and mcphub_bootstrap, so the agent tells you at the start of the next conversation, and a call to a blocked tool returns the reason. McpHub pins simulate replays the filter on every cached tool, as if each were new, to check it would not hold back legitimate tools.
Server isolation (macOS sandbox)
shield runs every local server under sandbox-exec. Servers keep working normally but cannot read or write SSH and GPG keys, cloud and GitHub credentials, browser profiles and cookies, Claude/Cursor configs, shell profiles, LaunchAgents or McpHub's own files, and cannot run security, launchctl, osascript or open. A secret file that a server references in its own env or args (an App Store .p8 key, for example) stays readable.
Per server: "sandbox": false, "strict" (no writes outside temp folders and caches), or { "mode": "strict", "network": false, "allowWrite": ["~/data"], "allowExec": ["open"] }.
The sandbox is a strong barrier against credential theft by a compromised package, not a full container.
Permissions, confirmations and audit
denyblocks a tool,confirmasks a human first through a native macOS dialog that the agent cannot answer.autoClassify: trueappliesconfirmto every destructive tool (by name and by the MCPdestructiveHintannotation).McpHub policy test SERVER TOOLshows which rule applies.McpHub audit --tail 50shows the last calls, with secrets redacted, in~/.McpHub/audit.jsonl(rotated).
🌐 Remote servers and shared OAuth
Remote servers are reached directly over Streamable HTTP, without an mcp-remote process per server. McpHub implements the MCP authorization spec: discovery (RFC 9728 and 8414), dynamic client registration, PKCE, resource indicators, automatic refresh, HTTPS only, tokens bound to the server URL and stored in the Keychain.
📊 Dashboard
Run McpHub dashboard (a one-time link opens your browser).
📚 Library
The Library tab of the dashboard is the official MCP Registry inside McpHub: search thousands of servers, read a trust score, click Add.
- Search runs locally. The first time you open the Library, McpHub downloads the catalog once in the background (the popular servers from the GitHub MCP Registry come first, in a few seconds; the full official catalog follows) into
~/.McpHub/registry-cache/. After that, it only fetches what changed, at most once a day. Search is instant and works offline. - Zero weight for your agent. The catalog lives in the dashboard and on disk. It adds no tool definition to the agent's context and nothing stays in memory between searches.
- Trust score before you install (0 to 100), with the detail of every point:
- verified publisher: the registry checks the namespace (a GitHub account or a DNS domain), McpHub checks that it publishes its own code;
- popularity and activity: GitHub stars, last update, archived repositories;
- permission scan: secrets requested, plain HTTP endpoints, privileged Docker options, bundle integrity hash, unpinned versions, and what the server can do (run commands, touch files, a browser, payments...).
- One-click add for every kind of server: remote (Streamable HTTP), npm (
npx), Python (uvx), Docker, .NET (dnx) and.mcpbbundles (downloaded, SHA-256 checked, extracted outside~/.McpHub). - Secrets go to the Keychain, never to
config.json. A secret you already have (GITHUB_TOKEN...) is reused. - Remote servers sign in with McpHub's native OAuth (one click on Sign in), tokens in the Keychain.
- New servers inherit every guard: shield sandbox for local code (Docker keeps its container), tool pinning and description scan on first contact, quarantine on change, audit log, permissions and profiles.
From the terminal: McpHub registry search postgres, McpHub registry info NAME, McpHub registry install NAME, McpHub registry sync.
Your agent installs what it needs
No new tool is added for this (about 30 tokens in total). When mcphub_search finds nothing, the agent can call:
The server is installed with the same guards, its tools are indexed right away, and the call is audited. An agent never handles secrets: when a server needs one, the agent asks you to finish in the dashboard. Control it in settings.registry:
agentInstall: "trusted" (default, only servers whose trust score reaches minTrust), "any" or "off".
🐧 Linux servers and sync
McpHub runs the same way on a Linux server, for example next to an agent running on a VPS:
- Sandbox with bubblewrap: same policy as on macOS. Every secret folder (
~/.ssh,~/.aws,~/.McpHub...) is replaced by an empty folder in memory, every secret file by an empty file;strictmode makes the whole system read-only except temporary folders, caches andallowWrite. - Secrets in
~/.McpHub/secrets.env, mode 600, hidden from sandboxed servers.McpHub vault set NAMEworks the same.
Move your setup from one machine to another without any plaintext secret:
The export is a portable config.json: every secret is a ${NAME} reference (plain values that look like tokens are taken out of the copy), and home paths become ${HOME}/.... With --secrets, the values travel too, encrypted with a passphrase (scrypt, then ChaCha20-Poly1305). Without the passphrase the file only reveals secret names. On import, servers whose program is missing on that machine are imported disabled, and decrypted secrets go to the Keychain (macOS) or secrets.env (Linux). For scripts, set MCPHUB_SYNC_PASSPHRASE.
⚙️ Configuration
Everything lives in ~/.McpHub/config.json and is hot-reloaded while the daemon runs.
Per-server options
Profiles per client
Profiles decide what each client may see and call: servers and excludeServers (globs), excludeTools ("server/tool" globs) and readOnly. Select one with http://127.0.0.1:24680/mcp/<profile>, /sse?profile=<profile>, or MCPHUB_PROFILE=<profile> in stdio mode.
Modes
discover(default): the agent seesmcphub_search,mcphub_callandmcphub_run.passthrough: every tool is exposed directly asserver__tool(full visibility, higher token cost).
🧰 CLI
Publishing a release (maintainers)
Bump version in Cargo.toml, merge, then push the tag vX.Y.Z (only admins can create v* tags). The Release workflow builds every binary, signs and notarizes the macOS ones, bundles the client, signs latest.json and publishes; the MCP Registry workflow then builds the Claude Desktop extension from .mcp/, attaches it and publishes to the MCP Registry. Its secrets live in the release environment, reachable only from v* tags; the signing key and the certificate are also kept in 1Password (scripts/ci-signing-secrets.sh refreshes the certificate when it is renewed).
Something wrong with a version already out?
Installations never go back to an older version: to undo a release, publish a fixed one with a higher number.
Files: ~/.McpHub/ (config, cache, pins, audit log, token; ~/.McpHub-<name>/ for a named instance) and ~/Library/Logs/McpHub/<server>.stderr.log (each server's error output).
❓ FAQ
Does it work with any MCP server?
Yes: any stdio server (command + args) and any Streamable HTTP server (url). Tool annotations, output schemas, paginated tool lists and protocol versions up to 2026-07-28 are relayed.
What happens when an editor restarts?
Nothing: the daemon keeps running, servers stay warm, and the editor reconnects to the same URL.
Will the sandbox break my servers?
shield only removes access to secrets and to a few programs that could escape it; regular servers keep working. Servers that need the whole machine (a shell tool like desktop-commander) are left outside by default, and any server can opt out with "sandbox": false.
Why does macOS ask for permissions after an update?
macOS remembers permissions per signing identity. make install signs with your Developer ID when available; the prebuilt binary is signed by SOFLUTION LTD. Ad-hoc builds get a new identity on every build, so macOS asks again.
How do I uninstall?
[McpHub logo]
MIT License · Made by SOFLUTION LTD
來源:README.md,提交 b521f25
工具
0版本歷史
3- v5.11.0最新Oct 31, 2026
- v5.10.0Oct 29, 2026
- v5.9.1Oct 26, 2026
評分
已滿足適用檢查項的 50%
該評分衡量此收錄條目的完整程度,依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價,也不表示伺服器安全或目前可用:可連通性是帶日期的檢查結果,評分也不包含安裝量或使用者評價。
- 近 30 天內可連通25 分
請保持端點能夠回應 MCP 握手;SourceWeft 每 30 天探測一次。
- 已宣告認證方式10 分
請在註冊中心條目中宣告憑證請求標頭,或保持端點能夠回應探測,以便判定其認證方式。
- 已列出工具15 分
請讓伺服器在無憑證時回應 tools/list,或發布可在沙箱中無憑證啟動的軟體包。
- 描述必需15 分
- 圖示10 分
- 文件15 分
- 授權條款10 分