Skip to main content
Glama

Graph top values over time

arkime_spigraph
Read-only

Graph top values of one Arkime field with a per-value time-series graph to spot top talkers or value spikes over time.

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: it widens as the range does. Buckets holding
    no session are left out entirely, so a window returns fewer buckets
    than its width divides into. 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. field=ip.dst over a
    window holding data returns 0 items with a non-zero recordsFiltered,
    while field=destination.ip with no time range can return 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

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: field=destination.ip, field=protocol and field=http.host fill the requested size, while field=ip.dst, field=protocols, field=dstIp, field=port.dst and field=dstPort each return 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 a few 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

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.1
    • changedInput schema / properties / field / description
      Previous value: -"One 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."New value: +"One Arkime field named by its STORAGE PATH, e.g. \"destination.ip\", \"protocol\", \"http.host\" — arkime_field_search's db column. NOT the exp column: field=destination.ip, field=protocol and field=http.host fill the requested size, while field=ip.dst, field=protocols, field=dstIp, field=port.dst and field=dstPort each return 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 a few 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."
  2. Changed2 schema fields changedv1.0.2
    • changedInput schema / properties / field / description
      Previous value: -"One Arkime field, e.g. \"ip.dst\", \"protocols\", \"http.host\"."New value: +"One 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."
    • changedInput schema / properties / size / description
      Previous value: -"Number of top values to return."New value: +"Number 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."
  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?

Goes far beyond the readOnlyHint/openWorldHint annotations: explains bucket-width is opaque and range-derived, that empty buckets are omitted (so bucket counts must not be compared), and gives a detailed failure taxonomy (non-zero recordsFiltered under empty items = bad field name; recordsFiltered 0 = time-range problem). This is exactly the operational context annotations cannot carry.

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?

Front-loaded core purpose, then routing, then behavioral caveats. Dense but every paragraph earns its place; the failure-mode block is somewhat long though materially useful. Slight redundancy between description and the field schema text on storage-path spelling.

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?

Output schema exists, so return-format explanation is not required, yet the description still covers the ambiguous cases (empty result, timestamps as epoch seconds, default recent-only window) that an agent must know to call it correctly. Complete for the tool's complexity.

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 already 100%, but the description still adds value: it explains that bucket width is NOT a parameter (widens with range), and reinforces the field-name/spelling trap. It stops short of tying each param in the description, relying mostly on the rich schema, so it is above baseline but not exhaustive at the description level.

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/resource ('Return top values of ONE Arkime field plus a per-value time-series graph') and explicitly differentiates from three siblings (arkime_unique, arkime_spigraphhierarchy, arkime_spiview) by contrasting what each does. An agent can route 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 when-to-use ('top talkers or spotting a value that spikes over time') plus when-to-use-alternatives with named siblings and the condition that selects each. Nothing left to inference.

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