Skip to main content
Glama
nagameTW

mcp-server-malcolm

by nagameTW
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

List unique field combinations

arkime_multiunique
Read-only

List distinct value combinations across a tuple of Arkime fields, such as (source.ip, destination.port) pairs, to spot port scanning or heavy talkers in network session data.

Instructions

List distinct value COMBINATIONS across a tuple of Arkime fields as plain text.

    Like arkime_unique but for a field tuple — e.g. every distinct
    (source.ip, destination.port) pair. Good for spotting a host scanning
    many ports, or a few talkers behind a lot of traffic. For a single field
    use arkime_unique; for a source/destination graph use arkime_connections;
    for a nested hierarchy use arkime_spigraphhierarchy. Returns plain TEXT
    (one combination per line, not JSON).

    "(no values)" with no time range usually means the data predates
    Arkime's default recent window rather than being absent: pass
    time_from. Every field added multiplies the rows, well past the 10,000
    values arkime_unique stops at — measured on Malcolm v26.07.1 over one 24-hour
    window, a two-field tuple returned 22,548 lines and a three-field tuple
    50,817, about 2 MB of text. This tool returns the first `limit` lines
    and ends with a line counting the rest. Scope it with expression first,
    or size the match with arkime_sessions_summary before asking for the
    tuples.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax combinations to return. Arkime sends every one, so the rest are cut here and counted on a last line.
countsNoInclude a per-combination occurrence count (default true).
fieldsYesComma-separated Arkime field names forming the tuple, e.g. "source.ip,destination.port".
time_toNoEnd time as EPOCH SECONDS (NOT a dateparser string). Empty = now.
time_fromNoStart time as EPOCH SECONDS (NOT a dateparser string). Empty = Arkime's recent-only default.
expressionNoOptional Arkime expression syntax to scope the data. Empty = all sessions.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.0
    • addedInput schema / properties / limit
      Added value: +{
+  "default": 1000,
+  "description": "Max combinations to return. Arkime sends every one, so the rest are cut here and counted on a last line.",
+  "maximum": 10000,
+  "minimum": 1,
+  "title": "Limit",
+  "type": "integer"
+}
  2. Addedv0.3.3

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the readOnly/openWorld annotations: discloses the exact output format (plain TEXT, one combination per line, not JSON), the 10,000-value cutoff comparison against arkime_unique, measured row counts and text size at 2- and 3-field tuples, truncation behavior ending with a count line, and the '(no values)' time-range pitfall. This is unusually rich operational context.

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 and example, then routing, then behavior. It is thorough rather than terse; the measured-numbers paragraph is slightly long, but every sentence carries operational value.

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?

Even with an output schema present, the description covers return format, truncation semantics, size expectations, and the misleading-empty-result case, giving an agent everything needed to call it correctly and interpret results.

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?

Schema coverage is 100%, so each parameter is already documented. The description adds the combinatorial blow-up consequence of adding fields and nudges toward time_from for the no-values case, but does not add syntax or format detail beyond the schema for limit, counts, expression, or time fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (List) and resource (distinct value combinations across a tuple of Arkime fields) with a concrete example. It references arkime_unique as the single-field alternative, but sibling differentiation is spread thin across four named siblings rather than sharply delineated.

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?

Explicitly names the alternative for each adjacent case: arkime_unique for single fields, arkime_connections for source/destination graphs, arkime_spigraphhierarchy for nested hierarchy. It also advises scoping with expression first or sizing with arkime_sessions_summary, which is actionable when-to-use guidance.

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

Deploy Server

Other Tools