Skip to main content
Glama

Graph top values over time

arkime_spigraph
Read-only

Returns top values for one Arkime field with per-value time series to identify spikes and top talkers.

Instructions

Return top values of ONE Arkime field plus a per-value time-series graph.

    Use for top talkers or spotting a value that spikes over time. For
    distinct values of one field without the graph use arkime_unique; for a
    nested multi-level hierarchy use arkime_spigraphhierarchy; for many
    fields profiled at once use arkime_spiview. Returns the raw Arkime
    spigraph response (top values with time-bucketed counts).

    The bucket width is Arkime's choice, taken from the range asked for and
    not exposed as a parameter — measured on Malcolm v26.07.1: 1 second for a
    10-minute window, 60 seconds from 30 minutes out to 2 days, an hour at
    7 days and wider. Buckets holding no session are left out entirely, so
    a 24-hour window came back as 368 buckets rather than 1,440. Compare
    the shape of two graphs, never their bucket counts.

    An empty items list is HTTP 200 whatever went wrong, but the response
    says which: `recordsFiltered` counts the sessions the expression and
    window matched, before the field is aggregated. Measured on Malcolm v26.07.1,
    field=ip.dst over a window holding data returned 0 items with
    recordsFiltered 6,016,935, while field=destination.ip with no time
    range returned 0 items with recordsFiltered 0. So a non-zero
    recordsFiltered under an empty items list means the FIELD NAME did not
    resolve — re-read the `field` description, the storage-path spelling is
    the usual cause. Only recordsFiltered 0 is a time-range problem: pass
    time_from, since Arkime defaults to a recent-only window that a
    historical capture falls outside.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sizeNoNumber of top values to return. It bounds how many distinct values are graphed, never how many time buckets each one is split into — Arkime decides that from the time range.
fieldYesOne Arkime field named by its STORAGE PATH, e.g. "destination.ip", "protocol", "http.host" — arkime_field_search's db column. NOT the exp column: measured on Malcolm v26.07.1 over one 24-hour window, field=destination.ip, field=protocol and field=http.host each filled the requested size, while field=ip.dst, field=protocols, field=dstIp, field=port.dst and field=dstPort each returned 0 — every one of them HTTP 200, so an empty result is the only signal a name was wrong. The db column is the storage path for all but seventeen fields, which print a camelCase alias (srcIp, dstPort, totBytes, dstGEO) and store under the dotted name (source.ip, destination.port, network.bytes, destination.geo.country_iso_code); pass the dotted one for those.
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?

Beyond the annotations (readOnlyHint=true, destructiveHint=false), it discloses detailed behavioral quirks: bucket width is Arkime's choice with measured values per range, empty items list returns HTTP 200, and recordsFiltered distinguishes field-name errors from time-range problems. This gives the agent crucial diagnostic knowledge for interpreting responses.

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 long but well-structured. The first paragraph front-loads the core purpose and alternatives, while later paragraphs provide essential behavioral and failure-mode details. Each sentence carries useful information, but the length (especially the measured example details) could be trimmed slightly without losing 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?

Given the output schema exists (so return values are externally documented), the description covers all critical usage context: purpose, alternatives, parameter quirks, time-range behavior, field-name resolution pitfalls, and diagnostic interpretation of empty results. It is exceptionally complete for a complex tool with subtle failure modes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already has 100% coverage, but the tool description adds significant extra meaning: explains that `field` uses storage path, not exp column, with concrete measured examples of success and failure; clarifies `time_from` empty means Arkime's recent-only default; and notes `size` bounds distinct values, not time buckets. This goes beyond the schema's own descriptions.

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 sentence states exactly what it does: 'Return top values of ONE Arkime field plus a per-value time-series graph.' It uses a specific verb ('return') and resource ('Arkime field'), and immediately distinguishes itself from siblings by naming arkime_unique, arkime_spigraphhierarchy, and arkime_spiview as alternatives.

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 explicitly says when to use it ('Use for top talkers or spotting a value that spikes over time') and gives clear alternative tools for different use cases: 'For distinct values of one field without the graph use arkime_unique; for a nested multi-level hierarchy use arkime_spigraphhierarchy; for many fields profiled at once use arkime_spiview.'

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