Skip to main content
Glama

Search Arkime expression fields

arkime_field_search
Read-only

Discover the field spellings Arkime routes accept before writing queries, returning expression, database, type, and group columns with help text.

Instructions

Discover the field names Arkime's routes accept — call before writing one.

    Arkime names the same field more than once, and which spelling a
    parameter wants is decided per PARAMETER, not per tool. This is the
    field-discovery tool for every arkime_* tool, as malcolm_field_search
    is for the malcolm_* ones. Returns "exp | db | type | group" lines with
    the help text. Route the two columns like this:

    - "exp" (ip.src, port.dst, protocols): every `expression` argument, and
      the field lists of arkime_unique, arkime_multiunique and
      arkime_spigraphhierarchy. exp=srcIp,dstIp gets the body "Unknown
      expression srcIp" under HTTP 200 from multiunique and HTTP 403 from
      spigraphhierarchy, so those three parameters reject a db name before
      the request rather than pass it on.
    - "db" (srcIp, dstPort, node): arkime_connections' src_field and
      dst_field, and nothing else. ip.src/dstIp gets HTTP 403 and
      srcIp/port.dst HTTP 500.
    - A THIRD spelling, the storage path, is what arkime_spigraph's field
      and arkime_spiview's spi take. It is the same string as the db column
      for most fields; the few that print a camelCase db alias store under
      a dotted name instead — srcIp is source.ip, dstPort is
      destination.port, totBytes is network.bytes, dstGEO is
      destination.geo.country_iso_code — and the dotted one is what those
      two parameters want.

    A dotted storage path is also accepted wherever the exp column is:
    exp=destination.port returns the same unique lines as exp=port.dst,
    while exp=dstPort returns none. It is the one spelling that answers on
    every route.

    The catalogue is far bigger than a keyword suggests, so the list
    usually stops at `limit` and says "... and N more". Read a field you
    cannot see as "not on this page" rather than absent, and narrow with
    group instead of raising limit.
    

Input Schema

NameRequiredDescriptionDefault
groupNoExact Arkime field group to restrict to, e.g. "http", "dns", "tls", "general". Empty = any group.
limitNoMax fields to return.
keywordNoSubstring matched against the expression name, db name and help text, e.g. "user", "cert", "ja3". Empty = no keyword filter.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.2

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare only readOnly/openWorld/no-destructive, so the description carries real additional load and delivers it: the truncation behavior ('... and N more', list stops at limit), the guidance to narrow with group rather than raise limit, the HTTP 200/403/500 outcomes for mis-spelled fields per route, and the fact that the dotted storage path answers on every route. This is exactly the behavioral context annotations cannot supply.

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 one-line purpose, then organized as a clean exp/db/storage taxonomy. It is dense and longer than typical, but each routing rule maps to a concrete parameter, so almost nothing is padding; a couple of the failure-code asides could be tightened.

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 the description needn't restate return format, and it still explains the column layout ('exp | db | type | group'). Combined with use-before-writing guidance, per-parameter routing, and truncation semantics, an agent has everything needed to call it correctly and interpret the result.

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%, so the baseline is 3, but the description adds genuine semantic value: it explains that 'group' should be used to narrow instead of raising 'limit', and that the returned list is paginated/truncated by 'limit'. It does not elaborate on 'keyword' beyond the schema's substring-matching text.

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 ('Discover the field names Arkime's routes accept') and immediately distinguishes itself from the sibling it parallels ('as malcolm_field_search is for the malcolm_* ones'). An agent can tell exactly what it returns and that it is a discovery prerequisite.

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 ('call before writing an expression') and then routes which column to use per parameter across the arkime_* family, naming the exact consuming parameters (arkime_connections' src_field/dst_field, arkime_spigraph's field, spiview's spi, etc.). It even documents the failure mode of the wrong spelling, so there is no ambiguity about when this tool is the right one.

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