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

TableJSON 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

TableJSON 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 current window, newest first as published.
`shown`	No	Items returned.
`notice`	No	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.
`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.

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?

The description adds significant behavioral context beyond the readOnlyHint and idempotentHint annotations: each feed is a rolling window of exactly 30 items, there is no pagination or date-range query, and coverage varies by feed. This tells the agent exactly what limitations to expect without contradicting the annotations.

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?

The description is two sentences, front-loads the core purpose, and then packs limitations and the alternative into the second sentence. Every sentence earns its place with no repetition or filler.

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?

Given the readOnly/idempotent annotations, the fully documented schema, and the presence of an output schema, the description covers all essential decision-making context: what feeds exist, the rolling-window limitation, and the sibling tool for full-corpus ICS searches. An agent has everything needed to invoke it correctly.

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%, so the schema already documents all three parameters thoroughly, including the feed enum meanings, the limit ceiling, and the since format. The description reinforces the window limitation but does not add substantial parameter meaning beyond what the schema provides.

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?

The description states a specific verb ('List') and resource (CISA's published feeds), and immediately clarifies that the tool covers three distinct feeds. It differentiates itself from cisa_search_ics_advisories by noting the feed window limitation, so an agent can distinguish it from sibling tools.

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?

The description explicitly states when the tool is appropriate ('what CISA has published recently') and when it is not ('no history, no pagination, and no date-range query'). It also names the alternative for ICS history beyond the window, cisa_search_ics_advisories, with coverage details.

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.