Dev Facts Check in Pi

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 Pi

Pi does not speak MCP on its own. The pi-mcp-adapter extension (these steps match version 2.34.0) loads remote servers and keeps their schemas out of the prompt until you ask. Install it once, then restart Pi:

pi install npm:pi-mcp-adapter

Add the server to a shared MCP file. Use .mcp.json in the project if only that project needs Dev Facts Check, or ~/.config/mcp/mcp.json if you want it in every project. Pi also reads ~/.agents/mcp.json. A Pi-only override lives in ~/.pi/agent/mcp.json or .pi/mcp.json and wins over the shared file.

{
  "mcpServers": {
    "dev-facts": {
      "url": "https://devfacts.openkrill.app/mcp",
      "lifecycle": "eager"
    }
  }
}

The url is enough. Do not set command: that field is for a local process. No API key header. lifecycle is eager so Pi connects at startup and can search tool names before the first call. A config that omits it still works: the first call connects. After restart, run /mcp and confirm the server is listed. Ask: Is Node.js 20 still supported, and when does it reach end of life? The adapter should offer get_eol_status, check_runtime_eol, check_license, check_browser_support, lookup_rfc, get_release_notes.

Leave directTools off unless you want those schemas in every turn. With a handful of tools the cost is small. The default proxy is the better fit: search for the tool, then call it. /mcp disable dev-facts writes a project override in .pi/mcp.json without editing the shared file. Run /reload after that change.

Pi will not find this server by scanning Cursor or Claude config unless you run /mcp setup and import it. Putting the url in .mcp.json is the direct path and the one this page tests against. The server is the same public endpoint the other clients use, with the same limits and the same privacy rules.

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 ChatGPT
• Dev Facts Check in Claude
• Dev Facts Check in Cursor
• Dev Facts Check in VS Code

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.