Skip to main content
Glama

Fetch a file carried by ONE session

arkime_session_file_by_hash
Read-only

Fetch metadata for the file a specific session carried, matched by content hash. Session-scoped to give the correct transfer even if the same file exists elsewhere.

Instructions

Fetch the file one NAMED session carried, by content hash; returns METADATA ONLY.

    Session-scoped, which is the whole difference from arkime_file_by_hash:
    that one serves the most recent body carrying the hash across all
    sessions, so once a file has moved twice it answers about the wrong
    transfer. Prefer this whenever you hold a session id — measured on
    Malcolm v26.07.1, for the window's most-carried md5 this route served
    the body from each of the three sessions that carried it while the
    sibling answered found:false, "No match found." for the same hash. Use
    malcolm_extract_file instead when Zeek carved the file to disk — that
    needs no session, but only works where file extraction is enabled.

    The bytes never enter the response and nothing is written to disk: a
    carved file may be live malware. The md5 and sha256 returned are
    computed over the bytes Arkime actually served, so comparing them with
    the hash you asked for shows whether the reconstructed body is complete.
    A hash this session did not carry is a successful answer with
    found:false, not an error — Arkime's own 400 "No match" — while a body
    over 100 MB is refused, url_only being the way through.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nodeNoCapture node that recorded the session (the `node` field of the arkime_sessions row). Empty resolves it from the session document, one extra request, and is also done for url_only.
url_onlyNoIf true, return only the download URL and skip the download.
file_hashYesContent hash of the carried body: md5 (32 hex chars) or sha256 (64). It lives in this session's own http.md5 / http.sha256, which malcolm_search returns and arkime_session_detail does not (measured on Malcolm v26.07.1: that row carries http.uri but no hash). A hash from a different session is answered "no match" even though the file exists elsewhere.
session_idYesThe session that carried the file, from an arkime_sessions row. This is what makes the answer specific: the same file moving five times has five sessions, and this asks about one of them.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Annotations already mark readOnlyHint=true and destructiveHint=false, but the description goes far beyond: 'The bytes never enter the response and nothing is written to disk', returned hashes are computed over served bytes for completeness verification, found:false is a successful answer rather than error, and bodies over 100 MB are refused. These are non-obvious operational behaviors that an agent needs to know.

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, then systematically covers alternatives and behavioral caveats in distinct paragraphs. It is a bit verbose with repeated 'measured on Malcolm v26.07.1' (also present in the schema), but every sentence carries meaningful information, so it earns a 4 rather than a 3 or 5.

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, the description covers all needed context: session scoping, metadata-only response, found:false semantics, 100 MB limit and url_only workaround, and alternative tools for different scenarios. An output schema exists to document return fields, so the description doesn't need to repeat those details.

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 covers 100% of parameters with detailed descriptions (e.g., file_hash explains md5/sha256 formats and the cross-session 'no match' gotcha; session_id explains its role in scoping). The description adds no additional parameter-specific meaning beyond the schema, so the baseline 3 is appropriate.

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+scope statement: 'Fetch the file one NAMED session carried, by content hash; returns METADATA ONLY.' It clearly differentiates from siblings arkime_file_by_hash (session-scoped vs most-recent-across-sessions) and malcolm_extract_file (Zeek-carved files), making the tool's unique role 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?

Explicit guidance is provided: 'Prefer this whenever you hold a session id' and 'Use malcolm_extract_file instead when Zeek carved the file to disk.' It also explains why this tool beats arkime_file_by_hash with a concrete measured example (served the body for all three sessions vs found:false).

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