Skip to main content
Glama

Read one saved object's query and filters

malcolm_saved_object_detail
Read-only

Resolve a saved Malcolm object into its underlying query, filters, and index pattern. Recover the curated query from a saved search or the search behind a visualization.

Instructions

Read one saved object with its query, filters and index pattern already resolved.

    Use this on a saved SEARCH to recover the query a human curated —
    Malcolm ships 141 of them, and the Arkime-side equivalent is
    arkime_views — and on a visualization to find the search it is built
    from. malcolm_saved_objects lists the catalogue and stops there;
    malcolm_dashboard_export resolves DASHBOARD ids only and answers 200
    with an embedded 404 for a visualization or saved-search id, so for
    those two this is the only route. For the traffic a query matches, take
    the string to malcolm_search or search_dsl.

    Three indirections are followed here instead of being handed back: the
    query sits in kibanaSavedObjectMeta.searchSourceJSON as a JSON *string*
    needing a second parse, the index is a reference NAME that means nothing
    until it is looked up in the object's own references[] array, and the
    query itself is stored in two shapes — a sixth of one install's saved
    searches used the pre-7.x {"query_string": {"query": "..."}} object
    rather than a plain string. `query` is always the string.

    Field names, and which of them appear for which object type, are in the
    output schema. Read `language` before reusing `query`: "lucene" and
    "kuery" are not interchangeable. On this Malcolm the index-pattern
    reference id is the pattern itself ("arkime_sessions3-*"); elsewhere it
    can be a UUID, which this tool resolves with object_type="index-pattern".
    A visualization has no query of its own — `based_on_search` names the
    saved search it inherits one from — and the aggregation and panel-layout
    blobs behind a dashboard come from malcolm_dashboard_export. Raises if
    nothing has that type and id.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
object_idYesThe object's id as malcolm_saved_objects returns it, e.g. "bc940221-83d5-416e-a353-dc8fc2f84141". Ids are not unique across types, so object_type has to match.
object_typeNoThe object's type, one of: search (a curated query, the usual case), visualization, dashboard, index-pattern. A right id with the wrong type reads upstream as no such object.search

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Annotations already indicate readOnly, openWorld, and non-destructive. The description adds substantial behavioral detail: it resolves three indirections (string JSON, reference NAME, two query shapes), explains error behavior ('Raises if nothing has that type and id'), and discusses environment-specific behavior (index-pattern id being the pattern vs a UUID). This goes beyond the annotations' safety hints and reveals internal mechanics.

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?

Although long, the description is densely informative with zero filler. It is front-loaded with the core purpose, then follows a logical flow from usage, to technical indirections, to field semantics, to error behavior. Every sentence contributes unique knowledge needed for correct invocation, and it is well-structured with paragraphs breaking ideas.

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?

With an output schema present, the description doesn't need to list return fields. It covers critical context that is not in the schema: when to use which sibling, what internal transformations happen, why `query` needs careful reading, and what errors occur. For a tool with hidden complexity, this description is exceptionally complete.

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 description coverage is 100%, so baseline is 3. The description enriches parameter understanding by explaining that 'Ids are not unique across types', how object_type affects resolution, and the linkage to malcolm_saved_objects. It also clarifies the semantic meaning of `query` and `language` in the context of the output, adding value over the schema's literal property descriptions.

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: 'Read one saved object with its query, filters and index pattern already resolved.' It clearly distinguishes itself from siblings like malcolm_saved_objects (which only lists) and malcolm_dashboard_export (which only handles dashboards), making it unmistakable what this tool uniquely does.

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?

Provides explicit when-to-use guidance with named alternatives: use for saved searches and visualizations, not for dashboards (use malcolm_dashboard_export), and for traffic use malcolm_search or search_dsl. It also states that for saved-search ids this is the only route, giving strong usage guidance.

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