Skip to main content
Glama

List fired alerts (history) from the System Event Index

sumo_list_alerts
Read-only

Retrieve fired alerts from Sumo Logic and correlate create and resolve events into one entry per alert. Filter by time range, status, or monitor name.

Instructions

Fired-alert HISTORY — the complement to sumo_list_monitors (definitions + current state): queries the documented System Event Index (_index=sumologic_system_events _sourceCategory=alerts) through the standard Search Job API. The index is enabled and searchable by default on Enterprise accounts (the same tier the Search Job API already requires). Alert create and resolve are SEPARATE events — this tool correlates them into one line per fired alert: fired-at, resolved-at (when the resolve event is in range), latest trigger status, and the monitorId + monitor name JOIN KEYS back to sumo_list_monitors. One search job, auto-deleted. Time range: exactly ONE of last (relative, e.g. "15m", "2h"; units s/m/h/d) OR both from and to (ISO-8601 like 2026-07-02T18:28:00, or epoch milliseconds).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoEnd time: ISO-8601 or epoch ms. Requires `from`.
fromNoStart time: ISO-8601 or epoch ms. Requires `to`.
lastNoRelative window ending now, e.g. "15m", "2h", "1d". Mutually exclusive with from/to.
limitNoMax fired alerts returned (default 50).
statusNoClient-side filter on trigger state (e.g. ["Critical","Warning"]; case-insensitive). By default matches the alert's LATEST state — a resolved Critical alert now shows [Normal] and is EXCLUDED. Use statusScope:"ever" for the old lifetime behavior.
timeZoneNoIANA timezone for query-time parsing (default UTC).
statusScopeNoHow `status` matches (default "latest"): "latest" = the alert's current/most-recent state; "ever" = any state seen across its lifetime events.
monitorQueryNoKeyword filter (e.g. a monitor-name fragment), matched full-text against the alert event JSON.
byReceiptTimeNoSearch by receipt time; recommended true for very recent windows (ingestion lag).
Behavior4/5

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

The description adds significant behavioral context beyond the readOnlyHint annotation: it queries the System Event Index, creates an auto-deleted search job, and correlates separate events. No contradictions.

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

Conciseness4/5

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

The description is a single paragraph that efficiently packs all necessary information without redundancy. While not extremely concise, every sentence serves a purpose.

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 no output schema, the description describes the output format (fields like fired-at, resolved-at, join keys). All parameters are covered, and the tool's behavior is fully explained. No obvious gaps.

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

Parameters5/5

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

Every parameter has a schema description, but the tool description provides additional semantics: explains the mutual exclusivity of `last` and `from`/`to`, gives examples for time formats, and clarifies status filtering behavior with `statusScope`. This adds value beyond the schema.

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 clearly states it lists fired-alert history, explicitly distinguishes it from the sibling tool sumo_list_monitors by calling it the complement, and specifies the source index and correlation logic.

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

Usage Guidelines4/5

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

It explains when to use this tool (historical alerts) and mentions Enterprise account requirement, time range constraints, and automatic search job deletion. It indirectly suggests alternatives by referencing sumo_list_monitors for definitions/current state.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mbe24/yokozuna-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server