end-of-life-mcp
Related Servers
Alternatives to end-of-life-mcp
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityBmaintenanceEnables checking whether software packages are deprecated, archived, stale, active, or unknown with supporting evidence, auditing dependency manifests, and looking up runtime support and end-of-life dates.MIT

endoflife-mcpofficial
AlicenseAqualityAmaintenanceSoftware end-of-life intelligence for AI agents: EOL dates, support timelines and 0-100 upgrade risk scores for 480+ products. Check whether a version is still supported, score its risk, or audit an entire stack.5197 npmMIT- AlicenseAqualityCmaintenanceEnables agents to validate Dockerfiles for build-breaking syntax errors, risky patterns like root users and secrets in ENV/ARG, and cache-order problems, returning every finding with its line and a fix. It also verifies referenced container images against public registries, reporting tag existence, digests to pin, supported platforms, last rebuild time, and end-of-life status with an upgrade tag.2MIT
- AlicenseAqualityDmaintenanceEnables inspection and analysis of project structures to detect languages, frameworks, entry points, and dependencies across multiple programming languages including Node.js, Python, PHP, Go, Java, and Rust.310 npm1ISC
- AlicenseAqualityDmaintenanceEnables AI assistants to check software end-of-life dates and support status using the endoflife.date API, providing accurate information on software lifecycle, security status, and upgrade recommendations in real-time.58MIT
- AlicenseAqualityBmaintenanceEnables reviewing GitHub Actions workflows for outdated actions, deprecated Node runtimes, retired runners, deprecated commands, and security risks, with file, line, and fix for each finding.3MIT
TDQS
Scored across 3 tools
check_project and check_versions both return EOL status for versions, but their inputs are clearly different (project files vs. explicit version pairs), so ambiguity is low. product_lifecycle is distinct, providing product-level release cycle information rather than checking specific versions. The slight overlap between checking a project's versions and checking explicit versions is resolvable from the descriptions.
Two tools follow a verb_noun pattern (check_project, check_versions) with the same verb 'check', but product_lifecycle is a noun phrase without a verb, breaking the pattern. This is a minor inconsistency, and the names are still readable and intuitive, but a more consistent convention (e.g., get_product_lifecycle) would improve coherence.
With 3 tools, the server is well-scoped for its purpose. Each tool covers a distinct need: scanning project files, checking explicit versions, and retrieving product lifecycle details. There is no redundancy or scope creep, and the count sits comfortably within the ideal 3-15 range.
The tool set covers the core end-of-life checking workflows: scanning project files, checking arbitrary version strings, and exploring a product's release lifecycle. This addresses the primary use cases without obvious dead ends. The only minor gap might be a dedicated single-version lookup, but check_versions handles that trivially by passing one version, so coverage feels complete.