--- name: dev-facts-jobs description: "Step-by-step job recipes for the Dev Facts Check MCP server: Get end-of-life status; Get release notes; Check a license. Use when the user asks things like \"Is Node.js 20 still supported and when does it reach end of life?\" or \"What changed in express between 4.18.2 and 4.21.2? Anything breaking?\"" license: MIT --- # Dev Facts Check jobs Each section below walks through one job with the tools of the `dev-facts` MCP server. The same recipes are MCP prompts (prompts/list) on `https://api.openkrill.app/gateway/mcp`. Connect the server at `https://devfacts.openkrill.app/mcp` in your MCP client settings (remote streamable HTTP, no key), then call its tools as normal tool calls. They are not command line programs: Bash, curl and scripts cannot reach them. ## Get end-of-life status Job: Get end-of-life status, with the Dev Facts Check MCP server. Use the `get_eol_status` tool for this job. Work on the user's request. If there is none yet, ask what they need. A request this job handles: "Is Node.js 20 still supported and when does it reach end of life?" Steps: 1. Call `get_eol_status` as a normal MCP tool call, with the request's values in the fields of its inputSchema. It needs `product`. 2. If a value the tool needs is missing and you cannot tell it from the request, ask the user one short question first. 3. This input is known to work; copy its format, not its values: `{"product":"nodejs"}` 4. For the request "Is Node.js 20 still supported and when does it reach end of life?", a correct answer looks like this: status ok with release cycle 20, its end-of-life date and whether that date has passed, the LTS dates, the latest 20.x patch, the cycles still supported, and the endoflife.date source with the as-of date. 5. Follow the server's own rules: - Use these tools for developer reference facts: get_eol_status for support and end-of-life dates of a software product or version, check_runtime_eol for the runtime versions a repository pins when you have its files open (package.json, .nvmrc, .python-version, pyproject.toml, go.mod, Dockerfile, .tool-versions and similar) or for runtimes named by version, such as node 18 and python 3.8, check_license for an SPDX license's identifier and OSI or FSF status, check_browser_support for Baseline status and browser versions of a web platform feature, lookup_rfc for an RFC by number or by words in its title, and get_release_notes for what changed in a package or GitHub repository between the version the user has and a newer one. - When a result has status not_found, ambiguous or version_not_found, read error.hint and the candidates, then call again with one of them instead of guessing. - Always give the source and asOf date with the answer. endoflife.date is community maintained: say so when the answer drives a decision. - A license answer is not legal advice and says nothing about what a license permits. - Do not use these tools for package vulnerabilities or package health: say this plugin does not cover them. 6. If the call fails or the answer looks wrong, tell the user, then report it with `submit_feedback` (kind bug, tool `get_eol_status`). ## Get release notes Job: Get release notes, with the Dev Facts Check MCP server. Use the `get_release_notes` tool for this job. Work on the user's request. If there is none yet, ask what they need. A request this job handles: "What changed in express between 4.18.2 and 4.21.2? Anything breaking?" Steps: 1. Call `get_release_notes` as a normal MCP tool call, with the request's values in the fields of its inputSchema. It needs `fromVersion`. 2. If a value the tool needs is missing and you cannot tell it from the request, ask the user one short question first. 3. This input is known to work; copy its format, not its values: `{"name":"express","fromVersion":"4.18.2","toVersion":"4.21.2"}` 4. For the request "What changed in express between 4.18.2 and 4.21.2? Anything breaking?", a correct answer looks like this: status ok with the express releases after 4.18.2 up to 4.21.2, newest first, each with its date, link and a short excerpt of its notes, the breaking versions if any, complete true, a GitHub compare link, and the source with the as-of date. 5. Follow the server's own rules: - Use these tools for developer reference facts: get_eol_status for support and end-of-life dates of a software product or version, check_runtime_eol for the runtime versions a repository pins when you have its files open (package.json, .nvmrc, .python-version, pyproject.toml, go.mod, Dockerfile, .tool-versions and similar) or for runtimes named by version, such as node 18 and python 3.8, check_license for an SPDX license's identifier and OSI or FSF status, check_browser_support for Baseline status and browser versions of a web platform feature, lookup_rfc for an RFC by number or by words in its title, and get_release_notes for what changed in a package or GitHub repository between the version the user has and a newer one. - When get_release_notes returns complete false, say the notes are partial and give compareUrl. - When a result has status not_found, ambiguous or version_not_found, read error.hint and the candidates, then call again with one of them instead of guessing. - Always give the source and asOf date with the answer. endoflife.date is community maintained: say so when the answer drives a decision. - A license answer is not legal advice and says nothing about what a license permits. - Do not use these tools for package vulnerabilities or package health: say this plugin does not cover them. 6. If the call fails or the answer looks wrong, tell the user, then report it with `submit_feedback` (kind bug, tool `get_release_notes`). ## Check a license Job: Check a license, with the Dev Facts Check MCP server. Use the `check_license` tool for this job. Work on the user's request. If there is none yet, ask what they need. A request this job handles: "Is the MIT license OSI approved and what is its SPDX id?" Steps: 1. Call `check_license` as a normal MCP tool call, with the request's values in the fields of its inputSchema. It needs `license`. 2. If a value the tool needs is missing and you cannot tell it from the request, ask the user one short question first. 3. This input is known to work; copy its format, not its values: `{"license":"MIT"}` 4. For the request "Is the MIT license OSI approved and what is its SPDX id?", a correct answer looks like this: status ok with id "MIT", the name "MIT License", osiApproved true, fsfLibre true, deprecated false, the SPDX page link and the note that this is not legal advice. 5. Follow the server's own rules: - Use these tools for developer reference facts: get_eol_status for support and end-of-life dates of a software product or version, check_runtime_eol for the runtime versions a repository pins when you have its files open (package.json, .nvmrc, .python-version, pyproject.toml, go.mod, Dockerfile, .tool-versions and similar) or for runtimes named by version, such as node 18 and python 3.8, check_license for an SPDX license's identifier and OSI or FSF status, check_browser_support for Baseline status and browser versions of a web platform feature, lookup_rfc for an RFC by number or by words in its title, and get_release_notes for what changed in a package or GitHub repository between the version the user has and a newer one. - When a result has status not_found, ambiguous or version_not_found, read error.hint and the candidates, then call again with one of them instead of guessing. - Always give the source and asOf date with the answer. endoflife.date is community maintained: say so when the answer drives a decision. - A license answer is not legal advice and says nothing about what a license permits. - Do not use these tools for package vulnerabilities or package health: say this plugin does not cover them. 6. If the call fails or the answer looks wrong, tell the user, then report it with `submit_feedback` (kind bug, tool `check_license`).