Skip to main content
Glama

List anomaly detectors

malcolm_anomaly_detectors
Read-only

List OpenSearch anomaly detectors with modeled features and anomaly counts. Use it to see if machine-learning baselines have flagged unusual activity.

Instructions

List OpenSearch anomaly detectors, what each models, and whether any anomalies exist.

    Use this to see what machine-learning baselines Malcolm is maintaining
    over the traffic and whether they have produced anything. It counts
    anomalies across every detector at once; for which entities one named
    detector scored, and when, take its `id` to malcolm_anomaly_results.
    This reads the detector configuration, not the traffic: for the
    underlying documents use malcolm_search, and for Suricata's
    signature-based alerts use malcolm_alerts, which is a different
    detection method entirely.

    Returns JSON {"total", "showing", "recorded_anomalies", "detectors"};
    per-detector fields are in the output schema, minus the aggregation
    definitions behind each feature, which are configuration detail.
    `recorded_anomalies` counts anomalous results across all detectors, NOT
    detector runs. Zero with detectors configured still needs care: a
    detector that was never started produces the same zero.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax detectors to return.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Beyond the readOnlyHint and destructiveHint annotations, the description adds critical context: it reads detector configuration rather than traffic, counts anomalies across detectors (not detector runs), and warns that zero recorded_anomalies can mean a detector never started. This proactively addresses interpretation pitfalls.

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 multi-sentence but every sentence adds distinct value: purpose, usage context, sibling differentiation, output shape, and an important zero-value caveat. It is well-structured and front-loaded, with no 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 output schema exists and the tool has a single well-documented parameter, the description covers all necessary context: what is returned, what is intentionally excluded, how it relates to sibling tools, and how to interpret edge-case results. Nothing critical is missing.

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?

The input schema fully describes the single 'limit' parameter with a clear description ('Max detectors to return.'), so schema coverage is 100%. The description adds no additional parameter semantics, but the baseline of 3 applies because the schema already handles this.

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 what the tool does: lists OpenSearch anomaly detectors, what each models, and whether anomalies exist. It distinguishes itself from siblings by explicitly naming malcolm_anomaly_results for per-detector results, malcolm_search for underlying documents, and malcolm_alerts for signature-based alerts.

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 guidance is provided: use this to see machine-learning baselines and their anomaly outputs; when to use alternatives is clearly stated (e.g., take an id to malcolm_anomaly_results for entity-level scoring, use malcolm_search for traffic, use malcolm_alerts for Suricata alerts). This offers strong when/when-not guidance.

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