模型上下文协议 (MCP) 服务器，使 Claude 等 AI 助手能够使用 endoflife.date API 检查软件生命周期终止 (EOL) 日期和支持状态。这有助于 AI 模型实时提供有关软件生命周期和安全状态的准确信息。
模型上下文协议 (MCP) 是一个允许 AI 应用（例如 Claude Desktop）连接到外部工具和数据源的系统。它为 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 link配置 Claude Desktop 以识别 EOL MCP 服务器：
code ~/Library/Application\ Support/Claude/claude_desktop_config.jsoncode %APPDATA%\Claude\claude_desktop_config.json添加 EOL 服务器配置：
{
"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 文档
在 GitHub 存储库中打开一个问题
endoflife.date为其全面的软件生命周期 API
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.
