[控场AI]
· 4 分钟阅读· 2,294 字

MCP TypeScript SDK:一个插件适配所有AI助手?

MCP TypeScript SDK:一个插件适配所有AI助手?

MCP TypeScript SDK 用统一协议让一个服务器接入多个 AI 助手,但托管与安全需自担。

MCP TypeScript SDK 是模型上下文协议的官方工具包,旨在解决 AI 助手、代码编辑器和 Agent 各自插件机制碎片化的问题,被比喻为「AI 应用的 USB-C 接口」。开发者用 schema 描述工具输入,SDK 在代码执行前拒绝非法调用;服务器支持本地标准输入输出和 HTTP 端点两种部署方式,同一套代码覆盖本地与远程场景,还能用于构建 MCP 客户端。但 SDK 只校验访问令牌而不签发,托管、限流、输出净化等安全责任完全由开发者承担。协议仍在快速演进,七月发布了规范修订和 SDK 版本 2,不同助手的特性支持存在差异,实际落地仍需针对客户端做适配测试。

AI 助手、代码编辑器、Agent 正在成为用户与应用交互的新入口。但每个平台都有自己的插件机制,开发者如果想让自己应用出现在所有 AI 工具里,往往要为每个入口单独开发和维护一套工具。MCP(Model Context Protocol)TypeScript SDK 试图解决这个碎片化问题——官方将其比喻为「AI 应用的 USB-C 接口」。

MCP 被比喻为 AI 应用的 USB-C 端口

统一入口:一次构建,多处运行

MCP 的核心理念是用一套协议描述应用能力。开发者注册「工具」用于执行动作,「资源」用于提供数据,「提示词」供用户选择。AI 助手的 MCP 客户端会列出这些能力,模型调用某个工具时,你的函数被执行,结果返回给模型。据官方文档,该 SDK 开源,采用 Apache 和 MIT 双许可,GitHub 星标已超过 13,000。

这意味着你不再需要为 VS Code、Cloud Code 和 Cursor 各写一套插件。SDK 指南中提到,只需一个启动命令即可接入这些环境。对于 TypeScript 开发者而言,一个 MCP 服务器可以同时服务多个助手。

MCP 中的「工具」「资源」「提示词」三类原语有明确的分工。工具(Tools)是模型可以主动调用的函数,通常带有副作用,比如发送邮件或查询数据库;资源(Resources)是只读的数据端点,类似文件或 API 响应,由客户端决定是否加载到上下文;提示词(Prompts)则是预置的模板,供用户在选择器中显式触发。这种划分让模型能区分「可以执行的动作」与「可以读取的数据」,也便于客户端按需控制权限和上下文体积。理解这三者的边界,是设计一个符合 MCP 规范的服务器的前提。

SDK 的三大实用能力

1. Schema 驱动输入校验

工具输入只需用 schema 描述一次。SDK 会在你的代码运行前拒绝不合法的调用,把参数错误挡在业务逻辑之外,减少运行时异常。

这里的 schema 通常指 JSON Schema,MCP 规范用它来描述工具输入参数的类型、必填项和约束。SDK 会将该 schema 转换为运行时的校验逻辑,在调用你的处理函数之前检查参数。由于 JSON Schema 本身是语言无关的标准,同一个工具定义可以被不同语言的客户端读取和渲染成表单,这也是 MCP 能跨助手复用的基础。对 TypeScript 开发者来说,schema 还可以与类型定义联动,减少手写校验代码的工作量。

2. 灵活的部署方式

服务器既可以通过标准输入输出在本地运行,也可以作为 HTTP 端点部署,供 Web 端 AI 助手调用。本地与远程场景用同一套代码覆盖。

标准输入输出(stdio)传输适用于本地进程,客户端启动服务器子进程并通过管道通信,无需网络端口,天然适合桌面端 AI 助手。HTTP 端点则面向远程或 Web 场景,通常配合服务器发送事件(SSE)或流式 HTTP 实现服务端到客户端的推送。两种传输方式共享同一套工具定义,差异主要体现在连接建立和会话管理上。选择哪种方式,取决于你的用户是在本地运行助手,还是通过浏览器访问托管服务。

3. 同时构建客户端

SDK 不仅用于写服务器,也支持构建 MCP 客户端。

SDK 同样可以用于构建 MCP 客户端

需要自己承担的托管与安全

便利背后有代价。SDK 负责校验访问令牌,但不会签发令牌;服务器的托管和安全防护完全由开发者自己负责。规范要求服务器必须校验工具输入、控制访问、限制调用频率并对输出做净化处理。这些不是可选建议,而是部署 MCP 服务时必须完成的工作。

托管与安全需要开发者自行处理

如果不想自托管,Composio 提供了现成的托管应用工具方案,并有免费计划可供尝试。

MCP 规范中的访问令牌校验通常基于 OAuth 2.1 流程,服务器需要验证令牌的签名、有效期和授权范围,但令牌的签发与用户授权环节要由开发者对接自己的身份提供商。限流方面,由于工具调用可能触发昂贵的后端操作,建议按客户端或用户维度设置配额。输出净化则针对模型可能被诱导执行危险操作的风险,对返回内容做转义或白名单过滤。这些要求共同构成了 MCP 服务器上线前的安全基线。

协议仍在快速演进

MCP 并非稳定不变的规范。据视频内容,七月带来了规范修订和 SDK 版本 2。不同助手对 MCP 特性的支持程度也不一致,这意味着「一次编写、处处运行」在现实中仍需要针对具体客户端做适配测试。

七月发布了规范修订和 SDK 版本 2

适合谁用

这套 SDK 面向希望用一个服务器服务多个 AI 助手、并且有能力安全运维的 TypeScript 开发者。入门路径很直接:跟随 SDK 的「第一个服务器」指南,安装依赖,添加一个工具,然后从 MCP inspector 发起调用验证。

对于小型团队,在决定自建之前,值得先评估托管方案的月成本与自托管所需的运维投入。安全要求(令牌签发、限流、输出净化)会显著影响工作量,这是选择自建路线时最容易被低估的部分。

#MCP TypeScript SDK#Model Context Protocol#AI 插件开发#MCP 服务器#AI 助手集成#TypeScript SDK#MCP 客户端
分享:

相关推荐