How to aggregate MCP servers with a personal hub

If you use more than one AI coding tool, you've felt this pain. An MCP hub solves it by making you configure each server exactly once.

The problem: MCP configuration is per-tool

The Model Context Protocol is great at what it does — it lets any AI agent call any tool as long as they speak the protocol. But the configuration model assumes each AI client manages its own list of servers.

In practice, if you use a filesystem MCP server, a database MCP server, a web scraper MCP server, and a screenshot MCP server across four different AI coding tools, you end up with this:

• Four copies in Claude Code — in ~/.claude.json for user- and local-scoped servers, or in a per-project .mcp.json.
• Four copies in Cursor's settings.
• Four copies in Claude Desktop's claude_desktop_config.json.
• Four copies in Windsurf.

Sixteen entries total, all hand-maintained. When one of those servers updates its API key or args, you have four places to fix.

What a personal MCP hub does

A personal MCP hub is itself an MCP server — but instead of exposing its own tools, it aggregates the tools of other MCP servers and re-exposes them behind one endpoint. You configure all your upstream servers in the hub, then point each AI tool at the hub.

From the AI tool's perspective, it's connected to exactly one MCP server. From your perspective, you have one place to add, remove, or reconfigure servers.

How AppContext's MCP Hub works

AppContext's built-in MCP Hub is a free feature that ships with the core app. Here's how it's structured:

Upstream connections

You register upstream MCP servers in ~/.appcontext/servers.json or via the Servers tab in the app window. Each entry has a transport:

• stdio — AppContext spawns a local command (e.g. npx -y @modelcontextprotocol/server-filesystem /tmp) and talks to it over stdin/stdout. This is the standard way to run local MCP servers.
• SSE — AppContext connects to a remote MCP server over HTTP Server-Sent Events, useful for hosted MCP services that expose an SSE endpoint.

Most local MCP servers are stdio, which is still one of the two standard transports in the current MCP specification (revision 2026-07-28); the other is Streamable HTTP. AppContext connects to remote upstreams over SSE, and it serves its own endpoint at http://localhost:7777/sse over SSE as well — a transport Claude Code and Cursor still support, and which Claude Code now labels deprecated in favour of HTTP where a server offers both.

Tool aggregation with namespacing

When an upstream server exposes a tool like read_file, AppContext re-exposes it as filesystem:read_file (using the server name as a prefix). This avoids collisions when multiple upstream servers define tools with the same name.

When your AI agent calls filesystem:read_file, AppContext routes the call to the right upstream server, waits for the response, and returns it. The AI doesn't know or care that there's a hub in the middle.

Crash recovery

If an upstream server crashes (stdio server segfaults, SSE connection drops), AppContext reconnects automatically with exponential backoff. When it's back, AppContext emits an MCP tools/list_changed notification so connected AI clients refresh their tool list.

One-click import

If you already have MCP servers configured in Claude Code, Cursor, or Claude Desktop, AppContext can import them in a single click from the Servers tab — no hand-editing of JSON.

Setting up the hub

1. Install AppContext

Download from appcontext.dev, install to /Applications, sign in.

2. Add your upstream servers

Open the app window, go to Servers, and either:

• Click Import to pull in servers from Claude Code, Cursor, or Claude Desktop.
• Click Add Server and fill in the transport + command or URL.

3. Point your AI tools at AppContext

Add AppContext as the only MCP server in each of your AI tools:

{
  "mcpServers": {
    "appcontext": {
      "url": "http://localhost:7777/sse",
      "type": "sse"
    }
  }
}

Your AI tools now have access to every MCP server you added to AppContext, plus AppContext's own visual-context tools.

Inspecting the hub

Three built-in tools give you programmatic visibility:

• hub_status — returns the list of upstream servers, their connection state, and the tools each one is currently exposing.
• hub_call — explicitly calls a tool on a specific upstream server. Useful for debugging.
• hub_policies — views and changes the authorization policies described in the AuthZ guide, so an agent can report which tools are currently blocked without you opening the app window.

You can ask any connected AI agent "what's in my MCP hub?" and it will call hub_status for you.

Why the hub is free

Running the hub itself costs AppContext nothing — it's local process orchestration on your machine. The Pro tier on AppContext gates the visual-context features (Live View, Metro log streaming, advanced policies), not hub aggregation. The hub is valuable on its own, and we don't want to put a paywall in front of the core "configure once, use everywhere" workflow.

What comes next

An MCP hub is the natural place to enforce authorization. Because every tool call from every AI agent routes through the hub, you have one chokepoint to say "this tool is off-limits" or "this tool can only be called 5 times per minute." That's covered in the AuthZ for MCP servers guide.

Frequently asked questions

What is a personal MCP hub?

A personal MCP hub is itself an MCP server that aggregates the tools of other MCP servers and re-exposes them behind a single endpoint. You register your upstream servers once in the hub, then point every AI coding tool at the hub instead of maintaining a separate server list per tool.

How does a hub avoid tool name collisions between servers?

AppContext namespaces every proxied tool with its server name, so a read_file tool from a server named filesystem is re-exposed as filesystem:read_file. Calls are routed back to the originating upstream server.

Is the MCP Hub free?

Yes. Aggregating servers, importing them from Claude Code, Cursor, or Claude Desktop, and starting or stopping them are all free. AppContext's Pro tier covers the visual-context features — Live View screenshots, browser console and Metro logs — and the advanced authorization controls.