Skip to main content
Glama

Read one anomaly detector's top anomalies

malcolm_anomaly_results
Read-only

Get the specific entities a given anomaly detector scored as anomalous in a time window, listed worst first, along with the detector's run state.

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: this Malcolm has no
    historical analysis tasks, and asking for them is a 500.
    

Input Schema

TableJSON 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. "94UZsZ8Bao8axaN3EPyz"). 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

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

The description discloses important behavioral traits beyond the readOnly/openWorld annotations: it reports detector run state alongside anomalies, returns an empty result as a sentence explaining what the detector's state implies, rejects seconds-shaped values rather than forwarding them, and passes through entity bucket keys unrenamed because they vary per detector. It also specifies real-time only and the 500 error for historical queries.

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 longer than average but well-structured and front-loaded with the core purpose. Each paragraph earns its place: sibling differentiation, time-unit warning, return format, and real-time limitation. It is dense but not padded, though some details repeat the schema.

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 tool's moderate complexity (5 params), annotations, output schema, and sibling tools, the description covers everything needed: what it returns, how empty results behave, detector state implications, time-unit pitfalls, and how to distinguish it from alternatives. The output schema handles the exact shape, so the description doesn't need to repeat it.

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?

The schema already covers all parameters with descriptions, so the baseline is 3, but the description adds meaningful usage context: the epoch-milliseconds warning, the instruction to multiply arkime_* timestamps by 1000, and the explanation that seconds values become a 1970 window indistinguishable from clean traffic. This goes beyond the schema's parameter 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?

The description opens with a specific verb and resource: "Read which entities one anomaly detector scored as anomalous in a window, worst first." It clearly distinguishes itself from malcolm_anomaly_detectors (single count per detector), malcolm_alerts, and malcolm_alerting_alerts by framing itself as the machine-learning baseline.

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 usage guidance is provided: use it after malcolm_anomaly_detectors to resolve ambiguity between 'ran and found nothing' versus 'never started.' It names alternatives for signature-based detection (malcolm_alerts, malcolm_alerting_alerts) and states that real-time results only are supported, with historical requests resulting in a 500.

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/nagameTW/mcp-server-malcolm'

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