MCP Servers v2.0.0 在保留旧版客户端支持的同时加入现代协议支持

MCP Servers v2.0.0 对项目的参考服务器进行了重构，以支持现代协议，同时保留对旧版客户端的支持。该更新于 10 月 19 日发布，旨在衔接不同代际的 MCP；MCP 即 Model Context Protocol，用于将 AI 应用与工具及数据连接起来。其兼容性承诺有明确边界：旧版客户端仍受支持，但 TypeScript 服务器现要求使用 Node.js 24。

这一差异给维护现有集成的开发者带来压力。客户端仍可使用较早的协议，但其工具背后的软件可能需要更新的运行时。因此，应用团队需要分别就服务器包、执行环境和协议行为作出决策。

核心矛盾在于现代化与延续性之间。维护者正将示例迁移至更新的架构，而不要求每个已连接的应用同步迁移。对于使用 Claude Desktop、VS Code 或自定义 AI 应用的开发者而言，最直接的问题是：哪些既有假设能够在这一过渡中继续成立。相比版本号本身，连接设置、文件权限和应用状态的生命周期更值得关注。

MCP Servers v2.0.0 实际改变了什么

此次发布更新的是一组明确的参考实现，而非更广泛 MCP 社区中的全部服务器。

发布包列表显示，有四个 TypeScript 包发布为 2.0.0 版本，分别覆盖 Everything、Filesystem、Memory 和 Sequential Thinking。TypeScript 是一种为 JavaScript 增加类型检查的编程语言。

同一版本还列出了三个 Python 包：Fetch、Git 和 Time。它们采用基于日期的版本号 2026.10.19。这一区别在团队盘点依赖项时尤为重要，因为仓库的发布标签并不会成为每个包的版本号。

维护者将此次更新描述为一次支持现代规范的重构，同时继续响应旧版客户端。这是针对所包含服务器的一项实现声明，并不能证明不相关的社区集成或所有通过 MCP 连接的应用也具备兼容性。

这里还涉及彼此独立的版本体系。仓库发布使用 v2.0.0，而协议使用基于日期的标识符。包版本用于标识已发布的软件；协议标识符则描述该软件所支持的通信规则。

混淆这些标识符可能导致对升级产生误导性预期。安装标注为 2.0.0 的包，并不意味着应用会自动采用每一项较新的协议功能。客户端仍决定其使用哪种受支持的通信行为。

这意味着 MCP 服务器兼容性是组件之间的一种关系。服务器包可以支持多个协议修订版本，而已连接的应用仍继续使用较早版本。反过来，安装更新的服务器软件也无法补齐客户端缺失的能力。

对于工程管理者而言，此次发布清晰地区分了可用性与就绪状态。已发布的软件包表明实现可供使用；是否就绪则取决于周边应用、启动环境、权限和预期行为能否协同工作。

其实际影响不止于直接运行这些包的人员。参考实现为其他开发者提供研究和改造的示例。即使参考包从未进入生产依赖清单，其架构选择也可能影响自定义集成。

这种影响需要谨慎表述。一个示例可以确立某种模式，但无法证明该模式适用于每一种部署。此次发布提供了具体的实现材料，但应用所有者仍有责任判断哪些部分符合自身系统。

因此，这条新闻比“MCP 已发生变化”的宽泛公告更具体。维护者发布了更新后的示例，将较新的协议行为与既有的大量旧版客户端连接起来。接下来的问题是运行这些示例所需的基础设施。

旧版客户端仍受支持，但旧版运行时不再受支持

协议兼容性并不意味着保留原有的执行环境。

此次发布的 Node.js 要求将 TypeScript 服务器的最低 Node.js 版本提升至 24。Node.js 是在浏览器之外执行 JavaScript 的运行时。该变更适用于 Everything、Filesystem、Memory 和 Sequential Thinking。

相关维护记录解释了为何这一要求值得关注。此前，包声明、文档和自动化检查对支持预期的表述并不一致。此次修正使声明的最低版本、文档与验证配置统一围绕较新的运行时。

这为本地 AI 应用带来了具体的迁移问题。用户可能更新服务器包，却未改动应用的启动环境。客户端协议仍然可接受，但服务器依然依赖于启动该进程时可用的运行时。

设想一台示例工程工作站，其开发环境与桌面应用环境彼此独立。终端可能报告预期的运行时，而从其他位置启动的应用则会继承不同配置。终端中成功执行，并不能说明桌面应用也能启动同一服务器。

这个例子说明的是部署推理，而非此次发布中已报告的缺陷。更广泛的含义直接源于新的最低要求：团队需要取得实际启动该包的环境证据。

压力最直接地落在分发配置的开发者、维护受管工作站的管理员，以及打包内部助手的团队身上。他们的责任不仅包括工具声明的接口，也包括启动工具的软件。

对这些团队而言，向后兼容可以减少协调工作，但无法完全消除。它们未必需要立即重写旧版客户端，但仍需考虑新版服务器的要求。

这一差别也改变了对故障的理解方式。无法启动的进程，与已运行却拒绝请求的服务器，是两类不同问题。若将两者都视为协议不兼容，排查就会指向错误的组件。

同样的推理也适用于支持文档。一条说明旧版客户端仍受支持的指引，附近应补充运行时要求的背景。否则，读者很可能合理地推断出维护者并未作出的更广泛承诺。

将依赖固定在选定版本的包版本锁定，成为一种后果清晰的运维选择。团队可以审慎评估新版本，而不是将意外的包变更与环境变更混在一起。

这并不构成一条普遍主张，即应当延后更新。它表明有必要区分更新的不同原因。寻求现代协议行为的团队，与维护现有工作流的团队，眼下目标并不相同。

此次发布为两类团队都提供了前进路径，但验证方式应反映这些不同目标。维护旧版客户端意味着检查其行为是否持续可用。采用新版客户端则还意味着审视处理其请求的架构。

兼容性桥梁改变了请求携带上下文的方式

即使可见工具依旧熟悉，更新后的架构也改变了通信上下文的存放位置。

根据当前的协议版本控制规则，协议修订版本为 2026-07-28。请求通过元数据声明协议版本，即随请求附带的描述性信息。服务器会依据所支持的版本逐一接受或拒绝请求。

客户端可以使用 server/discover，这是一种返回服务器身份、支持版本和能力的发现请求。较早的协议修订版本则使用初始化握手，即用于建立连接运行上下文的初始交互。

现代协议实现将两种方式都带入 TypeScript 参考服务器。对于本地连接，第一条消息会选择协议时代：旧版客户端以 initialize 开始；现代客户端则使用发现请求或较新的请求元数据。

该实现也不再依赖按会话标识符索引的服务器状态。连接特定的状态存放在服务器实例上。需要跨现代请求保存的信息则使用句柄，即由服务器签发、用于引用该信息的标识符。

这些细节很重要，因为“无状态”很容易被误解。不再依赖协议会话，并不意味着应用会在每次请求后忘记一切。它意味着开发者必须明确识别信息存放在哪里，以及后续操作如何引用这些信息。

对于自定义集成而言，这一区别会影响架构审查。开发者需要区分属于请求的信息、属于连接的信息，以及已存储的应用数据。它们的生命周期不必一致。

助手保留一项项目事实，与工具保留临时进度，是两种不同需求。持久信息应按照产品的存储规则持续存在。临时信息则应仅在预定操作或交互期间可用。

Memory 服务器说明了这种差异。其知识图谱是一种通过关系连接实体的结构，用于提供持久信息。其文档描述了现代和旧版客户端不同的订阅机制，同时保留相同的底层工具和资源。

订阅是指在信息发生变化时请求接收更新。重要的产品问题在于应用是否会继续接收这些更新。初始读取成功，并不能证明后续变化会如预期般出现。

Sequential Thinking 则呈现了另一种生命周期差异。其文档说明，在任一协议时代，思考历史都会持续存在于连接期间。这种行为涉及工具的工作上下文，而非对永久记忆作出的一般承诺。

Everything 的用途又有所不同。它为客户端构建者演练协议能力，包括现代请求和通知行为。其价值在于暴露简单的成功工具调用无法检验的集成行为。

综合来看，这些示例说明，MCP 服务器迁移不止是更换导入语句或包名称。可见功能可以保持熟悉，但周边通信模型已经改变。改造参考代码的开发者需要理解这两个层面。

这也是兼容性方案显现重要性的地方。支持旧版客户端为应用团队赢得了时间，但并不能免除在采用新行为前理解新架构的必要性。

文件系统访问使行为差异变得具体

同一个服务器包可能会因客户端所处的协议时代不同，而需要不同的权限配置。

Filesystem server 提供了最清晰的例子，因为它的行为会影响工具能够访问哪些本地目录。允许列表是明确列出的获准访问位置集合。该服务器的现代连接方式使用进程启动时提供的目录。

带标签的目录访问控制文档建议在各协议版本中使用这些启动参数。较旧的客户端还可使用 Roots，这是一种由客户端提供、用于描述文件系统位置的机制。现代连接方式不会请求这类旧版信息。

因此，未指定允许访问目录的服务器会因连接路径不同而表现不同。对于现代工具调用，文档说明会返回错误，解释缺少目录配置。仅仅连接到某个进程，并不意味着已经建立了可用的文件访问权限。

对于旧版客户端，文档还描述了访问权限更新和撤销机制。当 Roots 刷新处于待处理状态时，工具调用会等待。客户端提供的根目录生效后，如果更新中不包含任何有效根目录，访问权限将被移除，直到有效根目录重新出现。

产品层面的含义很直接：连接成功与权限成功是两个独立结果。客户端可以发现服务器并识别其工具，却仍没有通往目标文件的有效访问路径。

设想一个示例：某助手帮助工程师比较本地设计文档。客户端升级前后，用户的请求听起来完全相同。然而，应用程序可能进入不同的协议路径，并遇到不同的配置要求。

如果此前的安排依赖客户端提供的 Roots，采用现代路径就需要关注启动目录。用户的措辞不会暴露这种依赖关系。显示存在文件操作的工具列表也不会。

这正是为什么权限应纳入迁移分析，而非仅作为脚注。文件访问将协议行为与用户预期直接关联起来。配置不匹配在用户看来，可能像是知识缺失，或助手无法理解请求。

它还可能使故障排查更加复杂。团队可能会调查检索质量——即软件发现相关信息的有效程度——而底层工具实际上无法访问目标位置。该版本的文档有助于区分这些可能性。

对于知识工作流，团队应区分连接器的访问边界与最终信息系统的质量。可搜索的知识库依赖于相关文档可用、组织妥当且可被检索。协议支持只覆盖这条链路的一部分。

该示例也限制了开发者应从向后兼容性中推断的内容。持续支持旧版行为，并不意味着现代客户端可以采用相同的权限配置。两条路径都可能获得支持，但依赖不同的机制。

对于评估助手的组织而言，这种差异带来了一个具体的采购问题：哪个组件定义可访问的位置，以及应用程序如何传达访问权限缺失或被撤销？答案应描述实际行为，而不只是罗列支持的标准。

该版本使这一问题更容易调查，因为参考实现记录了其边界。其他集成仍需要各自的证据。复制协议标签，并不能证明它们采用了等效的访问规则。