Skip to main content
Glama

Profile many fields at once

arkime_spiview
Read-only

Profile top values across several Arkime fields in a single call, returning each field's top values with counts and sum_other_doc_count for missing distribution.

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. Measured on Malcolm v26.07.1, spi=protocols:10 over a window
    holding data returned 0 buckets with recordsFiltered 6,016,935, while
    spi=protocol:10 with no time range returned 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

TableJSON 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: 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.
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
Behavior5/5

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

Annotations only declare readOnlyHint=true and destructiveHint=false, which the description does not contradict. The description adds significant behavioral context beyond annotations: it explains the raw response format, the meaning of sum_other_doc_count, the fact that a field key always appears with an empty bucket list on no aggregate, and how recordsFiltered distinguishes field-name errors from time-range problems. These are non-obvious traits that materially affect how an agent interprets results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded: the first paragraph states purpose and alternatives, the second covers response traits, and the third gives a concrete measured example to disambiguate error cases. Every sentence earns its place, and the multi-paragraph format improves readability for complex behavioral details. It is appropriately sized for the tool's complexity.

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 (multi-field aggregation with subtle edge cases) and the presence of an output schema, the description covers all critical context: what the response contains, how to interpret empty results, and how to distinguish failure modes. The examples with measured values add empirical grounding. Nothing significant is left unexplained for an agent to invoke and evaluate the result correctly.

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?

The input schema already documents all four parameters with 100% coverage and rich descriptions, including the spi storage-path syntax, examples, and epoch-second format for time bounds. The tool description does not add material parameter-level information beyond what the schema provides, so the baseline of 3 applies. It does reinforce the behavior of the count suffix but that is already in 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?

The description clearly states the tool's function: 'Profile top values across SEVERAL Arkime fields at once, each with counts.' It specifies the resource (Arkime fields) and the action (profile top values), and distinguishes it from siblings by explicitly naming alternative tools for different use cases. The verb+resource construction is precise and immediately understandable.

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?

The description provides explicit when-to-use and when-not-to-use guidance: '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.' It also explains the performance benefit ('lighter than running one aggregation per field'), giving the AI agent clear decision criteria.

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

Install Server

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