MCP server
endoflife.date and lookup tools can tell an agent what a dependency's current end-of-life date is. This tells it what changed, since a timestamp it supplies, across every dependency GetEndOfLife tracks.
What it exposes
get_lifecycle_changes(since, toolSlug?, eventTypes?)
Returns every new_cycle, new_patch_release, eol_announced, and eol_date_changed event recorded after since, oldest first, capped at 500 with a truncated flag for paging.
| Param | Type | What it does |
|---|---|---|
| since | string, required | ISO 8601 timestamp. Only events recorded after this instant come back. |
| toolSlug | string, optional | Restrict to one dependency, e.g. "postgresql". Omit to check everything tracked. |
| eventTypes | string[], optional | Restrict to specific event types. Omit for all four listed above. |
list_tracked_tools() takes no arguments. It lists every tracked dependency's slug, name, and category, which is where the values for toolSlug above come from.Examples
Both of these ran against the tool for real, on a local copy of the catalog, not hand-typed.
Everything that changed for one dependency:
{
"name": "get_lifecycle_changes",
"arguments": {
"since": "2026-01-01T00:00:00Z",
"toolSlug": "kubernetes"
}
}{
"count": 3,
"truncated": false,
"changes": [
{ "cycleName": "1.36", "eventType": "new_patch_release",
"payload": { "latestVersion": "1.36.3", "previousVersion": "1.36.2" } },
{ "cycleName": "1.35", "eventType": "new_patch_release",
"payload": { "latestVersion": "1.35.7", "previousVersion": "1.35.6" } },
{ "cycleName": "1.34", "eventType": "new_patch_release",
"payload": { "latestVersion": "1.34.10", "previousVersion": "1.34.9" } }
]
}Only the changes worth an agent's attention, across the whole catalog:
{
"name": "get_lifecycle_changes",
"arguments": {
"since": "2026-01-01T00:00:00Z",
"eventTypes": ["eol_announced", "eol_date_changed"]
}
}{
"count": 7,
"changes": [
{ "toolName": "PostgreSQL", "cycleName": "16", "eventType": "eol_date_changed",
"payload": { "eolFrom": "2028-11-09", "previousEolFrom": "2028-01-01" } },
{ "toolName": "Node.js", "cycleName": "3", "eventType": "eol_announced",
"payload": { "eolFrom": null } },
{ "toolName": "Longhorn", "cycleName": "1.8", "eventType": "eol_announced",
"payload": { "eolFrom": "2026-07-22" } },
{ "toolName": "Neo4j", "cycleName": "2026.05", "eventType": "eol_announced",
"payload": { "eolFrom": "2026-07-08" } },
{ "toolName": "Neo4j", "cycleName": "2026.05", "eventType": "eol_date_changed",
"payload": { "eolFrom": "2026-07-08", "previousEolFrom": null } },
{ "toolName": "OpenBao", "cycleName": "2.5", "eventType": "eol_announced",
"payload": { "eolFrom": "2026-07-14" } },
{ "toolName": "OpenBao", "cycleName": "2.5", "eventType": "eol_date_changed",
"payload": { "eolFrom": "2026-07-14", "previousEolFrom": null } }
]
}PostgreSQL 16's end-of-life date moved from January 2028 to November 2028. A static lookup would show the new date and say nothing about the fact that it moved at all.
Connect
Unauthenticated, read-only, over Streamable HTTP:
https://api.getendoflife.com/mcpMost MCP clients take a URL directly:
{
"mcpServers": {
"getendoflife": {
"url": "https://api.getendoflife.com/mcp"
}
}
}Why a diff, not a lookup
A static lookup answers "what is the date." It cannot answer "did the date move," which is the case that actually breaks an upgrade plan already in flight. This server runs on the same data that drives GetEndOfLife's own email, Slack, Teams, and RSS alerts, exposed directly so an agent doing dependency research, an upgrade audit, or a compliance check can ask for what changed instead of diffing two lookups taken days apart by hand.
Data originates from endoflife.date, diffed and stored by GetEndOfLife. If you only need a current date, that project already answers it well.
Questions
This is new and unauthenticated, so its shape may still change once real usage shows what agents actually need from it. If something breaks, or it's missing a capability you need, say so.