Stop Rewriting MCP Ports: Bridging Local IDEs with MCPxHub

Local MCP setups usually fail in boring ways. The IDE is running, the plugin is installed, and Claude Desktop still cannot connect. You open the config file, squint at a port number, restart everything, and hope the next launch picks the same port.

MCPxHub exists for this one irritating layer: it keeps an MCP client connected to whatever local IDE MCP server is actually alive.

The Port Problem

IDE-side MCP servers often bind to local ports. VS Code-family tools might listen somewhere in the 9960-9990 range, and JetBrains integrations often live around 63342-63352.

That is fine until the port moves, the IDE restarts, or another process grabs the slot first. Then your MCP client has stale config.

The bad fix is to hardcode ports and keep editing JSON. It works once, but it does not hold up across machines, IDEs, or a workday where you open three projects and forget which one started first. MCPxHub finds the port by discovery instead.

Where MCPxHub Sits

MCPxHub sits between the client and the IDE-side server. It scans the expected local ranges, then proxies JSON-RPC calls to the live endpoint. The tools still come from your VS Code extension or JetBrains MCP plugin.

If your IDE plugin exposes file edits, terminal commands, Git status, or debugger actions, MCPxHub keeps the client pointed at that plugin. The tool boundary stays inside the editor integration.

Claude Desktop
      |
      | MCP over stdio
      v
   MCPxHub
      |
      | local JSON-RPC proxy
      v
IDE-side MCP server

The Config Can Stay Boring

The common setup is intentionally short:

{
  "mcpServers": {
    "MCPxHub": {
      "command": "npx",
      "args": ["-y", "@bugstan/mcpxhub"],
      "env": {
        "IDE_TYPE": "vscode"
      }
    }
  }
}

Set IDE_TYPE to vscode or jetbrains.

If you already know the endpoint, you can pass MCP_SERVER and MCP_SERVER_PORT. If not, let MCPxHub scan for it.

When the connection drops, the bridge polls more aggressively. When it is stable, it backs off.

Debugging The First Connection

The first failure usually comes from one of three places:

The IDE MCP plugin is not installed.
The IDE plugin is installed but not listening.
IDE_TYPE points at the wrong family.

Before you rewrite the config, check the IDE status bar and make sure the server is actually running. Then enable logs:

LOG_ENABLED=true

The logs show whether the bridge scanned the right range and whether it found a candidate endpoint.

Why This Matters For Multi-IDE Work

Many developers do not live in one editor anymore. You might have Cursor open for app code, VS Code attached to a remote folder, and a JetBrains IDE for a backend service. The MCP client should not care which local plugin won the port lottery.

MCPxHub gives you a stable client entry point while the IDE layer changes underneath. That helps Claude Desktop and any other MCP client that wants one local command instead of per-IDE hand wiring.

Use It With Workspace Boundaries

MCPxHub only handles discovery. What the agent is allowed to do is still your call.

If the IDE-side server exposes terminal commands or file edits, workspace trust still matters. Review what your editor plugin allows and keep dangerous actions behind explicit approval. Do not point an agent at a random folder just because the connection works.

The Practical Shape

Install the IDE plugin first. For VS Code-family editors, GG MCP for VS Code is one option. For JetBrains, use the appropriate IDE-side MCP server plugin.

Then start the bridge:

npx -y @bugstan/mcpxhub

If you are packaging it into Claude Desktop, keep the config stable and let the bridge handle the moving endpoint, so you stop editing JSON and chasing ports every time the IDE restarts.