deprecation-mcp

deprecation-mcp

ベンダーの API または SDK が有効か、非推奨か、提供終了かを確認できる、無料のオープンな MCP サーバーです。アップグレードやメンテナンスを行うエージェントが、問題が起きてからではなく、起きる前に確認できます。

API／SDK の非推奨情報は、変更履歴ページや RSS フィード（運がよければ）、またベンダーが RFC 8594 の実装に対応していれば Sunset／Deprecation HTTP ヘッダーなどに散在しています。このサーバーでは、厳選し手作業で検証した情報を 1 回のツール呼び出しで確認できます。

利用料金による制限も、従量課金も、課金用コードも一切ありません。これはシンプルなオープン MCP サーバーです。

提供する機能

1 つのツール、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 は空）が返されます。これは「追跡対象外」を意味し、「有効であることが確認済み」という意味ではありません。

厳選データセット

10 個のプロバイダーの API／SDK を対象に、それぞれ last_verified_at の日付にベンダー自身が公開したページ（source_url）と照合しています。データは data/deprecations.json にあります。

provider	target	status
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 を実行してください。

使用例

接続後、エージェントが次のように呼び出します。

{
  "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 も再計算してください（詳細は後述）。

ドリフト検出

10 件の source_url を時々手作業で確認する方法では拡張できず、古いデータはデータがないよりも悪影響を及ぼします。毎週実行される GitHub Action (.github/workflows/check-drift.yml) は、各レコードの source_url を取得し、レスポンス本文をハッシュ化（sha256）して、last_verified_at 時点でレコードに保存されている content_hash と比較します。ハッシュが変わっていた場合、そのページは最後に確認してから変更されています。レコードにはフラグが付けられ、自動更新はされません。この自動化が data/deprecations.json に書き込むことはありません。ページが変更されていた場合に意味するのは「人間またはエージェントがこのレコードを手動で再確認する必要がある」ということだけであり、新しいステータスを推測することはありません。誤ったステータスを自動推測するくらいなら、自動化しないほうがましです。

ドリフトまたは取得失敗が検出されると、ワークフローは drift-check ラベルが付いた GitHub issue を 1 件作成（または更新）し、確認が必要なレコードをまとめます。その後の実行で問題がないことが確認されると、その issue は自動的にクローズされます。

ローカルで実行するには、次のとおりです。

npm run build
npm run check-drift

すべてのレコードのハッシュが一致した場合は 0、それ以外の場合は 1 で終了します。

content_hash のベースラインを設定した際、10 件すべての source_url を通常の GET で取得しました（ヘッドレスブラウザーやボット対策の回避策は使用していません）。10 件すべて取得に成功しました。ベンダーが後からボット対策や通常の GET による取得を妨げるリダイレクトを追加した場合、そのレコードは週次レポートに fetch_failed として表示され、黙ってスキップされることはありません。

既知の制限事項： AWS のブログ記事、Stripe のドキュメントページ、PayPal のドキュメントページ（aws/aws-sdk-js-v2、stripe/sources-api、paypal/nvp-soap-api）には、リクエストごとに変化する動的コンテンツ（nonce、タイムスタンプ、セッショントークンなど）が埋め込まれています。実質的なページ内容に変更がなくても、これらの値は取得のたびに変わります。そのため、本文のハッシュはリクエスト間で完全には安定せず、実際には何も変更されていなくても、週次チェックでこの 3 件のいずれかに「ドリフトあり」のフラグが付くことがあります。これは開示しており、回避策（既知の変動する文字列を削除するなど）は講じていません。「このページを確認してください」という誤検知は、ステータスを決して推測しないことを設計原則とするツールにとって、許容できるコストです。フラグが付いたレコードを人間またはエージェントが再確認する際は、誤検知の可能性があることを想定してください。