Dev Facts Check in VS Code

Questions it answers

Check the facts a developer asks for again and again: when a software version reaches end of life, whether the runtimes a repository pins are still supported, what an open-source license is, whether a web feature works in a browser, what an RFC says about itself and what changed between two versions of a package.

Ask "is Node.js 20 still supported?", "is anything in this repo past end of life?", "is the MIT license OSI approved?", "can I use CSS container queries in Safari?", "which RFC obsoletes RFC 2616?" or "what changed in express between 4.18.2 and 5.1.0?".

For a repository, pass the files that pin runtimes (package.json, .nvmrc, .python-version, pyproject.toml, go.mod, a Dockerfile or compose file, .tool-versions, mise.toml, .ruby-version, a Gemfile, composer.json or global.json) and get one row per runtime with its end-of-life date, days left, latest patch and the next supported cycle.

It reads five public sources: endoflife.date for release cycles and support dates, the SPDX License List for license identifiers and OSI and FSF status, webstatus.dev for Baseline status and the first browser version that supports a web feature, the RFC Editor and IETF Datatracker for RFC status, abstracts and obsoleting links, and GitHub releases and changelog files for the notes of each release in a version range.

Every answer names its source and the date of the data. endoflife.date is maintained by volunteers, so confirm a date with the vendor before a contract or compliance decision. A license answer identifies a license and does not say what it lets you do: it is not legal advice.

It does not scan packages for vulnerabilities or health: use the Package Health Check plugin for that.

It stores nothing about you: answers are cached for a few hours and the only lasting record is a daily count of calls per tool.

The idea behind it, in one live picture: how Dev Facts Check works.

What it can do

• Shows whether a version of a product has reached end of life, with its end-of-life and LTS dates
• Lists the release cycles of a product that are still supported, newest first, with the latest patch
• Reads the runtime pins in a repo (Node.js, Python, Go, Ruby, PHP, .NET, Docker images) and flags any past end of life
• Looks up an SPDX license by identifier or name: OSI approved, FSF free, deprecated or not
• Shows the first release of each major browser that supports a web feature, and its Baseline status
• Looks up an RFC by number or title words: status, abstract, and the RFCs that obsolete or update it
• Lists the GitHub release notes of an npm or PyPI package between 2 versions and flags breaking changes
• Names the source and the date of its data in every answer

Tools

• get_eol_status, Get end-of-life status. Use this when the user asks whether a software version is still supported or when it reaches end of life, such as "is Node.js 20 still supported?" or "which Python versions get security fixes?". Pass the product (nodejs, python, ubuntu, postgresql and so on) and optionally a version or release cycle. With a version it returns that cycle's end-of-life date, whether it has passed, LTS dates and the latest patch. Without one it returns the release cycles that are still supported. Data comes from endoflife.date, maintained by volunteers: confirm with the vendor for contract or compliance decisions. Not for package vulnerabilities.
• check_runtime_eol, Check runtime end of life. Use this when you work in a repository and have its runtime pin files open, or the user asks whether a project's runtimes are still supported, such as "is anything in this repo past end of life?" or "is the Node version in our Dockerfile still supported?". Pass each file's name and 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 runtime pin, past end of life first, with the endoflife.date release cycle, its end-of-life date, whether it has passed, days left, the latest patch and the next supported cycle. A range such as >=18 is checked at the oldest version it allows; an image tag such as python:3.11-slim at its version, plus the Debian or Alpine base it names. A pin it cannot match comes back as unmatched with the reason, not as an error. Data comes from endoflife.date, maintained by volunteers. Not for package vulnerabilities.
• check_license, Check a license. Use this when the user asks about an open-source license, such as "is the MIT license OSI approved?" or "what is the SPDX id of Apache License 2.0?". Pass an SPDX identifier or the license name. Returns the SPDX id, full name, whether it is OSI approved, whether the FSF lists it as free, whether the id is deprecated, and the SPDX page. If the name matches several licenses it returns candidates to choose from. It identifies a license and does not say what the license permits or requires. It is not legal advice.
• check_browser_support, Check browser support. Use this when the user asks whether a web platform feature works in browsers, such as "can I use CSS container queries in Safari?" or "is subgrid Baseline?". Pass the feature name or its id. Returns its Baseline status (widely available, newly available or limited), the dates it reached them, and the first version that supports it in Chrome, Edge, Firefox and Safari, including Android and iOS. A browser shown as null has not shipped the feature. If the name is unclear it returns candidate features.
• lookup_rfc, Look up an RFC. Use this when the user asks about an RFC, such as "which RFC obsoletes RFC 2616?" or "find the RFC about WebSocket". Pass either the RFC number, or words from its title (not both). A number returns the title, status, publication date, authors, abstract, and the RFCs it obsoletes, is obsoleted by, updates and is updated by. Title words return up to five matching RFCs with their numbers: call again with a number for the details.
• get_release_notes, Get release notes. Use this when the user asks what changed between two versions of a package, or what to watch for in an upgrade, such as "what changed in express between 4.18.2 and 5.1.0?" or "are there breaking changes from requests 2.28 to 2.32?". Pass the npm or PyPI package name (or a GitHub repo) and fromVersion, the version the user has; toVersion defaults to the latest release. Returns each release after fromVersion up to toVersion, newest first, with its date, link, a short excerpt of its notes and a breaking flag, plus a GitHub compare link. Notes come from GitHub releases and, when those do not reach back far enough, from the repository's changelog file; complete is false when neither covers the whole range. Not for vulnerabilities.

Add Dev Facts Check in VS Code

VS Code reads MCP servers from mcp.json and offers their tools to Copilot Chat in Agent mode. A workspace file at .vscode/mcp.json applies to that project. For every workspace, run MCP: Open User Configuration from the Command Palette and add the same entry there. These steps were checked against the VS Code MCP servers guide on 2026-10-09.

Create or edit the file so it contains this server. VS Code uses a top-level servers object, not mcpServers. Merge it with servers you already have.

{
  "servers": {
    "dev-facts": {
      "type": "http",
      "url": "https://devfacts.openkrill.app/mcp"
    }
  }
}

No command, no headers and no input variables for a key: Dev Facts Check answers without a login. Save the file and select Start above the entry. VS Code asks once whether you trust the server: confirm it. Run MCP: List Servers to check that Dev Facts Check is running. You should see get_eol_status, check_runtime_eol, check_license, check_browser_support, lookup_rfc, get_release_notes.

Open the Chat view, choose Agent mode and ask: Is Node.js 20 still supported, and when does it reach end of life? The Configure Tools button in the chat input lists the tools of each server, and VS Code may ask you to confirm the first call. The server is public and read-only. It sees only the arguments of each call, so do not paste secrets into the question.

Command line users can add it to the user profile in one step with code --add-mcp and the same name, type and url as JSON. The portable .mcp.json at the project root also works in VS Code, with mcpServers as its top-level key. An organization can turn MCP off through Copilot policy: if the MCP commands are missing, ask the admin.

If it does not work

A call checked on 2026-10-11

MIT is an SPDX identifier. The answer is the public license record, not legal advice. The request below was posted to https://devfacts.openkrill.app/mcp as tools/call. HTTP 200. Source: the Dev Facts Check server, read 2026-10-11.

{
  "method": "tools/call",
  "params": {
    "name": "check_license",
    "arguments": {
      "license": "MIT"
    }
  }
}

• status. ok
• asOf. 2026-09-16
• source. SPDX License List (https://spdx.org/licenses)
• notice. Identifies a license and its OSI and FSF status. It does not say what the license permits or requires, and it is not legal advice: read the license text.
• license name. MIT License

Repeat the call yourself if you need a newer reading. Cached answers expire. A rate limit is not a result: wait and try again. Nothing in the call is a ranking, a filing, or advice.

Using it in production

Nothing to install and nothing to run: no package, no Python or Node.js version and no environment variable. Dev Facts Check runs on our servers, and your client only needs the URL https://devfacts.openkrill.app/mcp.

Use it in other apps

• Dev Facts Check in ChatGPT
• Dev Facts Check in Claude
• Dev Facts Check in Cursor
• Dev Facts Check in Pi

Roles that use Dev Facts Check

• Software developer guide

Frequently asked questions

Words on this page

• MCP (Model Context Protocol) definition
• Streamable HTTP transport definition
• Tool primitive definition
• Rate limit policy definition

Source: plugin listing for dev-facts in this repository, and a live tools/call on 2026-10-11. As of 2026-10-11.