Skip to main content
Glama

Read one anomaly detector's top anomalies

malcolm_anomaly_results
Read-only

Read which entities one anomaly detector scored as anomalous in a time window, worst first, with run state showing whether it ran or found nothing.

Instructions

Read which entities one anomaly detector scored as anomalous in a window, worst first.

    Use this after malcolm_anomaly_detectors, which reports a single
    anomaly count across every detector and admits it cannot tell "the
    detector ran and found nothing" from "the detector was never started".
    This asks one named detector for its own results and reports its run
    state beside them, which settles that question and names WHICH entity
    was anomalous and WHEN. For signature-based detection use malcolm_alerts
    (Suricata) or malcolm_alerting_alerts (standing OpenSearch rules); this
    is the machine-learning baseline instead.

    TIME HERE IS EPOCH MILLISECONDS, unlike every arkime_* tool, which takes
    seconds. A seconds-shaped value is rejected rather than forwarded:
    upstream it is a window in 1970 that answers empty, indistinguishable
    from clean traffic.

    Returns JSON {"detector_id", "detector_state", "window", "showing",
    "anomalies"}; the shape is in the output schema. Entity buckets are
    passed through unrenamed because their keys follow the detector's own
    category fields, so they differ per detector. No anomalies comes back as
    a sentence that says what the detector's state implies about that
    emptiness. Real-time detector results only; historical analysis tasks
    are not queried.
    

Input Schema

NameRequiredDescriptionDefault
sizeNoMax entity buckets to return, worst first.
orderNoRank buckets by "severity" (highest anomaly grade, the default — the single worst entity) or "occurrence" (most anomalous results — the entity that was odd most often).severity
detector_idYesThe detector's id, returned as `id` by malcolm_anomaly_detectors (e.g. "ExampleOsDocId000002"). Not its name.
end_time_msYesWindow end in EPOCH MILLISECONDS, greater than start_time_ms. Anomalies are placed by the detection interval they were scored in, so widen the window rather than guessing an offset.
start_time_msYesWindow start in EPOCH MILLISECONDS (not seconds — a seconds value is rejected). Multiply an arkime_* timestamp by 1000.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.1
    • changedInput schema / properties / detector_id / description
      Previous value: -"The detector's id, returned as `id` by malcolm_anomaly_detectors (e.g. \"94UZsZ8Bao8axaN3EPyz\"). Not its name."New value: +"The detector's id, returned as `id` by malcolm_anomaly_detectors (e.g. \"ExampleOsDocId000002\"). Not its name."
  2. Addedv1.0.2

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/openWorld/non-destructive, and the description adds genuinely non-redundant behavior: seconds-shaped timestamps are rejected (not silently forwarded), an empty window is returned as a sentence whose meaning depends on detector state, and entity buckets are passed through unrenamed because keys vary per detector. These are real operational traps disclosed ahead of the call.

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?

Front-loaded with the core purpose, then routing, then the time-unit hazard, then return shape. Dense and mostly earns its length, though the returns paragraph retreads ground the output schema already covers and could be tightened to just the passthrough and empty-case notes.

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?

For a read tool with an output schema and full annotations, nothing material is missing: routing, time-unit semantics, empty-result interpretation, and the real-time-only limitation are all covered.

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

Parameters4/5

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

Schema description coverage is 100%, so baseline would be 3, but the description adds cross-tool interop semantics the schema lacks: epoch-milliseconds here versus seconds for every arkime_* tool, with the note to multiply arkime_* timestamps by 1000. Window-widening guidance is a minor addition on top of the schema's own start/end descriptions.

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 specific verb and resource ('read which entities one anomaly detector scored as anomalous in a window, worst first') and immediately frames the scope against siblings — malcolm_anomaly_detectors for per-detector counts, malcolm_alerts/malcolm_alerting_alerts for signature-based detection. An agent can pick this tool without opening another 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?

Explicit sequencing ('use this after malcolm_anomaly_detectors'), an explicit problem the sibling cannot solve (run-state ambiguity), and explicit alternatives for a different detection class (Suricata, OpenSearch rules). It also states the boundary case — real-time only, historical analysis tasks are not queried.

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