Rakibul Yeasin

Posted on Nov 7

From Proxy to Powerhouse: How MCP Connect Became a Full-Featured Multiplexing Server

#rust #ai #mcp #devlife

Remember that Rust-based MCP proxy I built a while back? The one that was supposed to be a simple bridge between local clients and remote servers?

Yeah, well... it grew up.

What started as a weekend curiosity project has evolved into MCP Connect - a full-featured multiplexing server that does way more than just proxy requests.

And honestly? It's become way more useful than I ever expected.

What Changed? (Spoiler: Everything)

The original version was a simple proxy. Connect to one remote server, forward messages, done.

But then I realized: what if you need to connect to multiple servers at once?

And: what if you want to discover servers from a registry instead of manually configuring each one?

And: what if your IDE could just... automatically set everything up?

So I rebuilt it. Because apparently I hate myself. And without breaking the previous features. They are still there (really).

The New Architecture: Multiplexing Magic 🎭

MCP Connect is now a multiplexing server that acts as a single entry point to multiple MCP servers.

Think of it like a smart router for your MCP connections:

Local MCP Client
       ↓
  MCP Connect (Multiplexer)
       ↓
   ┌───┴───┬─────────┬──────────┐
   ↓       ↓         ↓          ↓
Server1 Server2  Server3   Server4
(GitHub) (Context7) (Custom) (Registry)

All through one connection. With namespace routing. And automatic configuration.

It's beautiful.

Features That Actually Matter

1. Centralized Configuration 📝

No more juggling multiple config files. Everything lives in one .mcp-connect.json:

{
  "version": "1.0",
  "envFile": ".env",
  "servers": {
    "github": {
      "name": "io.github.modelcontextprotocol/github-mcp-server",
      "remote": {
        "type": "streamable-http",
        "url": "https://api.githubcopilot.com/mcp",
        "headers": [
          {
            "key": "Authorization",
            "value": "Bearer ${GITHUB_TOKEN}"
          }
        ]
      }
    },
    "context7": {
      "name": "context7-mcp",
      "remote": {
        "type": "streamable-http",
        "url": "https://mcp.context7.com/mcp",
        "headers": [
          {
            "key": "Authorization",
            "value": "Bearer ${CONTEXT7_API_KEY}"
          }
        ]
      }
    }
  }
}

Environment variable substitution? Built-in. Multiple servers? Easy. Clean separation? You bet.

2. Registry Integration 🔍

Remember manually finding server URLs and figuring out authentication? Yeah, me neither.

# Search the official MCP Registry
mcp-connect registry search github

# Show server details
mcp-connect registry show io.github.modelcontextprotocol/github-mcp-server

# List all available servers
mcp-connect registry list

It's like npm search but for MCP servers. And it actually works.

3. Custom Registry Sources 🌐

The official registry is great, but what if you have internal servers? Or want to use a different registry?

# Add a custom registry
mcp-connect registry registry add \
  --name "internal" \
  --url "https://registry.company.com/api" \
  --api-version "v1"

# Set it as default
mcp-connect registry registry set-default internal

# Now all registry commands use your custom source
mcp-connect registry search my-server

Because sometimes you need to go off the beaten path.

4. IDE Integration 💻

The best feature? Your IDE just... works. Automatically.

# Generate Zed configuration
mcp-connect generate --ide zed

# Or VSCode
mcp-connect generate --ide vscode

# Or Cursor
mcp-connect generate --ide cursor

One command. Your IDE is configured. MCP Connect starts automatically. Magic.

No more manual JSON editing. No more "where do I put this config?" moments. Just... it works.

5. Namespace Routing 🗺️

When you have multiple servers, how do you distinguish between them?

MCP Connect uses namespace prefixes:

github/search_code          → GitHub server
context7/query              → Context7 server
custom/my_tool              → Custom server

All through one connection. All automatically routed. All transparent to your client.

The New Workflow (It's Actually Simple Now)

Step 1: Initialize

mcp-connect init

Creates your .mcp-connect.json with sensible defaults.

Step 2: Add Servers

Option A: From Registry

mcp-connect registry search github
mcp-connect registry show io.github.modelcontextprotocol/github-mcp-server
# Copy the config, add to .mcp-connect.json

Option B: Manual Configuration

# Edit .mcp-connect.json directly
# Or use your favorite editor

Step 3: Set Up Environment Variables

# .env file
GITHUB_TOKEN=ghp_your_token_here
CONTEXT7_API_KEY=ctx7sk_your_key_here

Step 4: Generate IDE Config

mcp-connect generate --ide zed

Step 5: Restart Your IDE

That's it. Everything works.

Real-World Example: Multi-Server Setup

Let's say you want to use:

GitHub MCP server (for code search)
Context7 MCP server (for embeddings)
A custom internal server

Before MCP Connect:

Configure each server separately in your IDE
Manage multiple config files
Hope they don't conflict
Debug connection issues one by one

With MCP Connect:

# 1. Initialize
mcp-connect init

# 2. Add servers to .mcp-connect.json
# (or use registry commands)

# 3. Set up .env with tokens

# 4. Generate IDE config
mcp-connect generate --ide zed

# 5. Done.

One connection. Multiple servers. Zero headaches.

The Technical Deep Dive (For the Curious)

Capability Aggregation

When multiple servers connect, MCP Connect aggregates their capabilities:

Tools: All tools from all servers, namespaced
Resources: All resources from all servers, namespaced
Logging: Unified logging from all servers
Instructions: Combined instructions from all servers

It's like having a super-server that knows everything.

Transport Flexibility

Each server can use a different transport:

HTTP/HTTPS for remote servers
STDIO for local processes
TCP for network services

MCP Connect handles the translation automatically.

Error Handling & Resilience

Automatic retries on connection failures
Graceful degradation (if one server fails, others keep working)
Detailed logging for debugging
Connection pooling and management

Because production is messy.

What I Learned (The Hard Way)

Multiplexing is harder than it looks - Aggregating capabilities, routing requests, managing state... it's not trivial.
Configuration management matters - A good config system makes or breaks developer experience.
IDE integration is worth the effort - One command that "just works" is worth 100 lines of documentation.
Rust's type system is your friend - Once you stop fighting it, it prevents so many bugs.
Building in public is terrifying - But also motivating. And the feedback is invaluable.

The Numbers

7 modular crates (because separation of concerns)
Full MCP 2024-11-05 spec compliance
3 IDE integrations (Zed, VSCode, Cursor)
Registry support (official + custom)
Multiple transport protocols (HTTP, STDIO, TCP)
Zero runtime dependencies (static binaries)

And it's still fast. Because Rust.

Try It Yourself

# Install from source
git clone https://github.com/dreygur/mcp-connect.git
cd mcp-connect
cargo build --release

# Or use the install script
curl -fsSL https://raw.githubusercontent.com/dreygur/mcp-connect/main/install.sh | bash

# Quick start
mcp-connect init
mcp-connect generate --ide zed
# Restart Zed. Done.

Final Thoughts

Was this necessary? Probably not.

Was it worth it? Absolutely.

Because sometimes the best projects aren't the ones that solve a problem - they're the ones that make you realize the problem was harder than you thought, and then you solve it anyway.

MCP Connect went from "simple proxy" to "full-featured multiplexing server" because that's what it needed to be.

And honestly? I'm pretty proud of it.

🦀 Source: GitHub - MCP Connect
📚 Docs: Full Documentation
🐛 Issues: Report Bugs

P.S. - If you're using MCP servers and juggling multiple configs, give MCP Connect a try. It might just make your life easier.

DEV Community