deprecation-mcp

deprecation-mcp

一个免费、开源的 MCP 服务，用于检查供应商的 API 或 SDK 是处于活跃、已弃用还是已停用状态——这样，执行升级／维护工作的 Agent 就能在出问题之前检查，而不是事后补救。

API／SDK 弃用信息散见于更新日志页面、RSS 源（如果你够幸运的话），以及 Sunset／Deprecation HTTP 标头（前提是供应商愿意实现 RFC 8594）。本服务将经过整理和人工核实的信息封装在一次工具调用中。

没有付费门槛、没有计量，也没有任何计费代码——这只是一个简单的开源 MCP 服务。

提供的功能

一个工具，check_deprecation：

check_deprecation(provider: string, target: string) -> {
  status: "active" | "deprecated" | "sunset" | "unknown",
  deprecated_on: string | null,
  sunset_on: string | null,
  replacement: string | null,
  migration_url: string | null,
  source_url: string,
  last_verified_at: string
}

对于以下精选数据集中未收录的任何提供方／目标，都会返回 status: "unknown"（且 source_url 为空）；这表示“未跟踪”，而不是“已确认仍处于活跃状态”。

精选数据集

涵盖十个提供方的 API／SDK，每项数据都根据供应商自行发布的页面（source_url），在 last_verified_at 标注的日期进行了核查。数据存放在 data/deprecations.json 中。

提供方	目标	状态
aws	aws-sdk-js-v2	已停用
stripe	sources-api	已弃用
twilio	programmable-chat	已停用
github	dependency-graph-sbom-sync	已弃用
openai	assistants-api	已弃用
slack	classic-apps	已弃用
sendgrid	v2-mail-send	已弃用
shopify	rest-admin-api	已弃用
auth0	rules-and-hooks	已弃用
paypal	nvp-soap-api	已弃用

查找不区分大小写，也会匹配每条记录的 aliases（例如，aws／aws-sdk 会解析为 aws-sdk-js-v2）。

运行

npm install
npm run build
npm start        # starts the stdio MCP server

添加到 MCP 客户端

Claude Code（在项目的 .mcp.json 中配置，或使用 claude mcp add）：

{
  "mcpServers": {
    "deprecation": {
      "command": "node",
      "args": ["/absolute/path/to/deprecation-mcp/dist/index.js"]
    }
  }
}

其他任何基于 stdio 的 MCP 客户端配置格式也相同：将 node dist/index.js 作为服务命令运行。

示例

连接后，Agent 调用：

{
  "name": "check_deprecation",
  "arguments": { "provider": "aws", "target": "aws-sdk-js-v2" }
}

并获得以下返回结果：

{
  "status": "sunset",
  "deprecated_on": "2024-09-08",
  "sunset_on": "2025-09-08",
  "replacement": "AWS SDK for JavaScript v3",
  "migration_url": "https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/migrating-to-v3.html",
  "source_url": "https://aws.amazon.com/blogs/developer/announcing-end-of-support-for-aws-sdk-for-javascript-v2/",
  "last_verified_at": "2026-08-08"
}

测试

npm test   # builds, then runs node:test against the lookup logic

更新数据集

直接编辑 data/deprecations.json 即可——无需构建步骤或爬虫，服务会在启动时读取该文件。每条记录都需要填写你实际核查过的有效 source_url 和准确的 last_verified_at。重新核实记录时，也要重新计算其 content_hash（见下文）。

漂移检测

偶尔手动检查十个 source_url 无法扩展，而且过时的数据比没有数据更糟。每周运行的 GitHub Action (.github/workflows/check-drift.yml) 会获取每条记录的 source_url，对响应正文进行哈希计算（sha256），并与记录在 last_verified_at 时存储的 content_hash 进行比较。如果哈希值发生变化，说明页面自上次验证后有所变动——系统会标记该记录，但不会自动更新。自动化流程绝不会写入 data/deprecations.json；页面发生变化只表示“需要人工或 Agent 手动重新验证这条记录”，绝不会据此推断新的状态。错误地自动推断状态比没有自动化更糟。

检测到漂移或获取失败时，工作流会创建（或更新）一个带有 drift-check 标签的 GitHub issue，汇总需要关注的记录；后续运行结果正常时，会自动关闭该 issue。

在本地运行：

npm run build
npm run check-drift

如果所有记录的哈希值仍然匹配，则以状态码 0 退出；否则以 1 退出。

所有十个 source_url 在设置 content_hash 基准值时都使用普通 GET 请求获取（未使用无头浏览器，也未绕过机器人防护），且全部成功。如果供应商之后添加机器人防护或重定向，导致普通 GET 请求无法获取页面，该记录会在每周报告中显示为 fetch_failed，而不会被悄然跳过。

已知限制： AWS 博客文章、Stripe 文档页面和 PayPal 文档页面（aws/aws-sdk-js-v2、stripe/sources-api、paypal/nvp-soap-api）会嵌入随每次请求变化的动态内容，例如 nonce、时间戳或会话令牌，即使页面实质内容并未改变也是如此。因此，这些页面的正文哈希在不同请求之间并不完全稳定，每周检查偶尔可能会将其中一条标记为“发生漂移”，即使实际上并无变化。我们会如实披露这一点，而不采取变通办法（例如移除已知的易变子字符串）：对于一个设计原则是绝不猜测状态的工具而言，误报“请查看此页面”是可以接受的代价。人工或 Agent 重新验证此类被标记的记录时，应考虑到这可能是误报。