Skip to main content
Glama

Profile many fields at once

arkime_spiview
Read-only

Profile top values across several Arkime fields in one call, with per-field counts, to compare distributions without running separate aggregations.

Instructions

Profile top values across SEVERAL Arkime fields at once, each with counts.

    One call covers many fields — lighter than running one aggregation per
    field. For a single field use arkime_unique (plain text) or
    arkime_spigraph (adds a time graph); for distinct field-tuple
    combinations use arkime_multiunique; for a nested drill-down hierarchy
    use arkime_spigraphhierarchy. Returns the raw Arkime spiview response
    (per-field top values with counts).

    Each field also reports sum_other_doc_count, the sessions its listed
    values do not account for; a large one means the top-N hid most of the
    distribution.

    A field always comes back under its own key, with an empty bucket list
    and HTTP 200 when nothing aggregated, so the key's presence proves
    nothing. `recordsFiltered` is what separates the two causes: it counts
    the sessions the expression and window matched, before any field is
    aggregated. spi=protocols:10 over a window holding data returns 0
    buckets with a non-zero recordsFiltered, while spi=protocol:10 with no
    time range can return 0 buckets with recordsFiltered 0. A non-zero
    recordsFiltered under empty buckets means
    that FIELD NAME did not resolve; only recordsFiltered 0 is a time-range
    problem, fixed by passing time_from.
    

Input Schema

NameRequiredDescriptionDefault
spiYesComma-separated Arkime fields named by their STORAGE PATH, each optionally suffixed ":<count>" to cap its values, e.g. "protocol:10,destination.ip:20,http.host" — the same spelling arkime_spigraph's field takes. NOT the exp column: spi=protocol:10, spi=destination.ip:20 and spi=http.host:5 fill their buckets, while spi=protocols:10, spi=ip.dst:20 and spi=dstIp:20 each return an empty bucket list under HTTP 200. For the few fields whose db column is a camelCase alias, pass the dotted storage path instead (source.ip for srcIp, destination.port for dstPort). A field left without the suffix takes Arkime's own default of 10 values, not all of them, and the sessions behind the rest are swept into sum_other_doc_count. Pass a count whenever you need a known depth.
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.1
    • changedInput schema / properties / spi / description
      Previous value: -"Comma-separated Arkime fields named by their STORAGE PATH, each optionally suffixed \":<count>\" to cap its values, e.g. \"protocol:10,destination.ip:20,http.host\" — the same spelling arkime_spigraph's field takes. NOT the exp column: measured on v26.07.1 over one 24-hour window, spi=protocol:10 returned 10 buckets, spi=destination.ip:20 returned 20 and spi=http.host:5 returned 5, while spi=protocols:10, spi=ip.dst:20 and spi=dstIp:20 each returned an empty bucket list under HTTP 200. For the seventeen fields whose db column is a camelCase alias, pass the dotted storage path instead (source.ip for srcIp, destination.port for dstPort). A field left without the suffix takes Arkime's own default of 10 values, not all of them: spi=protocol:10 returned 10 of that field's 52 values (spi=protocol:1000 returns all 52) and swept the remaining 139,902 sessions into sum_other_doc_count. Pass a count whenever you need a known depth."New value: +"Comma-separated Arkime fields named by their STORAGE PATH, each optionally suffixed \":<count>\" to cap its values, e.g. \"protocol:10,destination.ip:20,http.host\" — the same spelling arkime_spigraph's field takes. NOT the exp column: spi=protocol:10, spi=destination.ip:20 and spi=http.host:5 fill their buckets, while spi=protocols:10, spi=ip.dst:20 and spi=dstIp:20 each return an empty bucket list under HTTP 200. For the few fields whose db column is a camelCase alias, pass the dotted storage path instead (source.ip for srcIp, destination.port for dstPort). A field left without the suffix takes Arkime's own default of 10 values, not all of them, and the sessions behind the rest are swept into sum_other_doc_count. Pass a count whenever you need a known depth."
  2. Changed1 schema field changedv1.0.2
    • changedInput schema / properties / spi / description
      Previous value: -"Comma-separated Arkime fields, each optionally suffixed \":<count>\" to cap its values, e.g. \"protocols:10,ip.dst:20,http.host\"."New value: +"Comma-separated Arkime fields named by their STORAGE PATH, each optionally suffixed \":<count>\" to cap its values, e.g. \"protocol:10,destination.ip:20,http.host\" — the same spelling arkime_spigraph's field takes. NOT the exp column: measured on v26.07.1 over one 24-hour window, spi=protocol:10 returned 10 buckets, spi=destination.ip:20 returned 20 and spi=http.host:5 returned 5, while spi=protocols:10, spi=ip.dst:20 and spi=dstIp:20 each returned an empty bucket list under HTTP 200. For the seventeen fields whose db column is a camelCase alias, pass the dotted storage path instead (source.ip for srcIp, destination.port for dstPort). A field left without the suffix takes Arkime's own default of 10 values, not all of them: spi=protocol:10 returned 10 of that field's 52 values (spi=protocol:1000 returns all 52) and swept the remaining 139,902 sessions into sum_other_doc_count. Pass a count whenever you need a known depth."
  3. Addedv0.3.2
  4. Removedv0.3.0
  5. 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 safety (readOnly/openWorld/non-destructive), and the description adds substantial operational context beyond them: sum_other_doc_count meaning, the empty-bucket-list-with-HTTP-200 behavior, and how recordsFiltered distinguishes a field-name resolution failure from a time-range problem (fixable via time_from). This is genuinely diagnostic behavioral detail.

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 purpose and sibling routing are front-loaded, and later sentences earn their place by explaining the non-obvious empty-bucket case. It is nonetheless dense and long, with the recordsFiltered/time_from paragraph bordering on over-explanation for a description whose return shape is covered by an output schema.

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 multi-field profiling tool with a rich schema and an output schema, the description covers purpose, alternatives, aggregation caveats, and the failure-mode diagnosis fully. An agent has everything needed to call it correctly and interpret ambiguous empty results.

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% and the spi parameter is already exhaustively documented in the schema (storage paths, suffixes, default of 10, dotted-path aliases). The description reinforces this and ties spi spelling to the empty-bucket/recordsFiltered diagnostic, adding some value, but most parameter meaning lives in the schema, so it stays near baseline.

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 opening states a specific verb and resource: 'Profile top values across SEVERAL Arkime fields at once, each with counts.' It then explicitly names the siblings it is not (arkime_unique, arkime_spigraph, arkime_multiunique, arkime_spigraphhierarchy) and the conditions that select them, so an agent can pick this tool without opening any other 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?

It gives explicit when-to-use guidance by contrast: single field → arkime_unique/spigraph, field-tuple combos → arkime_multiunique, nested drill-down → arkime_spigraphhierarchy, many fields at once → this tool. Combined with 'lighter than running one aggregation per field,' the selection logic is fully spelled out.

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