Skip to main content
Glama
Sign In
nagameTW

mcp-server-malcolm

by nagameTW
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

List indexed PCAP files

arkime_pcap_files
Read-only

List indexed PCAP files with each file's coverage (time span, size, session count) to answer what captures a Malcolm holds and spot gaps.

Instructions

List the PCAP files Arkime has indexed, with each file's coverage.

    Use this to answer "what capture does this Malcolm hold" — which files
    exist, how big they are, how many sessions each carries and the time
    span it covers. That is the file-level view; for the dataset-level view
    (how fresh each sensor is, how many documents per log type) use
    malcolm_data_coverage, and to search the sessions themselves use
    arkime_sessions.

    On one node, an interval between a file's last packet and the next
    file's first is an interval with no captured packets, and no search can
    tell you whether the link was quiet or the capture was down — this list
    is the only place that distinction shows up. Files from different nodes
    overlap in time, so compare within a node. Per-file fields and their
    units are in the output schema.

Input Schema

NameRequiredDescriptionDefault
limitNoMax files to return.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.2

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious interpretive behavior: an interval between one file's last packet and the next file's first means no captured packets (and no search can distinguish a quiet link from a down capture), and files from different nodes overlap in time so comparisons must be within a node. That is real context beyond the annotations, though it stops short of describing result shape or ordering.

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 with the core action, then alternatives, then caveats — a sensible ordering with no filler. It is on the verbose side for a list tool, but each paragraph (routing, gap semantics, node overlap) carries distinct information.

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 and the description correctly delegates per-file fields and units to it. Between the explicit sibling routing, the read-only safety annotations, and the capture-gap caveat, an agent has everything needed to select and interpret this tool.

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?

Only one optional parameter (limit) with 100% schema coverage, so the schema already carries the meaning. The description adds nothing about the limit parameter and instead defers field/unit details to the output schema, which is the correct baseline 3 for a fully documented single parameter.

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 ('List the PCAP files Arkime has indexed') and immediately scopes it as the file-level view. It explicitly names the two siblings it is not (malcolm_data_coverage for dataset-level freshness, arkime_sessions for session search), so 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?

Gives explicit when-to-use framing ('what capture does this Malcolm hold') plus two named alternatives with the conditions that select them: malcolm_data_coverage for the dataset-level view and arkime_sessions to search sessions themselves. Nothing is left to inference.

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

Deploy Server

Other Tools