Skip to main content
Glama
enesjakozh
ducthinh993

EOL MCP Server

by ducthinh993
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

EOL MCP Server 📅

A Model Context Protocol (MCP) server that enables AI assistants like Claude to check software end-of-life (EOL) dates and support status using the endoflife.date API. This helps AI models provide accurate information about software lifecycle and security status in real-time.

What is MCP? 🤔

The Model Context Protocol (MCP) is a system that lets AI apps, like Claude Desktop, connect to external tools and data sources. It provides a standardized way for AI assistants to work with local services and APIs while keeping the user in control.

Related MCP server: package-version-check-mcp

What does this server do? 🚀

The EOL MCP server:

  • Checks software end-of-life dates and support status

  • Scans for CVE vulnerabilities in software versions

  • Provides version comparison and upgrade recommendations

  • Supports natural language queries about software lifecycle

  • Handles multiple software products (Python, Node.js, Ubuntu, etc.)

  • Caches recent queries for quick reference

Features ✨

Core Functionality

  • Real-time EOL date validation

  • Version support status checking

  • Security vulnerability analysis

  • Comprehensive version comparison

  • Natural language query processing

  • Detailed lifecycle validation

Tools

  1. check_version

    • Get EOL dates and support status

    • Check latest patch versions

    • Verify LTS status

    • Validate support timeline

  2. get_all_details (New!)

    • Get comprehensive lifecycle details

    • View all version cycles

    • Check support timeline

    • Get validation results

    • Calculate remaining support days

  3. compare_versions

    • Compare current vs latest versions

    • Get upgrade recommendations

    • Check compatibility

    • Assess upgrade urgency

    • Validate upgrade paths

  4. check_cve

    • Security vulnerability scanning

    • Support status verification

    • Security patch validation

    • Vendor support checking

  5. list_products

    • Browse available software

    • Search with filters

    • Verify product names

    • Get product details

Prompts

  1. check_software_status

    • Validate version support

    • Check EOL dates

    • Get security status

  2. compare_versions

    • Analyze version differences

    • Get upgrade recommendations

    • Check compatibility

  3. analyze_security

    • Security vulnerability analysis

    • Support status check

    • Patch verification

  4. natural_language_query

    • Process natural language questions

    • Get contextual responses

    • Smart version detection

  5. validate_version

    • Validate version recommendations

    • Check support status

    • Verify security implications

Response Examples

Version Validation

{
  "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"
  }
}

All Details Response (New!)

{
  "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"
      }
    }
  ]
}

Example Conversations 💬

  1. Basic Version Check:

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.

  1. Security Analysis:

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.

  1. Version Comparison:

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.

Prerequisites 📋

Before you begin, ensure you have:

You can verify your Node.js installation by running:

node --version  # Should show v18.0.0 or higher

Installation 🛠️

  1. Clone the repository:

git clone https://github.com/ducthinh993/mcp-server-endoflife
cd mcp-server-endoflife

  1. Install dependencies:

npm install

  1. Build the project:

npm run build

  1. Create a global link:

npm link

Configuration ⚙️

1. Claude Desktop Configuration

Configure Claude Desktop to recognize the EOL MCP server:

For macOS:

code ~/Library/Application\ Support/Claude/claude_desktop_config.json

For Windows:

code %APPDATA%\Claude\claude_desktop_config.json

Add the EOL server configuration:

{
  "mcpServers": {
    "eol": {
      "command": "npx",
      "args": ["/path/to/eol-mcp-server/build/index.js"]
    }
  }
}

2. Restart Claude Desktop

For the changes to take effect:

  1. Completely quit Claude Desktop (not just close the window)

  2. Start Claude Desktop again

  3. Look for the 🔌 icon to verify the EOL server is connected

Troubleshooting 🔧

Common Issues

  1. Server Not Found

    • Verify the npm link is correctly set up

    • Check Claude Desktop configuration syntax

    • Ensure Node.js is properly installed

  2. API Issues

    • Check if endoflife.date API is accessible

    • Verify the API response format hasn't changed

    • Check network connectivity

  3. Connection Issues

    • Restart Claude Desktop completely

    • Check Claude Desktop logs:

      # macOS
tail -n 20 -f ~/Library/Logs/Claude/mcp*.log

Getting Help

If you encounter issues:

Acknowledgments 🙏

Available Tools

5 tools
check_cveC

Scan for known security vulnerabilities and support status

ParametersJSON Schema
NameRequiredDescriptionDefault
productYesSoftware product name
versionYesVersion to check for vulnerabilities
vendorNoSoftware vendor (optional)

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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_versionB

Check EOL status and support information for software versions

ParametersJSON Schema
NameRequiredDescriptionDefault
productYesSoftware product name (e.g., python, nodejs, ubuntu)
versionNoSpecific version to check (e.g., 3.8, 16, 20.04)

TDQS

B3.1/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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_versionsC

Compare versions and get detailed upgrade analysis

ParametersJSON Schema
NameRequiredDescriptionDefault
productYesSoftware product name (e.g., python, nodejs)
versionYesCurrent version being used

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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_all_detailsB

Get comprehensive lifecycle details for all versions of a product

ParametersJSON Schema
NameRequiredDescriptionDefault
productYesSoftware product name (e.g., python, nodejs)

TDQS

B3.2/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

list_productsC

Browse or search available software products

ParametersJSON Schema
NameRequiredDescriptionDefault
filterNoOptional search term to filter products

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0
Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness5/5

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.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • EndOfLife MCP Server

    brianprost
    F
    license
    A
    quality
    F
    maintenance
    Provides access to the endoflife.date API to query support and end-of-life information for thousands of software products. It enables users to retrieve detailed release schedules, lifecycle data, and product categories through natural language.
    7

  • package-version-check-mcp

    MShekow
    A
    license
    A
    quality
    A
    maintenance
    Enables AI coding agents to retrieve the latest stable versions of packages and tools across multiple ecosystems, preventing outdated dependency versions in generated code.
    4
    8
    Apache 2.0

  • cve-lookup-mcp

    Aashish-32
    A
    license
    A
    quality
    C
    maintenance
    Provides live CVE data from NVD and EPSS without API key, enabling AI assistants to look up CVSS scores, search vulnerabilities, and check product CVEs.
    3
    MIT

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ducthinh993/mcp-server-endoflife'

If you have feedback or need assistance with the MCP directory API, please join our Discord server