我们为什么要做 MCPSDK
不是一篇产品发布稿。我们只是想聊聊为什么要做这个东西，以及它可能对你有什么用。
一个反复出现的问题
我们团队过去一年一直在做 AI Agent 相关的项目。每次开始一个新项目，都会遇到同一个问题：MCP Server 的接入。
MCP 本身是个很棒的协议。它让 AI 能够调用外部工具，这是 Agent 能真正"做事"的关键。但每次接入一个新的 MCP Server，流程都差不多：
- 找到 Server 的 repo
- 读文档，搞清楚怎么配置
- 写 config 文件
- 设置环境变量
- 可能还要起个 Docker
- 处理权限问题
- 祈祷它能跑起来
一个 Server 还好。但当你的 Agent 需要同时调用 GitHub、Slack、日历、邮件、数据库……这个过程就变得很痛苦。
我们最初的解决方案
最开始，我们只是写了一些内部脚本来简化这个流程。后来发现，这些脚本越写越多，逐渐变成了一个小型的 SDK。
核心想法很简单：能不能把"接入一个 MCP Server"这件事，简化到一行代码？
const github = await mcpsdk.connect('github');
不需要写配置文件，不需要管理 Docker，不需要处理权限。你只需要告诉它你要用哪个 Server，剩下的它来处理。
它是怎么工作的
技术上，MCPSDK 做了几件事：
-
统一的 Registry：我们聚合了多个 MCP Server 源（官方的、社区的、第三方的），目前大概有 5000+ 个可用的 Server。
-
云端沙箱执行：Server 不在你本地跑，而是在我们基于 Sandock.ai 构建的安全沙箱里运行。这解决了权限和安全隔离的问题。
-
标准化的接口：不管底层 Server 是用什么语言写的、怎么配置的，对你来说调用方式都一样。
这不是银弹
说实话，这个方案有它的局限性：
- 延迟：云端执行意味着网络往返，对延迟敏感的场景可能不适合
- 成本：沙箱运行是有成本的，高频调用需要考虑这一点
- 定制化：如果你需要深度定制某个 Server 的行为，直接本地部署可能更灵活
我们不是要取代本地部署的方式，而是提供一个"快速开始"的选项。当你在原型阶段、或者只是想快速验证一个想法时，不需要花半天时间在配置上。
谁可能会用到
从我们自己的使用场景来看：
- 做 AI Agent 的团队：需要快速接入多个外部服务
- 做 Workflow 自动化的产品：需要连接各种第三方 API
- 想尝试 MCP 的开发者：不想在配置上花太多时间
试试看？
如果你正好在做相关的事情，可以去 mcpsdk.dev 看看。
文档在 mcpsdk.dev/docs，有问题可以在 GitHub 上开 issue，或者直接留言。
我们还在持续迭代，很多功能还不完善。但如果你愿意尝试，我们很乐意听到你的反馈。
