起因

今天上午刷到了 One MCP 发布新功能 - 用 Skill 替代 MCP，省下 80% 的 Context 开销 ，奈何该工具需要 docker，而我又没有 docker，遂造轮之。

叠甲：我是不会告诉你们我今天晚上搜 gateway 在 npm 上发现了很多同类工具。所以请不要说我重复造轮子，我只是看了帖子上头了手搓了几个小时搓出来的

技术细节

该 mcp 服务提供了 3 个工具以隐藏 mcp 服务。

1. 获取全部的 MCP 服务以及其下属的工具摘要。

   放心，它只会返回 MCP 服务的名字以及下属的全部工具名称以及经过处理的描述。
   不会占用太多上下文。

2. 批量获取 MCP 服务及其下属工具
   该工具会返回要查询的全部 MCP 服务以及其下属工具的名称，描述以及调用参数约定

3. 通过 MCP 服务名称和工具名称调用具体工具

安装

首先，确保您使用 NodeJS v16 及以上版本。

npm install -g @kagg886/mcp-gateway@latest

其次，打开您的 AI 工具，编辑 MCP 文件，进行配置：

{ "mcpServers": { "mcp-gateway": { "isActive": true, "name": "mcp-gateway", "type": "stdio", "command": "mcp-gateway", "args": [ "-f", "/path/to/your/json" ], "installSource": "unknown" } } } 

/path/to/your/json 的配置如下：

{ "mcpServers": { "chrome-devtools": { "command": "npx", "args": [ "-y", "chrome-devtools-mcp@latest" ] }, "mcp-server-time": { "command": "uvx", "args": [ "mcp-server-time", "--local-timezone=Asia/Shanghai" ], "alwaysAllow": [ "get_current_time", "convert_time" ] }, "context7": { "command": "npx", "args": [ "-y", "@upstash/context7-mcp@latest" ], "alwaysAllow": [ "resolve-library-id", "query-docs" ], "disabled": true } } } 

最后，在 AI 工具中进行测试：

优点

• 不需要安装 docker (除了我之外还有谁没安装 docker 呢)
• 配置超级简单，只需要传递配置路径或配置字符串 (使用 -s 参数)
• 无 web-ui，私认为这种工具不需要可视化配置，完全可以通过参数来隔离实例。

缺陷

虽然我在几个小时内匆忙地写完了这个工具，但是综合看来，还是有很多功能没有做，例如：

• 现版本只能代理基于 STDIO 的 MCP 服务

• 将部分 MCP 调用错误标记为 error，以供 Agent 识别

• 尽管我在 MCP 服务的 description 中给 Agent 添加了足够的提示。
  但是在能力有限的模型中，可能不会调用代理工具查询可用的 Agent。
  此时需要您手动在聊天框或 prompt 中显式告知 AI 可用工具

• 尽管配置了并发启动，但启动速度很明显受木桶效应影响。

开发计划

大概有人用我才会更新，否则我会基于我自己的需求迭代这个工具 (x

未来可能会增加以下功能：

1. 异步启动 (而不是在程序启动阶段就初始化所有服务)
2. 数据缓存 (缓存调用规范以避免频繁启动)
3. 自动清理 (长时间不调用的 mcp 会自动关闭) 功能。
4. 代理基于 SSE 的 MCP 服务

我将永远不会制作以下功能：

1. 可视化 web 页面

注意事项

• 最好不要代理影响 LLM 行为的 MCP 服务，如 sequential-thinking

• 最佳实践是代理专业性较强，或者不常使用的 MCP 服务，如 chrome-devtools，github。

开源地址

mcp-gateway 使用 MIT 协议发布。源码地址为：GitHub - magic-cucumber/mcp-gateway: an gateway to manage tools, keeping context clean and focused.

写在最后

如果您喜欢这个重复的轮子，以及有建议，还请留言 / 收藏 / 标星，或者在原仓库提 issue (仅接受英文 issue，不过在这里反馈的话可以写中文)！

大家好！

如果你在使用 Claude Code、Cursor 时配置了多个 MCP 服务，你一定能感受到上下文（Context）窗口的压力。

痛点：被工具定义吃掉的 Context

Anthropic 官方曾在 Advanced Tool Use
技术博客中披露过工具定义的开销数据：
・GitHub: 35 个工具占用约 26,000 tokens
・Slack: 11 个工具占用约 21,000 tokens

这意味着，如果你同时开启这两个 MCP 服务，还没开始对话，近 50,000 tokens 就已经消失了。这不仅让 API 成本激增，更会导致 AI 的推理能力因为背景噪声过多而下降，甚至出现指令遵循失败。

──────────────────────────────────────────

One MCP v1.0.1：两种方案帮你「减负」

One MCP 新版本增加了 服务组合 (Combo) 功能

针对不同场景提供两种瘦身方案：

方案一：导出为 Anthropic Skill (推荐)

Anthropic 近期将 Skill 定为开放标准，旨在解决大规模工具定义的开销问题。我也在 OpenCode 和 Droid 上完成了实测，效果非常理想。

・极低开销：AI 只读取一个精简的 SKILL.md（~500 tokens），替代数万 tokens 的 JSON 定义。
・按需加载：工具详情只有在 AI 决定调用时才会被实时读取，完美适配 Anthropic 的官方实践。
・零依赖：导出的 Python 执行器仅使用标准库，不需安装任何包，开箱即用。
・广泛适配：完美支持 Claude Code / Droid / OpenCode 等支持 Skill 协议的客户端。

方案二：精简版组合 MCP (适用于传统客户端)

如果你的软件尚未支持 Skill 协议，你可以将 N 个服务组合成一个统一端点：

・精简工具：Context 里只暴露 search_tools 和 execute_tool。
・动态调用：无论后台有多少工具，AI 的初始上下文里永远只有这两个入口。

──────────────────────────────────────────

性能实测

以我测试的一个包含 4 个服务（24 个工具）的组合为例：
・原生 MCP 模式：占用约 12,000+ tokens。
・One MCP Skill 模式：仅占用约 800 tokens。

Context 节省率达 93%！ 把宝贵的 Context 留给代码和真正的逻辑。

──────────────────────────────────────────
实战案例

• 1. 使用 Skill（工具：OpenCode）

这个例子，我创建了一个 cherry-studio 工具的组合，包含 exa,amap,whois 等 4 个 mcp, 导出 skill，再解压到 opencode 的 skill 目录

最终 LLM 按照 skill.md 的说明，使用 python 脚本调用了合适的 mcp 工具

• 2. 使用组合后的 MCP（工具：Cherry Studio）

一开始只占用 1000 个 token，然后查询时，这里会多调用一次查找合适的工具和参数

──────────────────────────────────────────

快速体验

1. Docker 一键启动：

docker run --name one-mcp -d \
-p 3000:3000 \
-v $(pwd)/data:/data \
buru2020/one-mcp:latest

# Access the application
open http://localhost:3000
# Default username/password
root/123456

2. 在后台安装所需的 MCP 服务，创建一个「服务组合」。
3. 导出 Skill：点击导出 zip 包，解压到对应的 Skill 目录即可使用。

──────────────────────────────────────────
也可以登录我的 demo 站点创建 skill 体验：
Demo: https://demo.one-mcp.com/

项目地址

GitHub: https://github.com/burugo/one-mcp

欢迎 Star 和试用，让我们一起终结 MCP 的 Context 焦虑！如果有使用上的问题，欢迎在评论区讨论。