Dev Facts Check

Check runtime end of life

check_runtime_eol

Read-onlyIdempotent

Use this when the user asks whether a runtime version or a project's runtimes are still supported, such as "is Node 18 past end of life?" or "is the Node version in our Dockerfile still supported?". Pass runtimes by name and version, such as [{"runtime": "node", "version": "18"}], or the repository's pin files with their contents: package.json, .nvmrc, .node-version, .python-version, pyproject.toml, Pipfile, runtime.txt, go.mod, .go-version, Dockerfile, compose.yaml, .tool-versions, mise.toml, .ruby-version, Gemfile, composer.json or global.json. Returns one row per pin, past end of life first: the endoflife.date release cycle, end-of-life date, whether it passed, days left, latest patch and next supported cycle. A range such as >=18 is checked at its oldest version; an image tag such as python:3.11-slim at its version, plus its Debian or Alpine base. A pin it cannot match comes back as unmatched with the reason. Data comes from endoflife.date, maintained by volunteers. Not for package vulnerabilities.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`files`	No	The repository files that pin runtime versions, each with its name and full contents: package.json, .nvmrc, .node-version, .python-version, pyproject.toml, Pipfile, runtime.txt, go.mod, .go-version, Dockerfile, compose.yaml, .tool-versions, mise.toml, .ruby-version, Gemfile, composer.json or global.json
`runtimes`	No	Runtimes to check by name and version, when no repository files are open, such as [{"runtime": "node", "version": "18"}, {"runtime": "python", "version": "3.8"}]

Output Schema

TableJSON Schema

Name	Required	Description
`asOf`	Yes	Date of the source data when it states one, otherwise the date it was read (UTC, YYYY-MM-DD)
`error`	No	Present when status is not ok: a stable code, what went wrong and what to do next.
`counts`	Yes
`notice`	No
`source`	Yes	Where the data comes from
`status`	Yes
`summary`	Yes	One line: how many pins are past end of life, ending soon, supported and unmatched
`runtimes`	Yes	One row per runtime pin: past end of life first, then ending soon, supported, and unmatched last
`truncated`	Yes	True when the files held more than 60 pins and only the first 60 were checked
`skippedFiles`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 19, 2026

addedInput schema / description

Added value: +"Pass runtimes, files, or both; at least one entry in all"

addedInput schema / properties / runtimes

Added value: +{
+  "description": "Runtimes to check by name and version, when no repository files are open, such as [{\"runtime\": \"node\", \"version\": \"18\"}, {\"runtime\": \"python\", \"version\": \"3.8\"}]",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "runtime": {
+        "description": "Runtime, language or image name as people write it, such as \"node\", \"python\", \"go\", \"ruby\" or \"postgres\"",
+        "maxLength": 60,
+        "minLength": 1,
+        "type": "string"
+      },
+      "version": {
+        "description": "Version or release cycle, such as \"18\", \"3.8.10\", \"1.22\", \">=20\" or \"lts\"",
+        "maxLength": 60,
+        "minLength": 1,
+        "type": "string"
+      }
+    },
+    "required": [
+      "runtime",
+      "version"
+    ],
+    "type": "object"
+  },
+  "maxItems": 20,
+  "minItems": 1,
+  "type": "array"
+}

removedInput schema / required
```
Removed value: -[
-  "files"
-]
```

addedOutput schema / properties / runtimes / items / properties / file / description

Added value: +"The file the pin came from, or \"runtimes\" for a runtime named in the runtimes input"

AddedOct 11, 2026

TDQS

A4.3/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare a safe, idempotent, open-world read, but the description adds return shape (one row per pin, EOL first, cycle, EOL date, passed flag, days left, latest patch, next cycle), error handling (unmatched with reason), data provenance (endoflate.date, volunteer-maintained) and input-evaluation semantics for ranges and image tags. That is substantial behavior beyond the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the trigger condition and quoted examples, then input format, then output. The long enumeration of eighteen pin file names duplicates the schema's own file-name list and could be trimmed, but the rest is dense and free of filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, yet the description still summarizes rows and the unmatched case, which matches the tool's complexity. Optionality of runtimes/files, version syntax, and data source are all covered, so an agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the parameter list is already documented; the description goes further by explaining what a version string means operationally — a range like >=18 is evaluated at its oldest version and an image tag at its version plus its Debian/Alpine base. File names are repeated from the schema, adding little, but the version-resolution semantics are genuinely new meaning.

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?

States a specific verb and resource (check runtime end-of-life) and grounds it with quoted user questions, so the intent is unmistakable. It fails to differentiate from the sibling get_eol_status, which sounds like it covers overlapping ground; a reader cannot tell from the text alone which one to pick.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit trigger phrasing ("is Node 18 past end of life?", "is the Node version in our Dockerfile still supported?") and an exclusion ("Not for package vulnerabilities"), plus the runtimes-vs-files input choice. It does not state when to prefer this over the lookalike sibling get_eol_status.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Dev Facts Check tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.