---
name: cve-jobs
description: "Step-by-step job recipes for the CVE Risk Check MCP server: Check a CVE; Rank several CVEs; Triage dependency vulnerabilities. Use when the user asks things like \"How bad is CVE-2021-44228?\" or \"Which of CVE-2023-4863, CVE-2024-3094 and CVE-2019-0708 should I patch first?\""
license: MIT
---

# CVE Risk Check jobs

Each section below walks through one job with the tools of the `cve` MCP server. The same recipes are MCP prompts (prompts/list) on `https://api.openkrill.app/gateway/mcp`.
Connect the server at `https://cve.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.

## Check a CVE

Job: Check a CVE, with the CVE Risk Check MCP server.

Use the `check_cve` tool for this job.

Work on the user's request. If there is none yet, ask what they need. A request this job handles: "How bad is CVE-2021-44228?"

Steps:
1. Call `check_cve` as a normal MCP tool call, with the request's values in the fields of its inputSchema. It needs `cve`.
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: `{"cve":"CVE-2021-44228"}`
4. For the request "How bad is CVE-2021-44228?", a correct answer looks like this: status ok, priority exploited, the Log4Shell description, a CVSS 3.1 score of 10.0 (critical), a kev entry with the date CISA added it, an EPSS score near 1, and as_of dates for NVD and EPSS.
5. Follow the server's own rules:
   - Use these tools to triage a vulnerability by CVE id, or the dependencies of a project.
   - Call check_cve for one CVE, check_cves for up to 10 at once (most urgent first), list_recent_kev for what CISA recently added to its exploited list, triage_dependencies for a dependency list, and search_oss_security for oss-security mailing list threads about a package or a CVE.
   - Do not ask for source code, tokens or anything but names and versions.
   - Report the priority together with the CVSS score, the KEV status and the EPSS score it rests on, and give the as_of dates.
   - A status of rate_limited or deferred is not an answer about the CVE: say so and offer to try again after retry_after_seconds.
   - A status of not_found means NVD has no such id.
   - A priority of unknown means EPSS could not be read; do not call it routine.
   - For one package's license and maintenance, point to Package Health Check.
   - Show reduce_risk_now first when it is not null, saying the WAF rule lowers risk and does not fix the bug, then fix_first with its steps and proof line, then stay_online, then the verdict, confidence and evidence, then patch_service.line once.
   - Report its verdict as given: it is a passive reading of public banners, so say unknown means the version could not be seen, not that the site is safe.
   - Apart from that verdict, never claim a system is or is not vulnerable, and do not give exploitation instructions.
   - Credit NVD, OSV.dev, CISA and FIRST.
6. If the call fails or the answer looks wrong, tell the user, then report it with `submit_feedback` (kind bug, tool `check_cve`).

## Rank several CVEs

Job: Rank several CVEs, with the CVE Risk Check MCP server.

Use the `check_cves` tool for this job.

Work on the user's request. If there is none yet, ask what they need. A request this job handles: "Which of CVE-2023-4863, CVE-2024-3094 and CVE-2019-0708 should I patch first?"

Steps:
1. Call `check_cves` as a normal MCP tool call, with the request's values in the fields of its inputSchema. It needs `cves`.
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: `{"cves":["CVE-2023-4863","CVE-2024-3094","CVE-2019-0708"]}`
4. For the request "Which of CVE-2023-4863, CVE-2024-3094 and CVE-2019-0708 should I patch first?", a correct answer looks like this: count 3, a counts object per priority, and the results ordered with exploited CVEs first, each with CVSS, kev and EPSS fields.
5. Follow the server's own rules:
   - Use these tools to triage a vulnerability by CVE id, or the dependencies of a project.
   - Call check_cve for one CVE, check_cves for up to 10 at once (most urgent first), list_recent_kev for what CISA recently added to its exploited list, triage_dependencies for a dependency list, and search_oss_security for oss-security mailing list threads about a package or a CVE.
   - Do not ask for source code, tokens or anything but names and versions.
   - Report the priority together with the CVSS score, the KEV status and the EPSS score it rests on, and give the as_of dates.
   - A status of rate_limited or deferred is not an answer about the CVE: say so and offer to try again after retry_after_seconds.
   - A status of not_found means NVD has no such id.
   - A priority of unknown means EPSS could not be read; do not call it routine.
   - For one package's license and maintenance, point to Package Health Check.
   - Show reduce_risk_now first when it is not null, saying the WAF rule lowers risk and does not fix the bug, then fix_first with its steps and proof line, then stay_online, then the verdict, confidence and evidence, then patch_service.line once.
   - Report its verdict as given: it is a passive reading of public banners, so say unknown means the version could not be seen, not that the site is safe.
   - Apart from that verdict, never claim a system is or is not vulnerable, and do not give exploitation instructions.
   - Credit NVD, OSV.dev, CISA and FIRST.
6. If the call fails or the answer looks wrong, tell the user, then report it with `submit_feedback` (kind bug, tool `check_cves`).

## Triage dependency vulnerabilities

Job: Triage dependency vulnerabilities, with the CVE Risk Check MCP server.

Use the `triage_dependencies` tool for this job.

Work on the user's request. If there is none yet, ask what they need. A request this job handles: "Which dependencies in this package-lock.json should I fix first?"

Steps:
1. Call `triage_dependencies` as a normal MCP tool call, with the request's values in the fields of its inputSchema.
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: `{"packages":[{"ecosystem":"maven","name":"org.apache.logging.log4j:log4j-core","version":"2.14.1"}]}`
4. For the request "Which dependencies in this package-lock.json should I fix first?", a correct answer looks like this: status ok, a summary line, counts per priority, and fix_first holding the 3 most urgent vulnerable packages, each with a priority, a one-line why, CVE ids, fixed_in and a fix line such as Upgrade lodash from 4.17.15 to 4.17.21.
5. Follow the server's own rules:
   - Use these tools to triage a vulnerability by CVE id, or the dependencies of a project.
   - Call check_cve for one CVE, check_cves for up to 10 at once (most urgent first), list_recent_kev for what CISA recently added to its exploited list, triage_dependencies for a dependency list, and search_oss_security for oss-security mailing list threads about a package or a CVE.
   - For triage_dependencies pass the file text as manifest (a lockfile such as package-lock.json, pnpm-lock.yaml, yarn.lock, poetry.lock, uv.lock, Cargo.lock or go.sum gives exact versions) or a packages list; report fix_first as is, with each fix line and why, and mention not_triaged, skipped and message when present.
   - Do not ask for source code, tokens or anything but names and versions.
   - Report the priority together with the CVSS score, the KEV status and the EPSS score it rests on, and give the as_of dates.
   - A status of rate_limited or deferred is not an answer about the CVE: say so and offer to try again after retry_after_seconds.
   - A status of not_found means NVD has no such id.
   - A priority of unknown means EPSS could not be read; do not call it routine.
   - A CVE lookup does not know which software the user runs; triage_dependencies does, but only by exact package version, so say that it cannot show whether the code reaches the vulnerable part.
   - For one package's license and maintenance, point to Package Health Check.
   - Show reduce_risk_now first when it is not null, saying the WAF rule lowers risk and does not fix the bug, then fix_first with its steps and proof line, then stay_online, then the verdict, confidence and evidence, then patch_service.line once.
   - Report its verdict as given: it is a passive reading of public banners, so say unknown means the version could not be seen, not that the site is safe.
   - Apart from that verdict, never claim a system is or is not vulnerable, and do not give exploitation instructions.
   - Credit NVD, OSV.dev, CISA and FIRST.
6. If the call fails or the answer looks wrong, tell the user, then report it with `submit_feedback` (kind bug, tool `triage_dependencies`).