モデルコンテキストプロトコル（MCP）サーバー。ClaudeのようなAIアシスタントがendoflife.date APIを使用してソフトウェアのサポート終了日（EOL）とサポート状況を確認できるようにします。これにより、AIモデルはソフトウェアのライフサイクルとセキュリティ状況に関する正確な情報をリアルタイムで提供できるようになります。
モデルコンテキストプロトコル（MCP）は、Claude DesktopのようなAIアプリが外部ツールやデータソースに接続できるようにするシステムです。MCPは、AIアシスタントがユーザーによる制御を維持しながら、ローカルサービスやAPIと連携するための標準化された方法を提供します。
Related MCP server: Endoflife MCP Server
EOL MCP サーバー:
ソフトウェアのサポート終了日とサポート状況を確認します
ソフトウェアバージョンのCVE脆弱性をスキャン
バージョンの比較とアップグレードの推奨事項を提供します
ソフトウェアライフサイクルに関する自然言語クエリをサポート
複数のソフトウェア製品（Python、Node.js、Ubuntuなど）を扱います
最近のクエリをキャッシュしてすぐに参照できるようにします
リアルタイムのEOL日付検証
バージョンサポートステータスの確認
セキュリティ脆弱性分析
包括的なバージョン比較
自然言語クエリ処理
詳細なライフサイクル検証
check_version
EOL日とサポートステータスを取得する
最新のパッチバージョンを確認する
LTSステータスを確認する
サポートタイムラインの検証
get_all_details (新機能!)
包括的なライフサイクルの詳細を取得する
すべてのバージョンサイクルを表示
サポートのタイムラインを確認する
検証結果を取得する
残りのサポート日数を計算する
compare_versions
現在のバージョンと最新バージョンを比較する
アップグレードの推奨事項を取得する
互換性を確認する
アップグレードの緊急性を評価する
アップグレードパスを検証する
check_cve
セキュリティ脆弱性スキャン
サポートステータスの確認
セキュリティパッチの検証
ベンダーサポートの確認
list_products
利用可能なソフトウェアを参照する
フィルターを使って検索
製品名を確認する
製品の詳細を見る
check_software_status
バージョンサポートの検証
EOL日を確認する
セキュリティステータスを取得する
compare_versions
バージョンの違いを分析する
アップグレードの推奨事項を取得する
互換性を確認する
analyze_security
セキュリティ脆弱性分析
サポート状況の確認
パッチ検証
natural_language_query
自然言語の質問を処理する
コンテキストに応じた応答を取得する
スマートバージョン検出
validate_version
バージョン推奨事項を検証する
サポート状況を確認する
セキュリティへの影響を確認する
{
"current_date": "2024-02-20T00:00:00.000Z",
"validations": {
"current": {
"version": "1.20",
"eol_check": {
"date": "2024-02-06",
"valid": false,
"days_remaining": -14,
"message": "Version 1.20 EOL date 2024-02-06 is invalid, -14 days from now"
},
"support": {
"status": "not supported",
"lts": "not LTS"
}
}
},
"recommendation": {
"needs_update": true,
"urgency": "critical",
"message": "Current version needs urgent upgrade - use a supported version"
}
}{
"product": "go",
"current_date": "2024-02-20T00:00:00.000Z",
"cycles": [
{
"cycle": "1.22",
"releaseDate": "2024-02-06",
"eol": "2025-02-06",
"latest": "1.22.0",
"validation": {
"is_valid": true,
"days_to_eol": 351,
"is_supported": true,
"message": "Version 1.22 EOL date 2025-02-06 is valid, +351 days from now"
}
}
]
}基本バージョンチェック:
Human: Is Python 3.8 still good to use?
Claude: Let me check the status of Python 3.8.
[Uses check_version tool]
Based on the EOL data, Python 3.8:
- Security support ends: October 2024
- Current status: Security fixes only
Recommendation: Consider upgrading to Python 3.11 for new projects.セキュリティ分析:
Human: Any security concerns with Node.js 16?
Claude: I'll analyze the security status of Node.js 16.
[Uses check_version tool]
[Uses check_cve tool]
Found:
- Support Status: LTS until September 2023
- Critical CVEs: 2 in last 6 months
- CVSS Score Range: 7.5-9.8
Recommendation: Update to latest 16.x patch or consider Node.js 18 LTS.バージョン比較:
Human: Which Ubuntu version should I use?
Claude: I'll help you compare Ubuntu versions.
[Uses version-comparison prompt]
Analysis:
- 22.04 LTS: Supported until 2027, recommended for new deployments
- 20.04 LTS: Supported until 2025, stable and widely used
- 18.04 LTS: Approaching EOL, plan migration
Recommendation: Use 22.04 LTS for best long-term support.始める前に、次のものを用意してください。
Node.js (v18以上)
クロードデスクトップがインストール済み
Gitがインストールされている
次のコマンドを実行して、Node.js のインストールを確認できます。
node --version # Should show v18.0.0 or higherリポジトリをクローンします。
git clone https://github.com/ducthinh993/mcp-server-endoflife
cd mcp-server-endoflife依存関係をインストールします:
npm installプロジェクトをビルドします。
npm run buildグローバルリンクを作成します。
npm linkClaude Desktop が EOL MCP サーバーを認識するように構成します。
code ~/Library/Application\ Support/Claude/claude_desktop_config.jsoncode %APPDATA%\Claude\claude_desktop_config.jsonEOL サーバー構成を追加します。
{
"mcpServers": {
"eol": {
"command": "npx",
"args": ["/path/to/eol-mcp-server/build/index.js"]
}
}
}変更を有効にするには:
Claude Desktopを完全に終了します（ウィンドウを閉じるだけではありません）
Claude Desktopを再度起動します
EOLサーバーが接続されていることを確認するには、🔌アイコンを探します
サーバーが見つかりません
npmリンクが正しく設定されていることを確認する
Claude Desktop の設定構文を確認する
Node.jsが正しくインストールされていることを確認する
APIの問題
endoflife.date API にアクセスできるかどうかを確認する
APIレスポンスの形式が変更されていないことを確認する
ネットワーク接続を確認する
接続の問題
Claude Desktopを完全に再起動します
Claude Desktop のログを確認します。
# macOS
tail -n 20 -f ~/Library/Logs/Claude/mcp*.log問題が発生した場合:
MCPドキュメントを確認する
endoflife.date APIドキュメントを確認してください
GitHubリポジトリで問題を開く
包括的なソフトウェアライフサイクル API を提供するendoflife.date
MCP仕様のモデルコンテキストプロトコル
クロード・デスクトップのAnthropic
Scan for known security vulnerabilities and support status
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Software product name | |
| version | Yes | Version to check for vulnerabilities | |
| vendor | No | Software vendor (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'Scan' and 'support status' but lacks details on permissions, rate limits, response format, or whether this is a read-only operation. For a security tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Scan for known security vulnerabilities and support status') with zero waste. Every word earns its place, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a security vulnerability tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, response format, error handling, or how results are presented, which are crucial for an agent to use this tool effectively in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters (product, version, vendor) with descriptions and examples. The description adds no additional meaning beyond what the schema provides, such as explaining how parameters interact or their impact on results, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Scan for known security vulnerabilities and support status' clearly states the tool's purpose with a specific verb ('Scan') and resource ('security vulnerabilities and support status'). It distinguishes from siblings like 'check_version' or 'compare_versions' by focusing on vulnerabilities rather than version checking, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'check_version' or 'get_all_details'. The description implies usage for vulnerability scanning but offers no explicit context, prerequisites, or exclusions, leaving the agent to infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check EOL status and support information for software versions
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Software product name (e.g., python, nodejs, ubuntu) | |
| version | No | Specific version to check (e.g., 3.8, 16, 20.04) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Check' implies a read-only operation, it doesn't specify whether this requires authentication, has rate limits, returns structured data, or handles errors. For a tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple lookup tool and gets straight to the point with no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple lookup tool with good schema coverage but no annotations or output schema, the description is minimally adequate. It states what the tool does but doesn't provide enough context about behavior, alternatives, or expected outputs to be considered complete. The agent would need to make assumptions about how the tool actually works.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't add any parameter information beyond what's already in the schema (which has 100% coverage with clear descriptions and examples for both parameters). The baseline score of 3 is appropriate since the schema adequately documents the parameters, though the description could have added context about parameter relationships or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Check EOL status and support information') and resource ('software versions'), making it immediately understandable. However, it doesn't explicitly distinguish this from sibling tools like 'check_cve' or 'compare_versions' which might have overlapping domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'check_cve' (for vulnerabilities) or 'compare_versions' (for comparisons). There's no mention of prerequisites, typical use cases, or exclusions, leaving the agent to infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare versions and get detailed upgrade analysis
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Software product name (e.g., python, nodejs) | |
| version | Yes | Current version being used |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'compare versions' implies a read-only analysis operation, it doesn't specify whether this requires authentication, has rate limits, returns structured data, or handles errors. The mention of 'detailed upgrade analysis' suggests richer output, but this isn't elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—just one sentence with zero wasted words. It's front-loaded with the core purpose and efficiently communicates the tool's function without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'detailed upgrade analysis' entails, how results are structured, or any behavioral constraints. Given the complexity implied by 'analysis' and lack of structured output documentation, this leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already fully documents both parameters (product and version) with descriptions and examples. The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('compare versions' and 'get detailed upgrade analysis'), making it easy to understand what the tool does. However, it doesn't explicitly distinguish this from sibling tools like 'check_version' or 'get_all_details', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'check_version' or 'check_cve'. There's no mention of prerequisites, appropriate contexts, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive lifecycle details for all versions of a product
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Software product name (e.g., python, nodejs) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves details but doesn't describe what 'comprehensive lifecycle details' includes (e.g., release dates, support status, vulnerabilities), whether it's a read-only operation, potential rate limits, or error handling. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, with every part contributing to understanding. This earns a 5 for optimal conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (retrieving lifecycle details for all versions) and lack of annotations and output schema, the description is incomplete. It doesn't explain what 'comprehensive lifecycle details' entails, how results are structured, or any behavioral traits. For a tool with no structured data beyond the input schema, this leaves too many unknowns for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting the single 'product' parameter with examples. The description adds no additional parameter semantics beyond implying the tool operates on a product, which the schema already covers. According to the rules, with high schema coverage, the baseline is 3 even without param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('comprehensive lifecycle details for all versions of a product'), making the purpose specific and understandable. It distinguishes from siblings like 'check_version' (single version) or 'list_products' (product names only), but doesn't explicitly name alternatives. This earns a 4 for clarity without full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when comprehensive lifecycle details across all versions are needed, as opposed to checking a single version or listing products. However, it doesn't explicitly state when to use this tool versus alternatives like 'check_cve' or 'compare_versions', nor does it provide exclusions or prerequisites. This results in a 3 for implied but not explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse or search available software products
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Optional search term to filter products |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'browse or search' implies a read-only operation, it doesn't specify whether this tool requires authentication, has rate limits, returns paginated results, or what the output format looks like (especially since there's no output schema). For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core purpose ('Browse or search available software products'), making it easy for an agent to parse quickly. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for effective tool use. It doesn't explain what 'browse' entails (e.g., listing all products vs. paginated results), how search filtering works beyond the schema, or what the return values include (e.g., product names, IDs, versions). For a tool with no structured output documentation, the description should provide more context about expected behavior and results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'search' which aligns with the 'filter' parameter in the schema, but adds no additional semantic context beyond what the schema already provides (e.g., the schema's description covers 'Optional search term to filter products' with examples). With 100% schema description coverage and only one parameter, the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Browse or search available software products' clearly states the verb ('browse or search') and resource ('software products'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from its siblings like 'check_cve' or 'compare_versions', which appear to be more specific analysis tools rather than general browsing/searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or comparisons to sibling tools like 'get_all_details' (which might return comprehensive product information). Without such guidance, the agent must infer usage from the tool name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_cvecheck_versioncompare_versionsget_all_detailslist_productsScored across 5 tools
Each tool has a clearly distinct purpose with no ambiguity: list_products for browsing, get_all_details for comprehensive lifecycle info, check_version for EOL status, compare_versions for upgrade analysis, and check_cve for security scanning. The descriptions clearly differentiate their functions, making misselection unlikely.
All tools follow a consistent verb_noun pattern with snake_case naming (e.g., list_products, check_version, compare_versions). The naming is predictable and readable throughout the set, with no deviations in style or convention.
With 5 tools, this server is well-scoped for its EOL and software lifecycle management purpose. Each tool earns its place by covering distinct aspects of the domain, from product listing to detailed analysis, without being too sparse or bloated.
The tool set provides complete coverage for the domain, including browsing products, retrieving lifecycle details, checking EOL status, comparing versions for upgrades, and scanning for vulnerabilities. There are no obvious gaps, and the tools support a full workflow from discovery to analysis.
Latest versions, LTS windows, and EOL dates for 300+ products. Fresh ground truth for stale models.
Software end-of-life dates, open-source licenses, browser support for web features and RFC facts.
EOL dates, risk scores, CISA KEV exposure, SBOM audits and edge-device EOS for 500+ products.
Signed EOL dates, exploited CVEs and LLM prices; pay per call in USDC, no account, no daily cap.
