MCP Gateways & Proxies

Why Gateways?

As MCP deployments scale, connecting an AI Host directly to 50+ servers creates problems: token bloat (too many tool definitions), management complexity, and security gaps. MCP Gateways solve this by sitting between clients and servers.

Gateway Architecture

┌──────────┐     ┌──────────────┐     ┌──────────────┐
│ AI Host  │────▶│ MCP Gateway  │────▶│ MCP Server 1 │
│ (Claude) │     │ (Multiplexer)│────▶│ MCP Server 2 │
└──────────┘     └──────────────┘────▶│ MCP Server N │
                                      └──────────────┘

What Gateways Do

• Semantic Routing — Route tool calls to the right server based on meaning, not name
• Tool Aggregation — Present 500 tools from 50 servers as a unified catalog
• Token Optimization — Only inject relevant tool schemas into context, saving 80%+ tokens
• Observability — Central logging, metrics, and dashboards for all MCP traffic
• Rate Limiting — Prevent abuse and manage quotas across servers

The Tool Search Tool Pattern

An alternative to gateways is the Tool Search Tool (meta-tool) pattern: expose a single tool called find_tool that lets the LLM search for available tools by description. This avoids loading hundreds of tool schemas upfront.

// Instead of loading 500 tools into context:
server.tool("find_tool", "Search for tools by description",
  { query: z.string() },
  async ({ query }) => {
    const matches = semanticSearch(allTools, query, topK=5);
    return { content: [{ type: "text", text: JSON.stringify(matches) }] };
  }
);