Skip to main content
Glama
Sign In
nagameTW

mcp-server-malcolm

by nagameTW
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Check capture node health

arkime_node_stats
Read-only

Check Arkime capture node health—packet drops, disk, memory, queues—to verify data trustworthiness before concluding traffic is absent.

Instructions

Report each Arkime capture node's health: drops, disk, memory, queues.

    Use this to decide whether the data can be trusted before concluding
    anything from an absence: a node dropping packets or out of disk has
    gaps that look exactly like "no such traffic". For whether the Malcolm
    services are up at all use malcolm_service_status, and for OpenSearch
    cluster state use cluster_health — this one is about the capture side.

    `packets_dropped` is a running total, not a rate, so a non-zero one is
    history rather than a live fault; `dropped_per_sec` is the rate over
    Arkime's last stats interval, and the `warning` key marks a node losing
    packets right now. Per-node fields are in the output schema.

Input Schema

NameRequiredDescriptionDefault
nodeNoSubstring of a node name to narrow the list, e.g. "upload". Empty = every node.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.1
    • changedInput schema / properties / node / description
      Previous value: -"Substring of a node name to narrow the list, e.g. \"spark\". Empty = every node."New value: +"Substring of a node name to narrow the list, e.g. \"upload\". Empty = every node."
  2. Addedv1.0.2

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already establish the safe read-only, non-destructive profile, so the description correctly spends its budget on interpretation rather than repeating safety. It adds real behavioral context: packets_dropped is a cumulative total vs dropped_per_sec being an interval rate, and the warning key marks an actively failing node.

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?

Front-loaded with the one-line purpose, followed by routing guidance and then field semantics, with no filler sentences. Each paragraph carries a distinct job and the whole thing stays short.

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 per-node fields need no enumeration, and the description still supplies the interpretation the schema cannot (running total vs rate, warning meaning). For a read-only single-parameter tool, nothing an agent needs to call or interpret it is missing.

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 description coverage is 100%, and the single `node` parameter's substring-match and empty-default semantics are fully documented in the schema. The description adds nothing about the parameter, so the baseline 3 applies.

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 ('Report each Arkime capture node's health') and enumerates the dimensions covered (drops, disk, memory, queues). It explicitly distinguishes itself from siblings by naming malcolm_service_status and cluster_health and declaring 'this one is about the capture side.'

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 a concrete decision context: use it to decide whether data can be trusted before concluding anything from an absence, because dropped packets mimic 'no such traffic.' It also routes the agent to the correct alternative tools for adjacent questions (service status, cluster health).

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