MCP Gateway
Serves as a lazy-loading proxy for multiple MCP servers to prevent tool schema bloat and reduce context token usage. Exposes 4 lightweight gateway tools that start backend servers on demand rather than loading all schemas at startup.
README
MCP Gateway
A lazy-loading proxy that sits between Claude and your MCP servers. Instead of loading every server at startup (which dumps hundreds of tool schemas into context and burns tokens), the gateway exposes just 4 lightweight tools. Backend servers only start when you actually need them.
Before: 10 MCP servers = 200+ tool schemas loaded into every conversation = thousands of wasted tokens.
After: 10 MCP servers behind the gateway = 4 tool schemas loaded. Each server starts on demand.
The Problem
Every MCP server you add to Claude Code registers all its tools upfront. A typical server has 10-30 tools, each with a full JSON schema. With 10 servers that's 100-300 tool definitions eating your context window before you even ask a question.
Most conversations only use 1-2 servers. The rest are dead weight.
How It Works
The gateway exposes 4 tools to Claude:
| Tool | What it does |
|---|---|
gateway_list_servers |
Shows available servers and their status |
gateway_load_server |
Connects to a server and discovers its tools |
gateway_call_tool |
Calls a tool on a connected server |
gateway_reload_server |
Reconnects a server (picks up code changes) |
When Claude needs a server, it calls gateway_load_server. The gateway starts the subprocess, does the MCP handshake, and caches the connection. Subsequent calls reuse the running process.
Servers that aren't used never start. No tokens wasted.
Quick Start
git clone https://github.com/raiansar/mcp-gateway.git
cd mcp-gateway
./install.sh
Edit config.json to add your servers, then add the gateway to Claude Code:
claude mcp add gateway -- /path/to/mcp-gateway/run.sh
That's it. All your servers are now behind a single gateway.
Configuration
config.json is a simple map of server names to their connection details. The gateway supports both stdio (local processes) and HTTP (remote servers) transports.
Stdio Servers (local)
{
"servers": {
"my-server": {
"type": "stdio",
"command": "npx",
"args": ["-y", "some-mcp-server@latest"],
"env": {
"API_KEY": "your-key"
},
"timeout": 30,
"description": "What this server does"
}
}
}
HTTP Servers (remote)
{
"servers": {
"remote-server": {
"type": "http",
"url": "https://mcp.example.com/mcp",
"headers": {
"Authorization": "Bearer your-token"
},
"timeout": 60,
"description": "Remote MCP server"
}
}
}
Python Servers (uv)
{
"servers": {
"my-python-server": {
"type": "stdio",
"command": "uv",
"args": ["run", "--directory", "/path/to/server", "server-name"],
"env": {},
"timeout": 120,
"description": "Python server managed by uv"
}
}
}
Config Fields
| Field | Required | Default | Description |
|---|---|---|---|
type |
No | stdio |
Transport: stdio, http, sse, or streamable-http |
command |
Yes (stdio) | - | Command to run the server |
args |
No | [] |
Command arguments |
env |
No | {} |
Environment variables |
url |
Yes (http) | - | Server URL |
headers |
No | {} |
HTTP headers (auth tokens, etc.) |
timeout |
No | 30/60 | Request timeout in seconds (30 for stdio, 60 for http) |
description |
No | - | Human-readable description shown in gateway_list_servers |
Migrating Your Existing MCP Servers
If you already have MCP servers configured in Claude Code, move them to the gateway:
Before (in ~/.claude.json or Claude Desktop config):
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxx" }
},
"tavily": {
"command": "npx",
"args": ["-y", "tavily-mcp@latest"],
"env": { "TAVILY_API_KEY": "tvly-xxx" }
},
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/home/user"],
"env": {}
}
}
}
After (in config.json):
{
"servers": {
"github": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxx" },
"description": "GitHub - repos, issues, PRs, code search"
},
"tavily": {
"type": "stdio",
"command": "npx",
"args": ["-y", "tavily-mcp@latest"],
"env": { "TAVILY_API_KEY": "tvly-xxx" },
"description": "Tavily AI search"
},
"filesystem": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/home/user"],
"env": {},
"description": "File system access"
}
}
}
Then remove the individual servers from Claude and add just the gateway:
claude mcp remove github -s user
claude mcp remove tavily -s user
claude mcp remove filesystem -s user
claude mcp add gateway -- /path/to/mcp-gateway/run.sh
Usage
Once configured, Claude automatically uses the gateway. A typical interaction:
- Claude calls
gateway_list_serversto see what's available - Claude calls
gateway_load_server("github")when it needs GitHub - Claude calls
gateway_call_tool("github", "search_repositories", '{"query": "mcp"}')to use a tool - The GitHub server stays running for subsequent calls in the same session
The description field in your config helps Claude decide which server to load for a given task, so write good descriptions.
How This Differs from RTK
RTK is a CLI proxy that compresses shell command output (git, ls, test runners, etc.) to reduce token consumption by 60-90%.
MCP Gateway solves a different problem: it prevents MCP tool schema bloat by lazy-loading servers on demand instead of registering all tools upfront.
| MCP Gateway | RTK | |
|---|---|---|
| Problem | Tool schemas from idle MCP servers waste context | Verbose CLI output wastes context |
| How | Lazy-loads servers, exposes 4 proxy tools | Compresses command output before it hits context |
| When | Startup / tool registration | Runtime / command execution |
| Scope | MCP server management | Shell commands (git, npm, cargo, etc.) |
They're complementary. Use both for maximum token savings.
Requirements
- Python 3.10+
mcppackage (installed byinstall.sh)
License
MIT
推荐服务器
Baidu Map
百度地图核心API现已全面兼容MCP协议,是国内首家兼容MCP协议的地图服务商。
Playwright MCP Server
一个模型上下文协议服务器,它使大型语言模型能够通过结构化的可访问性快照与网页进行交互,而无需视觉模型或屏幕截图。
Magic Component Platform (MCP)
一个由人工智能驱动的工具,可以从自然语言描述生成现代化的用户界面组件,并与流行的集成开发环境(IDE)集成,从而简化用户界面开发流程。
Audiense Insights MCP Server
通过模型上下文协议启用与 Audiense Insights 账户的交互,从而促进营销洞察和受众数据的提取和分析,包括人口统计信息、行为和影响者互动。
VeyraX
一个单一的 MCP 工具,连接你所有喜爱的工具:Gmail、日历以及其他 40 多个工具。
Kagi MCP Server
一个 MCP 服务器,集成了 Kagi 搜索功能和 Claude AI,使 Claude 能够在回答需要最新信息的问题时执行实时网络搜索。
graphlit-mcp-server
模型上下文协议 (MCP) 服务器实现了 MCP 客户端与 Graphlit 服务之间的集成。 除了网络爬取之外,还可以将任何内容(从 Slack 到 Gmail 再到播客订阅源)导入到 Graphlit 项目中,然后从 MCP 客户端检索相关内容。
e2b-mcp-server
使用 MCP 通过 e2b 运行代码。
Neon MCP Server
用于与 Neon 管理 API 和数据库交互的 MCP 服务器
Exa MCP Server
模型上下文协议(MCP)服务器允许像 Claude 这样的 AI 助手使用 Exa AI 搜索 API 进行网络搜索。这种设置允许 AI 模型以安全和受控的方式获取实时的网络信息。