Skip to main content
Glama

Search Arkime expression fields

arkime_field_search
Read-only

Search Arkime's field catalog to find the correct field names for queries. Returns expression, database, type, and group details to prevent invalid-field errors.

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 — every number measured
    on Malcolm v26.07.1 over one 24-hour window:

    - "exp" (ip.src, port.dst, protocols): every `expression` argument, and
      the field lists of arkime_unique, arkime_multiunique and
      arkime_spigraphhierarchy. exp=ip.src,ip.dst returned 692 multiunique
      rows and 140 spigraphhierarchy table rows; exp=srcIp,dstIp returned
      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. srcIp/dstIp returned a 10-node graph;
      ip.src/dstIp returned 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 4,034 of the 4,051 fields here; the other seventeen print a
      camelCase db alias and 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 returned the same 10,000 unique lines as
    exp=port.dst and exp=network.bytes 5,544, while exp=dstPort returned
    none. It is the one spelling that answers on every route.

    The catalogue is far bigger than a keyword suggests — measured on
    v26.07.1: 4,051 fields, of which 942 match "ip" and 114 match "http" —
    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, of which this deployment has 192, instead of raising
    limit.
    

Input Schema

TableJSON 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

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Annotations only state readOnlyHint=true and destructiveHint=false. The description adds substantial behavioral detail beyond that: the returns format ('exp | db | type | group'), the per-parameter spelling decision, the existence of a third storage-path spelling, encountered error behavior (HTTP 403/500 cases), and pagination behavior ('... and N more'). This is entirely consistent with the annotations and enriches them.

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 lengthy but highly structured and front-loaded with the key purpose. It uses bullet-like sections for the three field spellings (exp, db, third spelling), with tables of examples and error cases. Every sentence carries substantive information or measurement evidence. The complexity of the tool justifies the length; there is no filler.

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?

The description is exceptionally complete for a field-discovery tool. It covers the return format, the central naming ambiguity, per-parameter routing rules, error behavior, pagination, and the recommendation to use group filtering. With an output schema present and three fully described optional parameters, no critical aspect is left unexplained. It even provides concrete measurements and examples to illustrate behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the input schema already has 100% coverage and descriptions for all three parameters, the tool description adds significant behavioral context for 'group' and 'limit'. It mentions the deployment has 192 groups and that narrowing by group is preferable to raising limit, and that the list often stops at limit with '... and N more'. These details clarify how to use the parameters effectively beyond their raw schema definitions.

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 and resource: 'Discover the field names Arkime's routes accept — call before writing one.' This clearly states what the tool does. It also distinguishes itself from the sibling malcolm_field_search by explicitly noting this is the field-discovery tool for every arkime_* tool, parallel to malcolm for malcolm_* tools.

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?

The description gives direct usage guidance: 'call before writing one' and explains exactly when to use this tool (before writing any Arkime expression). It differentiates from malcolm_field_search and provides detailed routing rules for which field spelling each arrow parameter expects. It also advises narrowing with group instead of raising limit when results are truncated.

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