Skip to main content
Glama
Sign In
nagameTW

mcp-server-malcolm

by nagameTW
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

List unique field combinations

arkime_multiunique
Read-only

List distinct value combinations across multiple Arkime fields as plain text to spot port scanners or heavy talkers; scope with an expression and set a limit.

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, and a three-field tuple can run to
    megabytes 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

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

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.8/5.0
Behavior5/5

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

Annotations only cover the safety profile (readOnly, non-destructive, open-world), and the description adds substantial beyond that: output is plain text not JSON, a trailing count line follows truncation, row counts explode multiplicatively with each added field, three-field tuples can be megabytes, and "(no values)" usually signals a time-window miss rather than absent data. This is exactly the operational context annotations cannot supply.

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?

Purpose is front-loaded, followed by sibling routing, output format, and sizing guidance — a logical order. The second paragraph piles several distinct gotchas together and reaches for emphasis ("well past", "megabytes"), which is slightly heavier than needed, but no sentence is wasted.

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 six parameters, an output schema, and a row-explosion failure mode, the description covers everything an agent needs to call it correctly and interpret results, including the truncation contract and the misleading empty-result case. Nothing material 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, but the description earns above that by giving operational meaning to time_from (the "(no values)" symptom maps to needing an explicit start time) and explaining the truncation-plus-count behavior tied to limit. It stops short of full compensation since the field-name syntax and epoch-vs-dateparser distinction are left to the schema.

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?

States a specific verb and resource ("List distinct value COMBINATIONS across a tuple of Arkime fields as plain text") and immediately disambiguates from the three nearest siblings (arkime_unique, arkime_connections, arkime_spigraphhierarchy). An agent can route between these 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?

Explicit alternative selection rules are given for all three sibling cases, plus concrete when-to-use framing ("spotting a host scanning many ports, or a few talkers behind a lot of traffic"). It also prescribes the ordering workflow: scope with expression first, or size the match with arkime_sessions_summary before requesting tuples.

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