eol-check-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| EOL_CHECK_TODAY | No | Set to a date in YYYY-MM-DD format to fix "today" for demos and tests. | |
| EOL_CHECK_SNAPSHOT | No | Set to use a specific snapshot file instead of the default cached or bundled snapshot. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_productsA | Lists the products in the endoflife.date snapshot (runtimes, frameworks, databases, operating systems and more), with their ids for use in the other tools. Filter by a search text and/or category. |
| get_cyclesA | Returns every release cycle of a product, newest first, with release date, LTS flag, end of active support, end of security support (end of life), status on the given date, days remaining or overdue, and the latest patch version. |
| check_versionA | Checks one product version: supported, security-only or end-of-life on the given date, with the end dates, days remaining or overdue, the latest patch in that cycle, the newest cycle and the recommended upgrade. Accepts versions as people write them: "8", "8.0.11", "net8.0", "net472", "4.8", "v18.19.0", "lts/hydrogen", "3.12". |
| scan_projectA | Reads project files you pass in (contents, not paths on disk) and reports every runtime and framework it detects (Node.js, .NET and .NET Framework, ASP.NET Core, AngularJS, Angular, React, Next.js, Vue, Python, Django, PostgreSQL, MySQL and more) with its support status, sorted most urgent first, plus a one-paragraph summary. Supported files: package.json, package-lock.json, npm-shrinkwrap.json, angular.json, bower.json, *.csproj / .vbproj / .fsproj, Directory.Build.props, global.json, web.config, packages.config, requirements.txt, pyproject.toml, Pipfile, .python-version, runtime.txt, .nvmrc, .node-version, .tool-versions, Dockerfile / .dockerfile / Containerfile, docker-compose.yml / compose.yaml. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool targets a distinct step of the EOL-checking workflow: enumerating products, fetching release cycles, checking a single version, and scanning project files. There is no overlap; check_version and scan_project differ clearly by input type (single version string vs. file contents).
All four tools follow a clean verb_noun snake_case pattern (list_products, get_cycles, check_version, scan_project). Verbs are chosen precisely to reflect different operations, making the naming predictable and self-documenting.
Four tools is well-scoped for a focused EOL-checking server, with each tool earning its place in the lifecycle. Nothing feels redundant or missing at the count level.
The surface covers discovery, cycle detail, single-version checks, and project scanning, which handles the core workflow end to end. Minor gaps remain, such as no explicit way to enumerate available categories or bulk-check an arbitrary list of versions without a project file.