Route a CVE identifier to a triage record

Your dependency scanner reports CVE-2021-44228. The next step is to attach vulnerability evidence to the finding so someone can assess the affected deployment. The cve endpoint returns severity data and linked references for $0.005 USDC per call through x402 on Base mainnet.

The latest catalog change makes that job explicit. Its description now opens with “CVE API for looking up a CVE ID” and names dependency and patch triage as the use case. It also tells callers to send cve_id.

That's the routing change.

For an agent choosing tools from catalog descriptions, the opening now connects a known identifier to a specific task. A request to enrich a dependency finding has a clearer match before the agent reads the full schema.

What changed in the catalog

The rewrite changes services.cve.description in bankr.x402.json. The previous opening said the endpoint looked up a CVE and returned the full NIST NVD vulnerability record. It then introduced cve as a short alias of cve-lookup.

The new opening puts the caller's job first: retrieve vulnerability information for dependency and patch triage. The next sentence names the input directly:

Send cve_id

The revised text also replaces “CVSS scorer” with “CVSS record fetch.” That wording gives a router a more precise instruction: choose this endpoint to retrieve published scoring information associated with a CVE identifier.

The price remains "0.005", denominated in USDC. methods remains ["POST"], and schema.input.required still contains cve_id. The description edit introduces no new request fields or response fields.

Existing callers can keep their request bodies. If you've copied the old catalog description into a tool definition, refresh that text so your agent sees the current task framing.

Keep the request small

Send a JSON body with the CVE identifier: 

{
  "cve_id": "CVE-2021-44228"
}

The identifier is case-insensitive. The handler trims surrounding whitespace and accepts the CVE-YYYY- prefix followed by four to seven digits. A malformed identifier returns HTTP 400; an identifier absent from NVD returns HTTP 404.

Use the response fields according to the decision you're making. cvss_v3_1 contains the available CVSS v3.1 metrics, including vector. cvss_v2 carries the older scoring data when present. The top-level score prefers v3.1 and falls back to v2.

Keep missing values intact. The handler can return null for scoring objects and for score or severity. A downstream ticket generator should preserve that absence instead of turning it into a zero score.

For product matching, inspect affected_cpes. The response includes up to 50 affected CPE strings, while affected_cpe_count reports the count collected before that limit. If the count exceeds the array length, your agent has a partial list to investigate.

Carry the evidence into Prooflayer workflows

A Prooflayer agent can use cve to add context to an existing dependency finding. Keep the returned cve_id attached to the ticket, and retain last_modified so a later review can identify the record timestamp used for triage.

And preserve the reference URLs. The response's references array contains objects with url, alongside source information and tags. A reviewer can follow those links when checking a proposed patch.

Treat public_exploit_known as a signal tied to the returned references. The handler examines up to 20 NVD references for exploit tags or matching exploit-reference URL patterns. A false value means that check found no matching reference within that set. It doesn't establish that exploitation is impossible.

The exploit_summary gives a readable account for the ticket. Keep its claims attached to the structured record, especially when the agent proposes urgency based on a score.

For a dependency review, pair that record with the installed version and deployment exposure before assigning patch priority. Store the CVE evidence beside the local finding so the person approving the change can inspect both.