Skip to main content
Glama

Search network traffic (Malcolm filters)

malcolm_search
Read-only

Search indexed network traffic using field-based filters and human-readable time ranges, returning matching Malcolm documents.

Instructions

Search Malcolm's indexed network traffic using Malcolm's simple filter dict.

    Use this for field-based filtering with human-readable time ranges. To
    search with Arkime expression syntax instead, or when you need a session
    id to feed arkime_session_pcap / arkime_add_tags afterward, use
    arkime_sessions (only its rows carry that id). For raw OpenSearch DSL,
    use search_dsl. Confirm field names with malcolm_field_search first —
    Malcolm uses non-standard names. Returns the raw Malcolm /mapi/document
    response (matching documents); when nothing matched and a filter names a
    field Malcolm does not index, the correct field name is reported above
    the response.

    Two defaults to know before the first call: with no time_from this
    searches ALL retained history, where malcolm_aggregate covers only the
    last 24 hours; and filter values are matched exactly, so any wildcard or
    substring has to go to search_dsl instead.

    Every document comes back whole, 2 to 3.5 KB of JSON each on Malcolm's
    training data, so 20 conn documents run to about 46,000 characters.
    For counts or top values use malcolm_aggregate, and keep limit small
    when reading documents. When the results fill limit, a "Note:" line
    above the JSON says more may match; Malcolm reports no total.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax documents to return.
doctypeNoTarget index. Empty = the Malcolm network index (Zeek/Suricata); "host"/"beat"* = host/beats logs; "arkime"/"session"* = the Arkime sessions index.
filtersNoJSON object in Malcolm filter syntax (NOT OpenSearch DSL). Values are matched EXACTLY — Malcolm compiles this to a terms query, so wildcards are NOT supported and "*example*" matches only the literal string. Use search_dsl for substring/wildcard matching. Examples: {"event.dataset":"conn"}; {"source.ip":"192.0.2.77"}; {"zeek.dns.query":"ntp.ubuntu.com"}; {"!network.transport":"icmp"} excludes; {"network.direction":["inbound","outbound"]} is OR; {"!related.password":null} means the field must exist. Empty = match all.{}
time_toNoEnd time, dateparser format. Empty = now.
time_fromNoStart time, dateparser format ("2024-01-01", "7 days ago"). Empty = ALL history (this tool's default, unlike malcolm_aggregate which defaults to the last 24 hours).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.0.2
    • changedInput schema / properties / filters / description
      Previous value: -"JSON object in Malcolm filter syntax (NOT OpenSearch DSL). Examples: {\"event.dataset\":\"conn\"}; {\"source.ip\":\"192.0.2.77\"}; {\"event.dataset\":\"dns\",\"zeek.dns.query\":\"*example.com*\"}; {\"!network.transport\":\"icmp\"} excludes; {\"network.direction\":[\"inbound\",\"outbound\"]} is OR; {\"!related.password\":null} means the field must exist. Empty = match all."New value: +"JSON object in Malcolm filter syntax (NOT OpenSearch DSL). Values are matched EXACTLY — Malcolm compiles this to a terms query, so wildcards are NOT supported and \"*example*\" matches only the literal string. Use search_dsl for substring/wildcard matching. Examples: {\"event.dataset\":\"conn\"}; {\"source.ip\":\"192.0.2.77\"}; {\"zeek.dns.query\":\"ntp.ubuntu.com\"}; {\"!network.transport\":\"icmp\"} excludes; {\"network.direction\":[\"inbound\",\"outbound\"]} is OR; {\"!related.password\":null} means the field must exist. Empty = match all."
    • changedInput schema / properties / time_from / description
      Previous value: -"Start time, dateparser format (\"2024-01-01\", \"7 days ago\"). Empty = Malcolm's default recent window."New value: +"Start time, dateparser format (\"2024-01-01\", \"7 days ago\"). Empty = ALL history (this tool's default, unlike malcolm_aggregate which defaults to the last 24 hours)."
  2. Addedv0.3.0
  3. Removedv0.2.0
  4. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only cover read-only/open-world safety, but the description adds substantial operational context: the no-time_from ALL-history default versus malcolm_aggregate's 24h window, exact-value matching semantics, document sizes (~46,000 chars for 20 conn documents), the 'Note:' overflow indicator, and that Malcolm reports no total. This is exactly the kind of behavior an agent needs before calling.

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 purpose and alternatives, and every paragraph addresses a distinct concern (routing, defaults, payload size). It is long and reads as a wall of text, but no sentence is genuinely wasted, so it stays just short of a 5.

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 five-parameter search tool with rich schema and an output schema, the description covers the remaining gaps: sibling disambiguation, prerequisites, defaults, payload sizing, and result-set signaling. Nothing needed to call it correctly is missing.

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 coverage is 100%, so the baseline is 3 and the schema already documents filter syntax and the time_from default. The description still adds value by tying parameters to practical consequences (keep limit small because each document is 2-3.5 KB) and contrasting time_from behavior across sibling tools.

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?

Opens with a specific verb+resource ('Search Malcolm's indexed network traffic using Malcolm's simple filter dict') and immediately distinguishes itself from arkime_sessions and search_dsl. An agent can tell which tool to reach for without opening any 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?

Gives explicit routing rules: use this for field-based filtering with human-readable time ranges, arkime_sessions when Arkime expression syntax or a session id is needed, search_dsl for raw DSL. It even adds a prerequisite ('Confirm field names with malcolm_field_search first') and a when-not (wildcards/substrings must go to search_dsl).

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