---
name: review-recent-vulnerabilities
description: Brief the user on recently indexed or modified CVEs and CWEs, optionally filtered by product, vendor, severity, or date. Use for "what is new", catch-up briefings, and recurring vulnerability round-ups.
---

# Review recent vulnerabilities

Produce a short, scannable briefing from the recently modified end of the
corpus, not an undifferentiated list.

## Workflow

1. Call `list_recent_vulnerabilities`. Narrow with `product`, `vendor`,
   `severity`, `cwe`, `knownExploited`, `publishedAfter`, and `publishedBefore`
   when the user gave you a scope. Leave `status` off unless they asked for a
   lifecycle filter. Resolve a relative date in the user's timezone and submit a
   complete ISO 8601 timestamp with an explicit UTC offset; the boundaries are
   inclusive. Submit only necessary filters; tool arguments are captured for
   service telemetry, so do not include secrets or internal asset names that are
   not needed for the briefing.
2. `product` and `vendor` each work on their own — a vendor with no product is
   a valid narrowing. Both match affected-component rows: `vendor: "Microsoft"`
   means components indexed under Microsoft, not necessarily advisories authored
   or published by Microsoft. An empty vendor-filtered result may mean the corpus
   uses another component-vendor name rather than that it has no recent records.
   Product suggestions require a product, so do not call
   `find_vulnerabilities_by_product` to discover a vendor spelling when none was
   supplied; ask for a product or known spelling.
3. Each page is limited to 20. Use the smallest page that satisfies a short
   briefing; paginate with `cursor` only when the user wants more. Carry
   `nextCursor` forward rather than restarting the call with a larger `limit`.
   The server pages by index recency, so reordering one page by severity does not
   prove corpus-wide priority.
4. Pull detail only for the entries you are going to single out: `okfUri` for
   the full document. When results already share an exact `cweIds` value, call
   `get_vulnerability` for that CWE instead of searching for an identifier you
   already have. Use `search_vulnerabilities` only when no exact weakness is
   present and discovery is still needed.
5. When several entries share a `cweIds` value, group them under that weakness.
   A briefing that names one root cause is more use than five near-identical
   rows.
6. A validation, rate-limit, readiness, or transport failure is not an empty
   page. Report the failure and do not state that there were no recent records.

## Reporting rules

- Order by what deserves attention — known-exploited first, then severity — not
  by index order.
- "Recent" here is ordered by the stored modified timestamp, falling back to
  stored `publishedAt`. The `publishedAfter` and `publishedBefore` filters apply
  only to stored `publishedAt`, which is stamped at corpus intake when ingestion
  supplied no date; it is not a reliable vendor-publication window. Say which
  boundary you used, and note that the newest advisories may not have been
  compiled into the corpus yet.
- Give each entry one line: identifier, what breaks, indexed severity, and
  whether it is known-exploited. Name the severity/CVSS source only for entries
  whose canonical report you read; compact recent rows do not carry that source.
- Do not pad the briefing to a target length. If three records matter, report
  three.