Skip to main content
Glama

Get index field mapping

index_mapping
Read-only

Retrieve every field name and OpenSearch type for one index to understand its schema before writing a DSL query. Use exact index name; wildcards return repeated blocks.

Instructions

Return one index's field mapping: every field name and its OpenSearch type.

    Use this to learn what fields an index holds and how they are typed before
    writing a DSL query against it. To list which indices exist rather than inspect
    one index's schema, use list_indices. For Malcolm's non-standard field names
    across all indices, malcolm_field_search is easier than reading raw mappings.
    Returns the raw OpenSearch _mapping response; a non-existent index is
    reported as an error carrying OpenSearch's index_not_found_exception.

    A wildcard returns one mapping block per matching index rather than a
    merged one, and each block repeats the whole schema: "arkime_sessions3-*"
    grows by another block every time Arkime opens a new index. Name ONE index when you only need the schema —
    the blocks are near-identical. The types it reports are OpenSearch's own
    (keyword, long, text), while malcolm_field_search reports Malcolm's names
    for the same fields (string, integer) — so come here only when the
    OpenSearch type is what you need.
    

Input Schema

NameRequiredDescriptionDefault
indexYesExact index name or pattern to fetch the mapping for, e.g. "arkime_sessions3-*". Accepts a wildcard.

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.8/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint), so the bar is lower, yet the description still adds real behavior: wildcard calls return one unmerged block per index with duplicated schemas, non-existent indices fail with OpenSearch's index_not_found_exception, and the returned type vocabulary is OpenSearch's rather than Malcolm's. That is meaningful context beyond structured fields.

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?

Core purpose and alternative routing are front-loaded and easy to scan. The type-vocabulary point is stated twice (mid-paragraph and again in the closing sentence), which is mild redundancy, but the wildcard-growth warning earns its space.

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 single-parameter read tool with annotations and an output schema, the description supplies everything an agent needs: what is returned, how wildcards behave, how errors surface, and when a sibling is preferable. Return-value details are deferred appropriately to the output schema.

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% and the schema already documents 'Exact index name or pattern ... Accepts a wildcard.' The description goes beyond it by explaining the consequence of the wildcard (block-per-index expansion, near-identical repetition) and advising to name ONE index. That is added value, though it stops short of pattern syntax specifics.

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 with scope: 'Return one index's field mapping: every field name and its OpenSearch type.' It explicitly differentiates itself from two named siblings (list_indices for existence, malcolm_field_search for Malcolm's field names), so an agent can separate the three 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?

Gives explicit when-to-use ('before writing a DSL query against it'), explicit when-not ('To list which indices exist ... use list_indices', 'malcolm_field_search is easier than reading raw mappings'), and a final condition selecting the tool ('come here only when the OpenSearch type is what you need'). Routing guidance is complete.

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