Skip to main content
Glama

Size a session set before acting on it

arkime_sessions_summary
Read-only

Get total sessions, bytes, packets, and per-field breakdowns for any Arkime expression in one call. Use it to size result sets before heavy actions or to avoid count dialect switches.

Instructions

Total sessions, bytes and packets for an expression, plus per-field breakdowns.

    Sizes a result set in one call, before something expensive acts on it.
    It is what arkime_create_hunt's total_sessions wants, in one call and
    in the same dialect — count means a dialect switch, and neither count
    nor arkime_sessions reports bytes or packets. For the matching sessions
    themselves use arkime_sessions, and for a value distribution without
    the totals use arkime_unique or arkime_spiview.

    Returns JSON {"totals", "breakdowns"}: totals carry sessions, bytes,
    dataBytes, packets and the first/last packet timestamps (Arkime's empty
    histogram scaffolding is dropped); each breakdown carries its field name
    and its top values with per-value session/byte/packet counts. An
    expression that matches nothing is a successful answer, not an error:
    the totals read 0 and every field asked for still comes back as a
    breakdown with an empty `data` list — measured with
    "ip == 203.0.113.99" over 1714003200-1714089600. A field Arkime declined
    to break down is listed in ignored_fields rather than passed over in
    silence, since upstream reports it the same way as a field with no
    values.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fieldsNoComma-separated fields to break the totals down by, one breakdown each, e.g. "protocols,ip.dst". Arkime expression names ("ip.src") and dotted ECS names ("source.ip") both work; a db name ("srcIp") is silently ignored upstream and is reported back in ignored_fields. Cannot be empty — Arkime rejects the request without it — so an empty value falls back to protocols.protocols
time_toNoEnd time as EPOCH SECONDS (NOT a dateparser string). Empty = now.
time_fromNoStart time as EPOCH SECONDS (NOT a dateparser string). Empty summarises Arkime's default recent window, which on a historical capture reports zero and looks like a broken tool.
expressionNoArkime expression syntax scoping what is counted, e.g. "protocols == http && ip.dst == 203.0.113.5". Empty counts every session in the window.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Annotations already declare readOnlyHint=true, but the description adds substantial behavioral detail: empty results are successful with zero totals, ignored_fields is returned for fields Arkime declines to break down, and the response format includes specific fields (totals, breakdowns, first/last timestamps). It also warns about the time_from default window on historical captures. This far exceeds the baseline and does not contradict annotations.

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 the core purpose and usage, then details the return format and edge cases. It is longer than typical but each sentence carries meaningful content, including a concrete measurement example to illustrate empty behavior. Slightly verbose but well-structured.

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 moderately complex read-only tool with four parameters and a rich output schema, the description is complete. It covers purpose, usage, return structure, empty-result semantics, ignored fields, and the default window pitfall. The output schema exists, so the detailed return description is a bonus, not a requirement.

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?

Schema coverage is 100%, so the baseline is 3. The description does not directly expand on parameter syntax; its only parameter-related additions are behavioral (e.g., ignored_fields behavior, expression matching nothing). These are more about output semantics than parameter meaning, so the description adds little beyond 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 opens with a specific verb: 'Total sessions, bytes and packets for an expression, plus per-field breakdowns.' It clearly distinguishes this tool from siblings by naming alternatives: 'For the matching sessions themselves use arkime_sessions, and for a value distribution without the totals use arkime_unique or arkime_spiview.' This makes the purpose unmistakable.

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 states when to use this tool ('before something expensive acts on it'), explains why it is preferable to count ('count means a dialect switch, and neither count nor arkime_sessions reports bytes or packets'), and names alternatives with precise conditions. This is exemplary usage guidance.

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