Skip to main content
Glama

List unique field combinations

arkime_multiunique
Read-only

List distinct combinations of Arkime field values to uncover patterns like a host scanning many ports. Returns plain text with counts, scoped by expression or time range.

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. Scope it with expression first, or size the
    match with
    arkime_sessions_summary before asking for the tuples.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
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
Install Server

TDQS

A4.8/5.0
Behavior5/5

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

The description discloses the plain TEXT return format (not JSON), the meaning of '(no values)' with no time range (data predates the default recent window, suggesting time_from), and specific measured performance characteristics (22,548 lines for a 2-field tuple, 50,817 for a 3-field tuple, ~2 MB). These go beyond the readOnlyHint/destructiveHint annotations and provide actionable behavioral 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?

The description is front-loaded with a clear one-sentence summary and then organized into focused paragraphs. While slightly verbose with performance data and troubleshooting, every sentence serves a purpose and there is no filler. The structure aids readability, though a bit more conciseness would make it perfect.

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 tool's complexity (tuple combinations, plain-text output, scalability concerns), the description covers all essential aspects: purpose, alternatives, return format, an edge-case interpretation, and scoping advice. The presence of an output schema is indicated, and the description clarifies the text return format that the schema may not fully convey. It is complete for practical use.

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?

The input schema already covers all 5 parameters with detailed descriptions (100% coverage), so the baseline is 3. The description adds value by giving an example tuple (source.ip,destination.port), explaining the time_from workaround for missing data, and warning that adding fields multiplies rows. This supplements the schema meaningfully, justifying a 4.

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 states it 'List distinct value COMBINATIONS across a tuple of Arkime fields as plain text', which is a specific verb+resource+scope. It explicitly distinguishes from arkime_unique (single field), arkime_connections (source/destination graph), and arkime_spigraphhierarchy (nested hierarchy), making the purpose unambiguous.

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 usage guidance: 'For a single field use arkime_unique; for a source/destination graph use arkime_connections; for a nested hierarchy use arkime_spigraphhierarchy'. It also gives example use cases (spotting a host scanning many ports) and advises scoping with expression or sizing with arkime_sessions_summary, which clarifies when and how to use the tool.

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

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