클로드와 같은 AI 비서가 endoflife.date API를 사용하여 소프트웨어 수명 종료(EOL) 날짜와 지원 상태를 확인할 수 있도록 하는 모델 컨텍스트 프로토콜(MCP) 서버입니다. 이를 통해 AI 모델은 소프트웨어 수명 주기 및 보안 상태에 대한 정확한 정보를 실시간으로 제공할 수 있습니다.
모델 컨텍스트 프로토콜(MCP)은 Claude Desktop과 같은 AI 앱이 외부 도구 및 데이터 소스에 연결할 수 있도록 하는 시스템입니다. 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
버전 권장 사항 검증
지원 상태 확인
보안 영향 확인
지엑스피1
{
"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 이상)
Claude Desktop 설치됨
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 linkEOL MCP 서버를 인식하도록 Claude Desktop을 구성하세요.
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 사양을 위한 모델 컨텍스트 프로토콜
클로드 데스크탑을 위한 인류학
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.
