MCP's Context Tax and the Multiplexer Fix

How the Model Actually Uses It

You might wonder: does the model know to use these meta-tools? Yes. The multiplexer's instructions tell the model the protocol:

To use tools, first call list_servers or search_tools to discover what's available. Then call describe_tool to get the full schema for a specific tool. Finally call call_tool to execute it.

In practice the flow looks like:

1. Model calls search_tools("read file", limit=3) → gets 3 matching tools with full schemas
2. Model picks one, calls call_tool("filesystem", "read_file", {path: "..."})
3. Multiplexer proxies the call to the upstream filesystem server, returns result verbatim

This is 2–3 tool calls instead of 1, but the token cost of those 2–3 calls is tiny compared to loading 50 schemas upfront. The tradeoff is a discovery hop for a massive context saving.

Hybrid Mode: Expose Your Favorites

For servers you call every session, many times per session (e.g., Serena for code navigation, a database server you query constantly), the discovery hop is pure overhead. The multiplexer supports "expose": true on a per-server basis:

{
  "mcpServers": {
    "serena": {
      "command": "uvx",
      "args": ["serena", "start-mcp-server"],
      "expose": true
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"]
    }
  }
}

With expose: true, that server's tools mount directly as first-class server__tool tools (e.g., serena__find_symbol), schema and all, next to the meta-tools. The model calls them like any directly-connected tool — no search, no describe, no proxy hop. The server stays reachable through the meta-tools too, and allow/deny still apply.

Rule of thumb: multiplex the fleet, expose the favorites.

Governance and OAuth Built In

The multiplexer isn't just a token saver. It adds two features that matter for team and production use:

Allow/deny governance. Per-server allow (exact names or prefix* globs) and deny lists let you restrict what the model can see and call. deny always wins. This is a control plane for agent tool access without modifying upstream servers.

OAuth 2.1 brokering. Remote servers that speak the MCP authorization spec work with "oauth": true on a URL server. First use fails with an authorization URL; open it, approve; a temporary localhost listener completes the exchange. Tokens live in ~/.cache/mcp-multiplexer/tokens.json (mode 0600), refresh automatically, and survive restarts. The model can also drive this itself via the authorize_server meta-tool.

Claude Code Integration

The project is also a Claude Code plugin. Install it and it migrates your existing servers into a multiplexer config:

/plugin marketplace add JohGirard/mcp-multiplexer
/plugin install mcp-multiplexer@mcp-multiplexer

Then ask Claude to "set up mcp-multiplexer" (or run /mcp-multiplexer:setup). The plugin installs the binary, rewrites your config (secrets become ${VAR} references, OAuth servers get flagged), rewires your client config, and verifies.

With the plugin installed, /mcp-multiplexer:gain shows the token savings report in chat.

What It Doesn't Do (Non-Goals)

The README is explicit about non-goals, which is refreshing:

• MCP resources and prompts (tools only)
• Upstream sampling, elicitation, and roots
• No truncation of tool results — returned verbatim
• OAuth for URL servers only (stdio servers use env for secrets)
• No tools/list_changed notification forwarding — use refresh_tools

This scope discipline is why the binary is small, fast, and reliable.

Related Work

mcp-multiplexer isn't the only project attacking this problem. The pattern goes by several names:

• MCP gateways: Gate22, MetaMCP, Jetski, agiletec-inc/airis-mcp-gateway (60+ tools through 7 meta-tools)
• Lazy schema loading: Focused, OpenMCP, Ismael Ramos, ArXiv 2604.21816 ("Tool Attention Is All You Need")
• Filesystem-based discovery: Bifrost exposes tools as files; discovery becomes lazy
• Call batching: callmux batches multiple tool calls into one request (~19× context reduction)

Claude Code itself has started addressing this: recent versions defer MCP tool schemas by default and load on demand through tool search (Geotoolbox, wmedia.es). But the multiplexer approach works across all MCP clients (Cursor, Zed, custom clients) and adds governance/OAuth on top.

Should You Use It?

If you run 3+ MCP servers in Claude Code (or Cursor, Zed, etc.) and see context warnings, yes. The install is one binary, the config is your existing mcpServers with one wrapper, and the plugin handles migration. The token savings are measurable and immediate.

If you run 1–2 servers with few tools, the overhead of the discovery hop may not be worth it. But as your tool fleet grows, the multiplexer pattern becomes the default architecture — it's the difference between an agent that can think and an agent that's already out of context before it starts.

If this was useful, you can support my open-source work on Ko-fi or check out my services.