
Crabeye Mcp Bridge
io.github.crabeye-aiPublished by GitHub account crabeye-aiv1.3.0Updated Oct 24, 2026
One MCP connection for all your tools — with discovery, namespacing, and execution policies.
Overview
A local MCP bridge that consolidates all your upstream MCP servers behind one STDIO connection, exposing only search_tools and run_tool.
- What you can do
- Search and run tools across all configured upstream MCP servers through two meta-tools, search_tools and run_tool, instead of loading every tool schema into context
- Discover, namespace and index tools from STDIO, HTTP and SSE upstreams, with fuzzy search to find them on demand
- Apply per-tool, per-server or global execution policies (always, prompt, never) and rate limiting
- Store secrets in an encrypted credential store with an OS-keychain-backed master key and credential templates, plus a one-shot OAuth flow for HTTP upstreams
- Set up and undo configuration with a CLI that scans client configs and injects the bridge entry, and share one subprocess per STDIO upstream via a manager process
- When to use it
- Useful when you have several MCP servers and their combined tool definitions are bloating the context window, or when you want central control over which tools run freely, need approval, or are blocked. Also handy for keeping tokens in one encrypted store instead of hardcoded in client configs.
- Requirements
- Runs locally as a Node.js process via npx. Needs at least one upstream MCP server configured, either by running the init command to import existing client configs or by editing a config file with an upstreamMcpServers section. Desktop MCP clients only; no web execution.
Installation
In SourceWeft
- Open Crabeye Mcp Bridge in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
Crabeye MCP Bridge
One MCP connection for all your tools — with discovery, namespacing, and execution policies.
Every MCP server you add to your AI assistant means another connection, another set of tool definitions injected into the context window, and no way to search or control them centrally. Wire up ten servers with a hundred tools each and your assistant is burning tokens on a thousand tool schemas before the conversation even starts — most of which it will never call.
crabeye-mcp-bridge consolidates all your upstream MCP servers behind a single STDIO interface and exposes exactly two tools to the assistant: search_tools and run_tool. Tools from every server are discovered, namespaced, and indexed as soon as your assistant connects, but none of them touch the context window until the assistant actually searches for them. You can have a thousand tools ready to go without bloating the context, with fuzzy search to find them and per-tool execution policies to control what runs freely, what needs approval, and what is blocked.
Quick start
The fastest way to get started is with init, which discovers your MCP client configs and sets up the bridge automatically:
This scans for config files from Claude Desktop, Cursor, VS Code Copilot, Windsurf, Zed, Cline, Roo Code, opencode, and Continue.dev, lets you pick which ones to use, and optionally injects the bridge entry. After that, just run npx @crabeye-ai/crabeye-mcp-bridge — no --config flag needed.
opencode and Continue.dev are surfaced as detect-only: their config schemas don't fit the rename-and-inject pipeline, so init prints a manual snippet for them instead of rewriting the file.
To undo, run npx @crabeye-ai/crabeye-mcp-bridge restore.
Manual setup
If you prefer to set things up manually, say your MCP client config looks like this today:
First, store your secrets in the encrypted credential store:
Then rename mcpServers to upstreamMcpServers, add the bridge, and replace hardcoded tokens with ${credential:key} references:
That's it. Your AI assistant now has access to all tools from all configured servers through a single connection. The bridge automatically excludes itself from mcpServers to avoid recursion, so pointing --config at the same file is safe.
The bridge also reads upstreamServers (shorthand), servers (VS Code Copilot), and context_servers (Zed) as input keys. See docs/configuration.md for the full priority order and self-exclusion rules.
Alternatively, you can add the bridge alongside your existing mcpServers entries without renaming anything — the bridge will pick up the other servers from mcpServers automatically (excluding itself). Disable the other MCP servers in your client so the assistant uses the bridge as the single entry point.
Install as a Claude Code plugin
Register the bridge's repo as a Claude Code marketplace, then install the plugin:
Claude Code auto-registers the bridge as an MCP server. If you haven't configured upstreams yet, the bridge's startup error will surface in Claude Code's MCP server log — run npx @crabeye-ai/crabeye-mcp-bridge init in a terminal to discover and import existing MCP server configs from your other clients.
Features
- Discovery + search. Two meta-tools (
search_tools,run_tool) instead of N×M tool definitions in context. See docs/how-it-works.md. - Configuration. STDIO, HTTP, and SSE upstreams; categories; multi-source config keys. See docs/configuration.md.
- Authentication. Encrypted credential store, OS-keychain-backed master key,
${credential:key}templates, and a one-shotauth <server>OAuth flow for HTTP upstreams. See docs/auth.md. - Policies. Per-tool / per-server / global tool policies (
always/prompt/never), rate limiting. See docs/policies.md. - STDIO manager. STDIO, HTTP and SSE upstreams routed through a per-user manager process so multiple bridges share a single subprocess or connection per upstream. See docs/stdio-manager.md.
- CLI.
init,restore,credential,daemon,--validate. See docs/cli.md.
License
MIT
Source: README.md at commit b4268c2
Tools
0Version history
1- v1.3.0LatestSep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts