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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "check_runtime_eol"
  }
}

Input 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, global.json, Cargo.toml (rust-version) or rust-toolchain.toml
`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

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.

Changed1 schema field changedNov 4, 2026

changedInput schema / properties / files / description

Previous value: -"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"New value: +"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, global.json, Cargo.toml (rust-version) or rust-toolchain.toml"

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.2/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnly, idempotent, openWorld, non-destructive) by describing the result shape (one row per pin, past-EOL first, with cycle, EOL date, days left, latest patch, next cycle), how ambiguous inputs are resolved (ranges checked at oldest version, image tags at their version plus Debian/Alpine base), and how failures surface (unmatched with a reason). It also discloses the data provenance and volunteer-maintenance caveat, which matters for trusting freshness.

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 triggering question and examples before mechanics, and every later sentence carries information about input or output handling. It is a single dense paragraph that repeats the pin-file enumeration already present in the schema, which is the only slack.

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

Completeness4/5

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

Covers both input branches, resolution edge cases, failure behavior, and data source, which is ample for a two-parameter lookup tool; the output schema means return fields need not be enumerated further. The small mismatch between the description's file list and the schema's file list is the only completeness blemish, and it does not block correct invocation.

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 baseline would be 3, but the description adds real meaning: version syntax accepted (>=18, lts, 3.8.10), the runtime/image naming convention, and the resolution rule for ranges and image tags. Minor inconsistency: its file list omits Cargo.toml and rust-toolchain.toml, which the schema does list.

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 — checking whether a runtime version or a repository's pinned runtimes are past end of life — and anchors it with two concrete user-question examples. It partially differentiates from siblings by excluding package vulnerabilities (check_license), but never mentions the adjacent get_eol_status tool, so an agent must still guess at that boundary.

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 triggering conditions in the form of literal user questions ("is Node 18 past end of life?", "is the Node version in our Dockerfile still supported?") and says how to supply input in each case (runtimes by name/version when no files are open, files with contents when they are). The only gap is the absence of a named alternative for overlapping EOL queries.

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

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.