Skip to main content
Glama
Sign In
nagameTW

mcp-server-malcolm

by nagameTW
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

List Arkime cron queries

arkime_crons
Read-only

List Arkime cron queries to view scheduled saved searches and trace which cron job applied tags to session data, including disabled queries.

Instructions

List Arkime's cron queries — saved expressions that re-run on a schedule.

    Use this for two questions. First, the same one arkime_views answers:
    which searches have analysts thought worth keeping. Second, and
    only this tool can answer it: where a tag came from. A cron query
    re-runs its expression every few minutes and stamps its own tags onto
    whatever matches, so those tags sit in session data with nothing in the
    session explaining them — this list is the explanation. For saved
    searches nobody schedules use arkime_views, for named value lists (IOC
    sets) use arkime_shortcuts, and to see the tags actually present in the
    data use malcolm_field_values on the `tags` field.

    Disabled queries are listed too — one switched off last week still
    explains tags already sitting in the data. A deployment with none
    configured gets a plain sentence instead of an empty list; that is an
    answer, not a fault. Per-query
    fields are in the output schema.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.2

TDQS

A4.6/5.0
Behavior4/5

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

The annotations already establish readOnlyHint, openWorldHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral context beyond that: disabled queries are still listed, an empty deployment returns a plain sentence rather than an empty list, and per-query fields are deferred to the output schema. It stops short of pagination or result-volume details, but for a zero-parameter listing tool it discloses the important edge cases.

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 and then structured around usage and edge cases. It is somewhat long for a zero-parameter list tool, but each sentence adds routing, behavioral, or result-shape information. It avoids filler and does not bury the main point.

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?

Given the output schema exists, the description does not need to explain return fields, and it correctly points to the output schema instead. It covers what the tool is, when to use it versus siblings, disabled-query behavior, and empty-deployment behavior, which is complete for this tool's complexity and zero-parameter interface.

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 tool has zero parameters, so there is no parameter semantics for the description to clarify; the baseline for 0 params is 4. The input schema is empty and fully self-describing, and the description appropriately adds no misleading parameter detail.

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: 'List Arkime's cron queries — saved expressions that re-run on a schedule.' It distinguishes cron queries from saved searches and named value lists, so an agent can tell it apart from arkime_views, arkime_shortcuts, and malcolm_field_values without opening other 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?

It explicitly names when to use the tool for two questions, and then routes alternatives: use arkime_views for unscheduled saved searches, arkime_shortcuts for IOC sets, and malcolm_field_values to see tags actually present in the data. The guidance covers both when to use this tool and when to use its siblings.

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