Skip to content
ToolCargo

A practical MCP workflow

Check CVE aliases against CISA KEV with AI and MCP

Connect ToolCargo OSV and CISA KEV separately. Look up your exact package version in OSV, inspect its advisory records and check each CVE alias against CISA’s validated catalogue snapshot. Keep package affectedness, recorded exploitation and source remediation context as separate evidence.

Built for: Developers and security teams researching dependency advisories and documented exploitation signals.

What to connect

Create a ToolCargo account and use OAuth or an API key with a supported MCP client. Hosted connectors share your plan’s call quota; connect each required MCP endpoint separately. Review provider permissions before starting.

Client setup and test status · Current plans and limits

Run the workflow

  1. 1. Start with the exact package and version

    Call osv_query_package with the package’s registry ecosystem, name and version, then inspect returned advisory IDs with osv_get_vulnerability. Keep affected ranges and CVE aliases from the source. No matching OSV advisory does not establish that the package is safe.

  2. 2. Check each exact CVE alias

    Call cisa_kev_lookup for one literal CVE ID from an advisory. A listed result means CISA records that vulnerability in the returned catalogue snapshot; it does not establish that your installation is affected or compromised. A not_listed result describes only this validated snapshot, not the absence of exploitation or vulnerability.

  3. 3. Keep the source’s distinctions

    Preserve vendor, product, date added, required action and due date as recorded source data. Known ransomware use is a confirmed source signal; Unknown means confirmation is lacking. Optional forensic-triage metadata has its own recorded status. Neither field establishes your asset’s condition or prescribes a personal response.

  4. 4. Research a focused catalogue page

    Use cisa_kev_catalogue with at least one explicit vendor, product, addition-date or ransomware filter. Vendor/product matching uses literal case-insensitive substrings combined with AND, not inferred company identity. Ask for at most twenty records and follow nextCursor explicitly with unchanged filters and limit. A changed snapshot requires restarting the search.

  5. 5. Prepare a dated evidence ledger

    Record catalogue version, release date, snapshotId, fetchedAt and cacheHit alongside each CVE. The tools share a bounded cached copy of the public source feed rather than fetch individual advisory pages. Verify linked source guidance separately and review your actual assets before deciding which actions apply.

A prompt to try

Use ToolCargo OSV to inspect the exact package and version I provide. For each returned advisory, retain its ID, affected-range evidence and CVE aliases. Check each CVE alias with ToolCargo CISA KEV and show listed or not_listed in the dated snapshot. Keep required actions and due dates as attributed CISA source data, with federal context. Distinguish Known and Unknown ransomware use and optional forensic-triage status. Do not infer that my installation is affected, compromised or safe, and do not execute remediation commands.

What a useful result looks like

A source ledger: package/version → advisory ID → CVE alias → CISA listed/not_listed → date added → recorded ransomware/triage status → source action and federal due-date context → catalogue version/release date → snapshotId/fetchedAt/cacheHit. Put unresolved affectedness and source-review questions beside the evidence.

Know the limits

These tools research published metadata; they do not scan assets, verify compromise, install patches or calculate personalized remediation deadlines. CISA due dates describe its published federal remediation context and are not universal deadlines. Absence from either source does not establish safety. Source lists change, and catalogue caching introduces a disclosed delay. Each successful hosted tool call uses the shared ToolCargo allowance, including cache hits; no provider key or paid provider is needed.

Common questions

What is the difference between OSV and CISA KEV?

In this workflow, OSV supplies recorded advisories for a package version, affected-range evidence and advisory aliases. CISA KEV supplies recorded catalogue membership for an exact CVE in a dated snapshot. Use a returned CVE alias to connect the two sources; an OSV advisory ID is not automatically a CVE. Neither source alone proves your installation is affected, exploitable, compromised or safe.

Does CISA listing prove my software is affected?

No. Listing records known exploitation of the CVE. Separately inspect affected versions, your configuration and the source advisory before applying that evidence to your assets.

Does not_listed mean exploitation has never happened?

No. It means the exact CVE is absent from the validated, dated snapshot returned by the tool. An unavailable or invalid catalogue produces an error instead of a negative finding.

Are source due dates deadlines for every organization?

No. They belong to CISA’s published federal remediation context. The connector does not evaluate whether a directive applies to you or calculate asset-specific timelines.

Why can another page require restarting?

The cursor binds the filters, page size and projected snapshot identity. If the source snapshot changes, restart to avoid mixing catalogue versions in one result set.

References and tool documentation

Use the provider’s documentation to check the underlying concepts, and ToolCargo’s references for the exact tools, inputs and limits.

Tool references for this workflow

Continue with the tools

View the main connectorSet up your client

Related workflows