Un servidor de Protocolo de Contexto de Modelo (MCP) que permite a asistentes de IA como Claude consultar las fechas de fin de vida útil (EOL) del software y el estado de soporte mediante la API endoflife.date. Esto ayuda a los modelos de IA a proporcionar información precisa sobre el ciclo de vida del software y el estado de seguridad en tiempo real.
El Protocolo de Contexto de Modelo (MCP) es un sistema que permite que las aplicaciones de IA, como Claude Desktop, se conecten a herramientas y fuentes de datos externas. Proporciona una forma estandarizada para que los asistentes de IA trabajen con servicios y API locales, manteniendo al usuario en control.
Related MCP server: package-version-check-mcp
El servidor MCP EOL:
Comprueba las fechas de finalización de la vida útil del software y el estado de soporte.
Analiza en busca de vulnerabilidades CVE en versiones de software
Proporciona comparación de versiones y recomendaciones de actualización.
Admite consultas en lenguaje natural sobre el ciclo de vida del software.
Maneja múltiples productos de software (Python, Node.js, Ubuntu, etc.)
Almacena en caché consultas recientes para una referencia rápida
Validación de fecha de fin de vida útil en tiempo real
Comprobación del estado de compatibilidad de versiones
Análisis de vulnerabilidades de seguridad
Comparación completa de versiones
Procesamiento de consultas en lenguaje natural
Validación detallada del ciclo de vida
check_version
Obtenga fechas de fin de vida útil y estado de soporte
Consulte las últimas versiones del parche
Verificar el estado de LTS
Validar el cronograma de soporte
get_all_details (¡Nuevo!)
Obtenga detalles completos del ciclo de vida
Ver todos los ciclos de versiones
Consultar el cronograma de soporte
Obtener resultados de validación
Calcular los días de soporte restantes
compare_versions
Comparar las versiones actuales con las más recientes
Obtenga recomendaciones de actualización
Comprobar compatibilidad
Evaluar la urgencia de la actualización
Validar rutas de actualización
check_cve
Análisis de vulnerabilidades de seguridad
Verificación del estado de soporte
Validación de parches de seguridad
Comprobación del soporte del proveedor
list_products
Explorar el software disponible
Buscar con filtros
Verificar los nombres de los productos
Obtener detalles del producto
check_software_status
Validar la compatibilidad de versiones
Consultar fechas de fin de vida útil
Obtener estado de seguridad
compare_versions
Analizar las diferencias de versiones
Obtenga recomendaciones de actualización
Comprobar compatibilidad
analyze_security
Análisis de vulnerabilidades de seguridad
Comprobación del estado de soporte
Verificación de parches
natural_language_query
Procesar preguntas en lenguaje natural
Obtenga respuestas contextuales
Detección de versión inteligente
validate_version
Validar recomendaciones de versiones
Comprobar el estado del soporte
Verificar las implicaciones de seguridad
{
"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"
}
}
]
}Comprobación de la versión básica:
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.Análisis de seguridad:
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.Comparación de versiones:
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.Antes de comenzar, asegúrese de tener:
Node.js (v18 o superior)
Claude Desktop instalado
Git instalado
Puede verificar su instalación de Node.js ejecutando:
node --version # Should show v18.0.0 or higherClonar el repositorio:
git clone https://github.com/ducthinh993/mcp-server-endoflife
cd mcp-server-endoflifeInstalar dependencias:
npm installConstruir el proyecto:
npm run buildCrear un enlace global:
npm linkConfigurar Claude Desktop para reconocer el servidor MCP EOL:
code ~/Library/Application\ Support/Claude/claude_desktop_config.jsoncode %APPDATA%\Claude\claude_desktop_config.jsonAgregue la configuración del servidor EOL:
{
"mcpServers": {
"eol": {
"command": "npx",
"args": ["/path/to/eol-mcp-server/build/index.js"]
}
}
}Para que los cambios surtan efecto:
Salir completamente de Claude Desktop (no solo cerrar la ventana)
Inicie Claude Desktop nuevamente
Busque el ícono 🔌 para verificar que el servidor EOL esté conectado
Servidor no encontrado
Verifique que el enlace npm esté configurado correctamente
Compruebe la sintaxis de configuración de Claude Desktop
Asegúrese de que Node.js esté instalado correctamente
Problemas de API
Comprueba si la API endoflife.date es accesible
Verifique que el formato de respuesta de la API no haya cambiado
Comprobar la conectividad de la red
Problemas de conexión
Reiniciar Claude Desktop por completo
Consulte los registros de Claude Desktop:
# macOS
tail -n 20 -f ~/Library/Logs/Claude/mcp*.logSi encuentra problemas:
Revisar la documentación del MCP
Consulte la documentación de la API endoflife.date
Abrir un problema en el repositorio de GitHub
endoflife.date para su API integral del ciclo de vida del software
Protocolo de contexto de modelo para la especificación MCP
Antrópico para Claude Desktop
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.
EOL dates, risk scores, CISA KEV exposure, SBOM audits and edge-device EOS for 500+ products.
Real-time B2A and M2M deprecation feeds for AI agents and dev pipelines.
CVE lookups (NVD) and dependency-manifest audits (OSV) for AI agents. No API keys.