jitorun.ai

Appearance

2026-03-12

从 Cursor MCP 到 ChatGPT Atlas：为什么我们需要写一个 MCP Server

在公司内部，我们已经有一套MCP（Model Context Protocol）工具（蔡总的kms-mcp），主要是给开发者在Cursor里使用的，但当我尝试让ChatGPT Atlas也调用这些工具时，发现事情没有想象中那么简单，因此写一篇文档记录一下。

这篇文章总结一下这个过程：

  • MCP 是什么
  • MCP 的 stdio 模式是怎么工作的
  • 为什么现有的 MCP 不能直接给 Atlas 用
  • 为什么我们最后需要写一个 MCP Server / Gateway

一、什么是 MCP ​

MCP（Model Context Protocol） 是 Anthropic 提出的一个协议，用来让 LLM 调用外部工具、数据源或服务。

它的核心思想其实很简单：

让 AI 通过统一协议访问工具，而不是为每个 AI 写一套独立的 API 集成。

整体架构通常是这样的：

LLM Host (Cursor / Claude / ChatGPT)
          │
          │ MCP protocol
          ▼
      MCP Server
          │
          ▼
  Tools / APIs / Databases

在这个架构里：

  • Host：运行 LLM 的客户端
    • Cursor
    • Claude Desktop
    • ChatGPT Atlas
  • Server：提供工具能力
    • GitHub
    • Database
    • 内部系统
    • DevOps 工具

Server 会声明自己提供的：

  • tools
  • resources
  • prompts

LLM 就可以通过 MCP 调用这些能力。

二、MCP 的 stdio 模式 ​

在开发 MCP Server 时，最常见的 transport 是 stdio。

所谓 stdio，就是通过：

  • stdin
  • stdout

来进行 JSON-RPC 通信。

一个典型的流程是：

Cursor
  │
  │ JSON-RPC
  ▼
stdin / stdout
  ▼
MCP server process

例如：

cursor
   │
   │ spawn process
   ▼
node my-mcp-server.js
   │
   ├─ stdin  ← request
   └─ stdout → response

这种方式的优点：

  • 非常简单
  • 不需要网络
  • 本地开发体验好
  • 进程生命周期由 host 控制

这也是为什么很多 Cursor MCP 插件都是 stdio。

三、为什么 stdio MCP 不能直接给 Atlas 用 ​

问题在这里。

Cursor 使用 MCP 的方式是：

Cursor
   │
   │ spawn local process
   ▼
stdio MCP server

但 ChatGPT / Atlas 不是这样工作的。

Atlas 是一个 远程 LLM host，它通常只能访问：

  • HTTP
  • HTTPS
  • SSE

也就是说：

Atlas
   │
   ▼
Remote MCP server

而不是：

Atlas
   │
   ▼
spawn 本地进程

所以：

一个只支持 stdio 的 MCP server，Atlas 是连不上的。

四、MCP 的 Host 和 Server 是不同角色 ​

理解 MCP 的关键是这一点：

Cursor = MCP host
Atlas  = MCP host

而我们写的工具其实是：

MCP server

所以真实的结构应该是：

Cursor ─┐
        │
        ▼
     MCP server
        ▲
        │
Atlas ──┘

而不是：

Cursor → Atlas

很多人第一次接触 MCP 都会误以为：

Cursor 的 MCP 可以直接给别的 AI 用。

其实不是。

五、我的问题 ​

公司内部已经有一套 stdio MCP，例如：

  • 查询内部文档
  • other

它原本是给 Cursor 用的：

Cursor
   │
stdio
   ▼
internal MCP tools

但现在我们希望：

Atlas
   │
   ▼
这些工具

问题来了：

Atlas 无法直接运行本地进程。

六、解决方案：写一个 MCP Server / Gateway ​

最常见的解决办法就是：

在 stdio MCP 外面加一层 Gateway

架构如下：

ChatGPT Atlas
        │
        │ HTTPS
        ▼
   MCP Gateway
        │
        │ local process
        ▼
   stdio MCP server
        │
        ▼
 internal systems

这个 Gateway 做的事情：

  1. 提供 远程 MCP endpoint
  2. 处理认证
  3. 校验工具参数
  4. 管理 stdio 进程
  5. 转发请求

换句话说：

HTTP MCP
   ↓
stdio MCP

七、为什么不直接改写 MCP ​

理论上我们可以把现有 MCP 改成：

Remote MCP server

也就是：

HTTP / Streamable HTTP

这样 Atlas 就可以直接调用它。

但在实际工程中，这并不是一个理想方案，原因不仅仅是“改造成本高”。

更重要的是 扩展性和维护成本的问题。

1. 每个 MCP 都需要重复改造 ​

如果公司只有一个 MCP server，那么直接改写问题不大。

但在实际情况中，我们往往会有很多 MCP，例如：

  • docs-mcp
  • git-mcp
  • ci-mcp
  • ticket-mcp
  • 内部工具 mcp

如果选择逐个改造，每个 MCP 都需要：

  • 支持 HTTP transport
  • 增加认证逻辑
  • 增加日志
  • 增加部署能力
  • 适配 Atlas

这意味着：

N 个 MCP
→ N 次改造
→ N 份维护成本

而如果使用 Gateway，则变成：

N 个 stdio MCP
→ 1 个 Gateway
→ 后续只需要改配置

接入一个新的 MCP 只需要：

  • 配置启动命令
  • 注册一个 route
  • 配置权限

而不需要重新开发 server。

2. 把“协议适配”从业务逻辑中剥离 ​

现有 MCP server 的职责其实很简单：

  • 提供工具能力
  • 访问内部系统
  • 返回结果

但如果为了 Atlas 接入，把每个 MCP 都改造成 remote server，就意味着每个 MCP 都需要处理：

  • HTTP server
  • transport 协议
  • 认证
  • 日志
  • 限流
  • 错误处理

这些其实不是业务逻辑，而是平台接入逻辑。

更合理的做法是：

把这些能力统一放在 Gateway 层。

这样 MCP server 只需要专注于：

提供工具能力

而不需要关心：

如何被不同 AI 平台接入

3. 接入新 MCP 变成配置问题 ​

有了 Gateway 之后，接入一个新的 MCP 往往只需要增加配置，例如：

docs-mcp   -> node docs-server.js
git-mcp    -> python git_server.py
ci-mcp     -> ./ci-mcp

也就是说：

接入新 MCP 从“开发任务”变成了“配置任务”。

这对于团队协作非常重要，因为：

  • 平台团队维护 Gateway
  • 业务团队只维护自己的 MCP
  • 两者职责清晰

4. 网关可以统一处理治理能力 ​

如果没有 Gateway，这些能力通常要每个 MCP 自己实现：

  • 身份认证
  • 权限控制
  • 审计日志
  • 限流
  • 超时
  • 监控

但有了 Gateway，可以统一在入口层处理。

这样 Atlas 接入任何 MCP，都经过同一套治理能力。

换句话说：

Gateway 不只是一个协议桥接器，它也是一个统一治理层。

5. 更容易支持多个 AI Host ​

今天接入的是 Atlas，未来可能还会有：

  • Claude Desktop
  • 内部 Agent 平台
  • 公司自己的 AI 助手

如果逐个改写 MCP，那么每来一个新的 Host，都可能需要重新适配。

而如果有 Gateway，大部分变化都收敛在 Gateway 层。

业务 MCP 不需要感知这些变化。

hhh，以上都是废话，实际上是我自己想玩一下

然后大概研究了一下，网上还是有一些开源框架的

在调研 MCP Gateway 方案时，我发现社区已经出现了多种形态的 MCP infrastructure，例如 Supergateway（stdio bridge）、MCP Bridge（proxy）、以及 ContextForge / Obot 这类 MCP control plane。不同方案解决的问题不同，而在我的场景中，只需要把已有 stdio MCP 暴露为远程 endpoint，因此选择了最轻量的 Supergateway。

https://github.com/supercorp-ai/supergateway?utm_source=chatgpt.com

它的核心功能就是：

Remote MCP
   ↓
stdio MCP

也就是说，它会帮你：

  1. 启动 MCP server
  2. 用 stdio 和 server 通信
  3. 对外暴露 MCP endpoint

整个过程基本不需要改原来的 MCP。

八、部署 Supergateway ​

假设我们原来的 MCP server 是：

kms-mcp

本质上就是一个 stdio server，比如：

node kms-mcp.js

安装 ​

最简单的方式是直接用 npx：

npx supergateway

或者安装到全局：

npm install-g supergateway

启动 gateway ​

启动一个 gateway，把 stdio MCP 暴露出来：

npx supergateway \
--stdio"xxx" \
--port 8000

参数含义：

  • -stdio

    指定启动 MCP server 的命令

  • -port

    gateway 对外暴露的端口

启动后会得到一个 endpoint：

http://localhost:8000

此时 gateway 会：

HTTP request
   ↓
Supergateway
   ↓
stdio
   ↓
kms-mcp

然后再加个内网穿透，配个auth就行了

企业微信截图_79ae9a32-5d52-4ce0-942a-b84e029a207d.png

image.png

image.png

算是验证了个小玩具吧hhh

最后更新于: