Skip to main content
Glama

Search Suricata alerts

malcolm_alerts
Read-only

Search Suricata IDS alerts by signature, category, IP, severity, or SID without knowing Malcolm field names. Maps your search terms to the correct fields automatically.

Instructions

Search Suricata alerts with structured parameters, no field knowledge needed.

    Use this instead of malcolm_search when hunting Suricata alerts: it maps
    each argument to the correct Malcolm field for you (you don't need to
    know whether it's suricata.alert.signature or rule.name). It always
    filters event.dataset=alert. These are Suricata IDS alerts, signature
    matches on the wire; three other things on this server are also called
    alerts and are different mechanisms — malcolm_alerting_monitors and
    malcolm_alerting_alerts are the OpenSearch alerting plugin's standing
    rules and their firings, malcolm_anomaly_detectors is its machine-learning
    baseline, and malcolm_create_alert (alerting write class) records a
    finding of your own.

    Behavior: `signature` and `category` are substring searches, which Malcolm
    cannot express in a filter (its filters are exact terms), so this tool
    resolves the substring against the field's 500 most common values first
    and filters on the matches. A substring that matches no recorded value
    returns a message saying so rather than an empty result set — that is the
    difference between "no such signature here" and "no alerts fired". That
    pre-scan is the one place the time range bites: it reads only the last 24
    hours, while the alert search itself covers ALL history when time_from is
    empty, so on a capture older than a day every signature reads as
    unrecorded until you pass time_from.
    Returns the raw Malcolm /mapi/document response (matching alert documents).
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sidNoComma-separated Suricata signature IDs, matched on ECS rule.id (Malcolm renames suricata.alert.signature_id to it).
limitNoMax alerts to return.
actionNoRule action: "allowed" or "blocked" (Suricata drop/reject).
dest_ipNoFilter by destination IP.
time_toNoEnd time, dateparser format. Empty = now.
categoryNoAlert category substring, matched on ECS rule.category (Malcolm normalizes suricata.alert.category to it).
severityNoComma-separated severity levels, e.g. "1,2" (1=high, 2=medium, 3=low).
signatureNoAlert signature substring, e.g. "ET MALWARE", "CVE-2024". Matched on ECS rule.name (Malcolm renames suricata.alert.signature to it).
source_ipNoFilter by source IP.
time_fromNoStart time, dateparser format. Empty searches ALL history, but the signature/category substring pre-scan then sees only the last 24 hours — pass a range when hunting an older signature.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Goes far beyond annotations by disclosing the automatic event.dataset=alert filter, the substring search resolution against 500 common values, the 24-hour time limit on the pre-scan versus full history search, and the raw /mapi/document return format. No contradiction with readOnlyHint=true and destructiveHint=false.

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?

Although longer than typical, every sentence provides essential value: purpose, differentiation, behavior, and return type. The 'Behavior:' section is clearly structured and front-loads the most important usage guidance. No fluff or repetition.

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 tool with 10 optional parameters and many sibling tools, this description covers all necessary aspects: what it does, when to use it, how it differs from siblings, behavioral quirks, and return format. The presence of output schema makes further return details unnecessary. It is fully self-contained for correct selection and invocation.

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?

Schema coverage is 100% with detailed parameter descriptions, but the tool description adds critical behavioral semantics not in the schema: how signature/category substring matching works, the 500-value pre-scan, and the interaction between time_from and the pre-scan window. This goes beyond mere parameter enumeration.

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 begins with 'Search Suricata alerts with structured parameters, no field knowledge needed', which is a specific verb+resource statement. It explicitly differentiates from malcolm_search by stating 'Use this instead of malcolm_search when hunting Suricata alerts' and names sibling alert-related tools to avoid confusion.

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?

Provides explicit guidance on when to use this tool over alternatives ('Use this instead of malcolm_search when hunting Suricata alerts') and clarifies the difference between this and other alert mechanisms (malcolm_alerting_monitors, malcolm_alerting_alerts, malcolm_anomaly_detectors, malcolm_create_alert). It also explains the field-mapping advantage.

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