Skip to main content
Glama

List indices

list_indices
Read-only

List indices with health, status, and document counts to see what exists before querying. Filter with a pattern to narrow to specific indices, such as arkime_sessions3-* for network traffic.

Instructions

List indices with their health, status, and document count.

    Use this to discover which indices exist before querying one. For the field
    schema (field names and types) of a single index, use index_mapping instead;
    for cluster-wide health rather than per-index status, use cluster_health.
    Returns a JSON array, one object per index, with name, health, status, and doc
    count.

    This reads OpenSearch's index list directly, so Malcolm's own internals
    come back beside the traffic, and most of what is listed holds no
    network data at all (.kibana_1, .opendistro_security, the arkime_*_v*
    config indices, top_queries-*). The traffic is in the arkime_sessions3-*
    indices alone; Arkime opens a new one per day, so their number grows and
    the newest is usually still empty — read "docs.count" rather than the
    name to find the one carrying the capture. A pattern matching nothing
    returns an empty array, not an error. "health" is a shard-replication
    fact and says nothing about whether capture is still arriving —
    malcolm_data_coverage answers that.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
patternNoIndex name or wildcard to match; default "*" returns all. Only matching indices are returned, e.g. "arkime_sessions3-*", which is the narrowing that skips Malcolm's internal indices.*

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

The description goes far beyond the readOnly/destructive annotations, revealing that the tool reads OpenSearch's index list directly, returns internal Malcolm indices, that traffic lives only in arkime_sessions3-* indices, that new indices are empty, and that patterns matching nothing return an empty array. It even clarifies the meaning of 'health' and points to malcolm_data_coverage for capture freshness. No contradiction with annotations.

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?

The description is longer than average but every sentence earns its place, covering purpose, usage, alternatives, return format, data source caveats, and edge-case behavior. It is well-structured, front-loaded with the core function, and uses paragraphs to separate distinct concepts without fluff.

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?

For a tool with one optional parameter and an output schema, the description is exceptionally complete. It explains the return format, how to interpret results (e.g., using docs.count over names), what not to expect (health vs. capture freshness), and directs to related tools for complementary data, fully equipping an agent to use it 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?

The schema already describes the pattern parameter well (100% coverage), so the baseline is 3. However, the description adds valuable behavioral semantics about the parameter: 'A pattern matching nothing returns an empty array, not an error' and explains that a specific pattern skips internal indices, enriching the schema's meaning.

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: 'List indices with their health, status, and document count.' It clearly distinguishes itself from siblings by explicitly naming index_mapping for field schemas and cluster_health for cluster-wide health, making the tool's unique scope unambiguous.

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 usage guidance is provided: 'Use this to discover which indices exist before querying one.' It also states when not to use it, directing to index_mapping and cluster_health for different needs, fulfilling the when/when-not/alternatives criterion perfectly.

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