cisa-cybersecurity-mcp-server

cisa_get_alerts

cisa_get_alerts

Read-onlyIdempotent

List what CISA has published recently — its combined advisory feed, its alerts feed, or its ICS advisory feed. Each feed is a rolling window of exactly 30 items with no history, no pagination, and no date-range query, so the window's coverage varies from about a week to about two months depending on the feed. For ICS advisory history beyond the window, use cisa_search_ics_advisories, which covers the full corpus back to 2010.

Input Schema

Name	Required	Description	Default
`feed`	No	Which feed to read: advisories (all.xml, ~8 days of coverage), alerts (alerts.xml, ~8 weeks), or ics (ics-advisories.xml, ~2.5 weeks).	advisories
`limit`	No	Maximum items to return. The 30 ceiling is the upstream window, not a server choice.
`since`	No	Keep only items published on or after this date, YYYY-MM-DD. Filters within the fetched window; it cannot reach back beyond it.

Output Schema

Name	Required	Description
`cap`	No	The limit that was applied.
`feed`	No	The feed that was read.
`error`	No	Present when the call failed. Absent on success.
`items`	No	Items from the fetched window, newest first as published; stale identifies cached fallback.
`shown`	No	Items returned.
`stale`	No	True when refresh failed and this response uses the last cached window.
`notice`	No	Safe retry guidance on refresh failure, or guidance when the since filter excluded every item.
`window`	No	What the fetched window covers.
`feedUrl`	No	The absolute feed URL this window came from.
`feedTitle`	No	The channel title the feed declares.
`fetchedAt`	No	UTC timestamp when this window was successfully fetched.
`truncated`	No	True when the limit capped the returned items.
`windowCaveat`	No	That the feed has no history, no pagination, and no date query.
`effectiveQuery`	No	The since filter as applied, and how many window items it excluded.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 14, 2026

addedInput schema / properties / since / format
```
Added value: +"date"
```

changedInput schema / properties / since / pattern

Previous value: -"^\\d{4}-\\d{2}-\\d{2}$"New value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$"

changedOutput schema / anyOf

Previous value: -[
-  {
-    "not": {
-      "required": [
-        "error"
-      ]
-    },
-    "required": [
-      "feed",
-      "feedUrl",
-      "feedTitle",
-      "items",
-      "window",
-      "windowCaveat"
-    ]
-  },
-  {
-    "required": [
-      "error"
-    ]
-  }
-]New value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "stale",
+      "fetchedAt",
+      "feed",
+      "feedUrl",
+      "feedTitle",
+      "items",
+      "window",
+      "windowCaveat"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / fetchedAt

Added value: +{
+  "description": "UTC timestamp when this window was successfully fetched.",
+  "type": "string"
+}

changedOutput schema / properties / items / description

Previous value: -"Items from the current window, newest first as published."New value: +"Items from the fetched window, newest first as published; stale identifies cached fallback."

changedOutput schema / properties / notice / description

Previous value: -"Guidance when the since filter excluded every item."New value: +"Safe retry guidance on refresh failure, or guidance when the since filter excluded every item."

addedOutput schema / properties / stale

Added value: +{
+  "description": "True when refresh failed and this response uses the last cached window.",
+  "type": "boolean"
+}

Changed1 schema field changedSep 25, 2026

changedOutput schema / properties / items / items / properties / advisoryId / pattern

Previous value: -"^ICS(A|MA)-\\d{2}-\\d{3}-\\d{2}(?:[a-z]|-\\d+)?$"New value: +"^ICS(A|MA)-\\d{2}-\\d{3}-\\d{2}(?:[A-Z]|-\\d+)?$"

First observedSep 20, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint and idempotentHint; the description goes well beyond them by disclosing the fixed 30-item rolling window, absence of history/pagination/date-range querying, and the fact that coverage varies from roughly a week to two months by feed. That is exactly the operational context an agent needs before calling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense sentences, front-loaded with the action and feed options, then the constraint, then the fallback route. No filler and nothing buried.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be described, and the description covers the scope, the rolling-window limitation, and the alternative tool for deeper history. Nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and each parameter already documents its enum values, 30-item ceiling, and windowed-filter behavior, so the baseline is 3. The description adds little param-level detail beyond reiterating the window constraint, and its 'no date-range query' phrasing sits in mild tension with the existence of `since` (the schema resolves this, but the description does not).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource ('List what CISA has published recently') and immediately enumerates the three specific feeds it can read. It also names the sibling cisa_search_ics_advisories, so an agent can distinguish scope without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states both when to use it (recent publication lookup across the three feeds) and when not to (ICS history beyond the rolling window), routing to cisa_search_ics_advisories and noting that it covers the full corpus back to 2010. The 'no pagination, no date-range query' clause further bounds its use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All cisa-cybersecurity-mcp-server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.