Dev Facts Check in ChatGPT

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.

Short questions this server answers, each with a direct answer: Runtime End of Life, License, Browser Support and RFC Lookup.

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 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.
• 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 ChatGPT

ChatGPT does not read a local config file. A custom MCP server is added in the product, and only after developer mode is on. These steps were checked against OpenAI's plugin connect guide and the ChatGPT MCP guide on 2026-10-01. Developer mode can be hidden by a workspace policy, so a Team or Enterprise admin may have to allow it first.

1. Open ChatGPT settings, then Security and login, and turn on Developer mode.
2. Open ChatGPT plugins and select the plus button.
3. Enter a name such as "Dev Facts Check" and a one-line description of what you want it to answer.
4. Under Connection, choose the public endpoint and paste this URL. Include the /mcp path. Do not add a tunnel id: this server is already public.

   https://devfacts.openkrill.app/mcp

5. Create the connection and review the tools ChatGPT lists. You should see get_eol_status, check_runtime_eol, check_license, check_browser_support, lookup_rfc, get_release_notes. The feedback tools on the same server are optional and not required for the lookup.
6. Start a new conversation, add the connection from the tools menu, and ask: Is Node.js 20 still supported, and when does it reach end of life?

No API key and no OAuth client id are required. The server answers without a login. Calls are limited per network and per day, and a limit comes back as a tool error rather than a partial answer. If the tool list is stale after a server change, open the connection and select Refresh, then start a new conversation.

The ChatGPT desktop app, Codex CLI and IDE extension share a different config. In the desktop app, open Settings, then MCP servers, choose Add server, select Streamable HTTP, and paste the same URL. In ~/.codex/config.toml the equivalent is a table named mcp_servers.dev-facts with url = "https://devfacts.openkrill.app/mcp". ChatGPT on the web does not read that file. A published directory listing is also a different path: this page is the developer-mode connection, not a claim that Dev Facts Check is already in the ChatGPT directory.

Treat the server as untrusted until you have read a few answers. A remote MCP server sees the arguments the model sends. Dev Facts Check is read-only and documents what it sends onward on the privacy page.

If it does not work

A call checked on 2026-10-17

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-17.

{
  "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 Claude
• Dev Facts Check in Cursor
• Dev Facts Check in VS Code
• 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-17. As of 2026-10-17.