Skip to main content
Glama
Sign In
nagameTW

mcp-server-malcolm

by nagameTW
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Cluster health

cluster_health
Read-only

Report OpenSearch-wide status (green/yellow/red) with node and shard counts to confirm the storage backend is healthy and explain any yellow state.

Instructions

Report OpenSearch cluster health: green/yellow/red status plus node and shard counts.

    This checks the storage backend (OpenSearch) itself, cluster-wide. To check
    whether the Malcolm API is reachable, use malcolm_ping; for the readiness of
    Malcolm's individual services, use malcolm_service_status; for per-index
    status rather than the whole cluster, use list_indices. Returns the raw
    OpenSearch _cluster/health document.

    This is a storage-layer answer only: every shard allocated says nothing
    about whether packets are still being captured or parsed. A healthy
    single-node Malcolm settles at green with unassigned_shards=0, so treat
    yellow as something
    to explain rather than as normal. For whether data is still arriving use
    malcolm_data_coverage; for whether a capture node is dropping packets use
    arkime_node_stats.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.0
  2. Removedv0.2.0
  3. First observedv0.1.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so safety is covered. The description adds valuable behavioral context: it returns the raw _cluster/health document, explains that yellow should not be treated as normal for single-node Malcolm, and warns that shard health does not imply packet capture/parsing health.

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 routing guidance, then interpretation caveats. It is somewhat long and repeats the storage-layer limitation, but each paragraph still provides useful context.

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?

With an output schema already present, the description needn't explain return structure; it instead clarifies scope, alternatives, and interpretation of green/yellow/red in the Malcolm context. That is complete enough for an agent to call this tool 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?

There are 0 parameters, so the baseline is 4. The description properly treats this as a no-argument call and does not invent parameter semantics.

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 states a specific verb and resource: 'Report OpenSearch cluster health: green/yellow/red status plus node and shard counts.' It also explicitly distinguishes this tool from siblings by naming malcolm_ping, malcolm_service_status, and list_indices for adjacent checks.

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?

It gives very explicit routing: use malcolm_ping for API reachability, malcolm_service_status for service readiness, list_indices for per-index status, malcolm_data_coverage for data arrival, and arkime_node_stats for capture node drops. It also states when-not to interpret this as data-flow 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