Skip to main content
Glama

Extract file by hash

arkime_file_by_hash
Read-only

Find whether a known-bad MD5/SHA256 appeared in captured traffic and return the matching transferred file's metadata only (magic, size), not bytes.

Instructions

Extract the transferred file matching a content hash across sessions; returns METADATA ONLY.

    Pivots from a file-hash IOC to the actual bytes: Arkime finds the most
    recent session carrying a body with this hash, resolves the capture node,
    and fetches the file. That "most recent" is the catch — when the same
    file moved several times, this answers about the last transfer, which is
    usually not the one under investigation. Use this to find out whether a
    known-bad hash appeared at all, and arkime_session_file_by_hash to pin
    the answer to a session you already hold — a "no match" here is not
    proof the file is absent, since that route can serve a body this one
    declines. Checks the file-magic and returns metadata
    (magic, size) only — the raw bytes are never put in the MCP response —
    and refuses a file over 100 MB before reading it (use url_only then).
    The hash comes from a session's http.md5 / http.sha256, which
    malcolm_search returns. For the whole session's packets rather than one
    carried file use arkime_session_pcap. Returns whether a match was found
    plus its metadata.
    

Input Schema

NameRequiredDescriptionDefault
url_onlyNoIf true, return only the download URL and skip the download.
file_hashYesThe transferred file's content hash: md5 (32 hex chars) or sha256 (64 hex chars). Taken from a session's http.md5 / http.sha256 field, which malcolm_search returns and arkime_session_detail does not.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.1
    • changedInput schema / properties / file_hash / description
      Previous value: -"The transferred file's content hash: md5 (32 hex chars) or sha256 (64 hex chars). Taken from a session's http.md5 / http.sha256 field, which malcolm_search returns and arkime_session_detail does not (measured on Malcolm v26.07.1)."New value: +"The transferred file's content hash: md5 (32 hex chars) or sha256 (64 hex chars). Taken from a session's http.md5 / http.sha256 field, which malcolm_search returns and arkime_session_detail does not."
  2. Changed1 schema field changedv1.0.2
    • changedInput schema / properties / file_hash / description
      Previous value: -"The transferred file's content hash: md5 (32 hex chars) or sha256 (64 hex chars). Taken from a session's http.md5 / http.sha256 field (see arkime_session_detail)."New value: +"The transferred file's content hash: md5 (32 hex chars) or sha256 (64 hex chars). Taken from a session's http.md5 / http.sha256 field, which malcolm_search returns and arkime_session_detail does not (measured on Malcolm v26.07.1)."
  3. Addedv0.3.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/openWorld/non-destructive, yet the description adds substantial behavioral context beyond them: only metadata (magic, size) is returned and raw bytes never enter the MCP response, a >100 MB file is refused before reading, and the 'most recent session' semantics mean the answer is about the last transfer. It also explains what a negative result does and does not mean.

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 critical fact ('returns METADATA ONLY') is front-loaded and every sentence carries real content, but the prose is dense with nested em-dash asides and quoted fragments that could be restructured for faster scanning. Appropriately sized for the caveats it must convey, if slightly verbose.

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?

An output schema exists so return values needn't be spelled out, and the description still adds the caveats an agent needs (metadata-only payload, size limit, last-transfer semantics, negative-result interpretation, hash provenance). Nothing material is missing for correct invocation.

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 100%, so both parameters are already documented (baseline 3). The description adds operative meaning over the schema: it ties url_only to the 100 MB refusal ('use url_only then') and reinforces where the hash originates (http.md5/http.sha256 from malcolm_search).

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 and resource ('Extract the transferred file matching a content hash across sessions') and immediately scopes the output ('returns METADATA ONLY'). It also names the sibling it is not (arkime_session_file_by_hash) and differentiates related routes (arkime_session_pcap), so an agent can pick it apart from neighbors without opening schemas.

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 ('find out whether a known-bad hash appeared at all'), when-not/alternative ('use arkime_session_file_by_hash to pin the answer to a session you already hold'), and the caveat that a no-match is not proof of absence. It also routes oversized results to url_only.

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