Workhorse: creates a Sumo Logic search job, waits for completion, returns the first N results, and deletes the job. 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). Token levers: detail=summary (whole-job counts by the AUTO-DETECTED severity field — exact via a side-aggregate with disclosed provenance, or a loud SAMPLE label if that fails — plus a compact histogram and top message signatures; cheapest) | compact (timestamp, level, request_id, _sourcecategory, FULL message, plus method/path/status when present) | full (compact + duration_s/logger/client_ip) | raw (verbatim _raw — logs exactly as the app emitted them, including anything sensitive it logged). See the fields/dedupe/maxMessageChars params for projection, grouping, and the message-length cap. Inline limit max 5000 — use sumo_export_results for bulk (up to 100k to a file).

Scoping in one line: filter WHERE with _sourcecategory=. Severity schemas VARY per system — let sumo_error_digest auto-detect (it discloses what it applied), or run sumo_describe_schema on a new scope and pass filter=. TRACE one request by searching its quoted correlation id with no other filters. Hostname keywords match only request logs — hunt errors by _sourcecategory. Full workflow: the "triage" MCP prompt.

Creates a search job and returns its id WITHOUT waiting. The server background-polls created jobs (keepalive) so the job persists across your tool calls; without that, Sumo cancels jobs after a short idle period. Page results with sumo_get_messages / sumo_get_records; always call sumo_delete_search_job when done. 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).

Polls a search job (and resets a kept job's idle timer). States: NOT STARTED / GATHERING RESULTS (in progress; partial results already pageable) / DONE GATHERING RESULTS / FORCE PAUSED (100k cap hit — results available, truncated) / CANCELLED. For aggregate queries messageCount counts scanned input; recordCount is the result count.

Pages messages of a NON-aggregate search job (aggregate jobs 400 — use sumo_get_records). Page size max 10000. Partial results are pageable while the job is still gathering. Token levers: detail=summary (whole-job counts by the AUTO-DETECTED severity field — exact via a side-aggregate with disclosed provenance, or a loud SAMPLE label if that fails — plus a compact histogram and top message signatures; cheapest) | compact (timestamp, level, request_id, _sourcecategory, FULL message, plus method/path/status when present) | full (compact + duration_s/logger/client_ip) | raw (verbatim _raw — logs exactly as the app emitted them, including anything sensitive it logged). See the fields/dedupe/maxMessageChars params for projection, grouping, and the message-length cap.

Pages records of an AGGREGATE search job (non-aggregate jobs 400 — use sumo_get_messages). Page size max 10000.

Deletes a search job, freeing its slot against the 200-active-jobs org cap. Always delete jobs you created via sumo_create_search_job (or kept with keepJob: true) when done. Deleting an already-gone job is not an error.

Runs a search and streams ALL results (up to the 100,000 server cap) to an NDJSON file on disk, returning the file path — NOT the content. Use this for bulk analysis ("feed the logs to a coding agent") instead of large inline limits. Each line is one flattened log object (metadata + parsed _raw log.* fields). Lines are CHRONOLOGICAL (oldest→newest by _messagetime; the server appends "| sort by _messagetime asc" to non-aggregate queries — a PARTIAL result may not be fully ordered). Aggregate queries export their records instead (one JSON record per line, query order; maxMessages/extract do not apply). If more than 100k messages match, split the time range into multiple exports. 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).

The fastest way to see the SHAPE of matching logs before reading any messages: runs one small "count by " aggregate per dimension (concurrently; every job auto-deleted) and returns a compact ranked table per dimension. Dimensions starting with "_" are native Sumo fields (e.g. _sourcecategory, _sourcehost); anything else is an ABSOLUTE JSON path from the _raw root (e.g. stream, log.levelname, log.status — dots allowed). A dimension that is 100% (none) probably does not exist at that path — run sumo_describe_schema to learn the scope's real fields. Numeric keys match numerically when filtering (num(x) = 404) — some producers emit float-strings like "404.0" (displayed coerced). One failing dimension yields an error line, never a total failure. 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).

One-call triage: finds the scope's severity-signal messages, groups them by normalized signature (timestamps/UUIDs/hex/numbers stripped), and returns the top-N distinct problems with count, first/last occurrence, a sample request_id for cross-referencing, and the _sourcecategory. The severity filter is AUTO-DETECTED per scope (severity schemas VARY per system) and DISCLOSED in the output with a matched-N-of-M line — override with filter=; run sumo_describe_schema on a new/odd scope for paste-ready fragments. Cost: 2 search jobs (3 when string-payload categories are in scope; 1 with filter=), all 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).

Stateless receipt-time monitor for polling loops: returns messages that ARRIVED since your last call plus a new cursor. First call: omit since to get a baseline over lookback (default "15m"). Every response contains a cursor=<epoch ms> line — pass that value as since on the next call and the half-open windows [since, now−settleMargin) tile contiguously with no gaps or duplicates. byReceiptTime is FORCED true and the window ends 180s in the past (settle margin) so late-arriving logs are not skipped — results are complete but ~180s stale. Aggregate queries (| count …) are rejected — use sumo_run_search for those. Token levers: detail=summary (whole-job counts by the AUTO-DETECTED severity field — exact via a side-aggregate with disclosed provenance, or a loud SAMPLE label if that fails — plus a compact histogram and top message signatures; cheapest) | compact (timestamp, level, request_id, _sourcecategory, FULL message, plus method/path/status when present) | full (compact + duration_s/logger/client_ip) | raw (verbatim _raw — logs exactly as the app emitted them, including anything sensitive it logged). See the fields/dedupe/maxMessageChars params for projection, grouping, and the message-length cap.

Shows WHEN things happened: buckets matching messages with | timeslice, counts per bucket split into series (default: the scope's AUTO-DETECTED severity field, disclosed in the output), and renders one compact sparkline + per-bucket counts per series. Use it to spot spikes and onsets before reading messages. The query must be a plain scope — no | aggregation operators (timeslice/count are appended; jobs 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).

Discovers the org's native Sumo Logic Monitors (the 24/7 prod alerting): name, folder path, type, enabled/disabled, current status, trigger types, and notification destinations. Read-only management-API call — no search jobs involved. Requires an access key with the "View Monitors" capability (without it Sumo returns HTTP 403). FOOTGUN: free-text query matching is NAME-ONLY, case-insensitive substring — folder paths are NOT searched (a folder name yields 0 even when monitors live under it). The query syntax also accepts monitorStatus:<Critical|Warning|MissingData|Normal|Disabled> (what the status param wraps). Fired-alert HISTORY is a different question — use sumo_list_alerts.

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).

Thorough schema learner — the deep counterpart to the lite auto-detection inside sumo_error_digest/sumo_trend: STRATIFIED-samples the scope (per category × type/stream stratum, spread across message shapes — never first-N rows), enumerates top-level AND nested JSON keys (fill %, inferred types incl. float-strings, top values; arrays marked []), characterizes string payloads (format + severity-ish token hits) instead of returning an empty schema, breaks fields out per stratum, and closes with RANKED paste-ready severity fragments for the filter= param — each with honest caveats. It PROPOSES, never decides: it applies no filters and persists nothing; record what you confirm in your own memory. Use when a digest disclosed no-signal/zero-match or on first contact with a new system. Job budget: 2-4 aggregate jobs + 1-6 bounded page jobs, all 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).