# crabeye-mcp-bridge [Health: Active]

**Category:** 🔗 Aggregators  
**Repository:** https://github.com/crabeye-ai/crabeye-mcp-bridge  
**GitHub Stars:** 18  
**npm Downloads (last month):** 208  
**Views:** 1  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/crabeye-mcp-bridge

## Description
One MCP connection for all your tools — with discovery, namespacing, and execution policies.

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `npx` (confidence: high):

```json
"mcpServers": {
  "crabeye-mcp-bridge": {
    "command": "npx",
    "args": ["-y","@crabeye-ai/crabeye-mcp-bridge"]
  }
}
```

## Documentation

## What crabeye-mcp-bridge does

crabeye-mcp-bridge combines tools from multiple upstream MCP servers behind one MCP connection. Instead of presenting every upstream tool directly to the assistant, it exposes two bridge-level tools: `search_tools` for discovery and `run_tool` for execution.

The bridge discovers and indexes configured upstream tools when the assistant connects. Search results can then identify the relevant namespace and schema, allowing the assistant to run a selected tool without loading all available tool definitions into the context window at startup. This design is intended for environments where many connected servers would otherwise contribute a large number of tool schemas.

## How it works

The assistant connects to the bridge over STDIO. The bridge fans requests out to configured upstream MCP servers, which may communicate over STDIO, HTTP, or SSE. Namespaces distinguish tools that come from different upstream servers.

Search uses fuzzy matching to locate available tools. Execution is governed by policies that can apply globally, per server, or per tool. Each policy can allow execution automatically, require approval, or block the tool. Rate limiting is also available.

STDIO upstreams are routed through a per-user manager process. Multiple bridge instances can therefore share one subprocess for an upstream server.

## Setup and configuration

The quickest setup path is the `init` command:

```bash
npx @crabeye-ai/crabeye-mcp-bridge init
```

It looks for MCP client configuration from Claude Desktop, Cursor, VS Code Copilot, Windsurf, Zed, Cline, Roo Code, opencode, and Continue.dev. The command lets you choose configurations and can add the bridge entry automatically. opencode and Continue.dev are detection-only in this flow and receive a manual configuration snippet instead of an automatic rewrite. `restore` reverses changes made by initialization.

Manual configurations can place upstream definitions under `upstreamMcpServers`. The bridge also reads `upstreamServers`, `servers` for VS Code Copilot, and `context_servers` for Zed. Existing `mcpServers` entries can also be used when the bridge excludes its own entry. Supplying `--config` points the bridge at a specific configuration file.

Credentials can be stored with the CLI credential command and referenced in configuration using `${credential:key}` templates. HTTP upstreams can use the one-shot `auth <server>` OAuth flow. Claude Code can install the bridge through its marketplace and plugin commands.

## Tools and capabilities

- `search_tools`: searches the indexed tools exposed by configured upstream servers.
- `run_tool`: invokes a selected upstream tool through the bridge.
- Namespaces separate tools from different servers.
- Policies support `always`, `prompt`, and `never` behavior at global, server, or tool scope.
- The encrypted credential store uses an OS-keychain-backed master key.
- CLI commands include `init`, `restore`, `credential`, `daemon`, and `--validate`.

The bridge automatically excludes itself from discovered upstream configuration, preventing recursive self-registration when the same file is used for both settings and the bridge entry.

_Full upstream README: https://allmcps.com/mcp/crabeye-mcp-bridge/readme_