Skip to main content
Glama

Export sessions as CSV

arkime_sessions_csv
Read-only

Export network sessions as compact CSV to cut token usage on large queries. Use for table-readable results like all DNS sessions from a host.

Instructions

Export many sessions as a compact CSV table, one row each.

    Use this when you want a lot of sessions cheaply: CSV costs roughly half
    the tokens of the same rows as JSON, so it suits "show me every DNS
    session this host made" when you intend to read the result as a table.
    Use arkime_sessions instead when you need a session id to drill into
    (this returns none), and arkime_connections for a who-talked-to-whom
    summary.

    Returns raw CSV TEXT with a header row, not JSON. `limit` bounds the
    rows exactly. A request naming a column Arkime does not accept hangs
    rather than failing, so a timeout is reported as a probable `fields`
    problem.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax rows to export.
fieldsNoComma-separated columns, as ECS DOTTED names ("source.ip,destination.port") — the names malcolm_field_search returns, NOT Arkime db names (srcIp) or expression names (ip.src). A name Arkime does not accept is never reported as an error: measured on Arkime 6.6.0 it either comes back as an empty column or the request hangs until it times out. Leave empty for Arkime's default columns, which always work.
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 default recent window.
expressionNoArkime expression syntax to scope the rows, e.g. "ip == 192.0.2.7 && protocols == dns". 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 readOnlyHint annotation, the description discloses that the tool returns raw CSV text (not JSON), that `limit` bounds rows exactly, and that an invalid `fields` name can cause a hang rather than an error, with timeout indicating a fields problem. These are non-obvious behaviors that materially affect invocation and result interpretation.

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 compact yet information-dense: starts with purpose, then usage guidance with alternatives, then return type and behavioral quirks. Every sentence contributes a distinct piece of information, and no filler is present.

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 simple CSV-export purpose and the rich annotations and output schema, the description covers all essential aspects: output format, cost/token advantage, exact row limit, and failure mode. No critical information is missing for an agent to select and invoke it correctly.

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?

Input schema covers 100% of parameter descriptions, including detailed notes on field naming conventions and time formats. The tool description adds useful context about `limit` exactness and the timeout behavior linked to `fields`, which complements the schema without redundancy.

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+resource+format: 'Export many sessions as a compact CSV table, one row each.' It clearly distinguishes the tool from close siblings by stating that arkime_sessions is used when a session id is needed and arkime_connections for a who-talked-to-whom summary.

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?

Explicitly states when to use this tool ('when you want a lot of sessions cheaply') and provides direct alternatives with rationale: arkime_sessions for drilling into a session id (none returned by CSV) and arkime_connections for a summary. This is model 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