Skip to main content
Glama
Sign In
nagameTW

mcp-server-malcolm

by nagameTW
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Export OpenSearch dashboard

malcolm_dashboard_export
Read-only

Exports a dashboard's full saved-object JSON from its ID, including panel layout, to inspect how a shipped OpenSearch Dashboards dashboard is built.

Instructions

Export one OpenSearch Dashboards dashboard as its full saved-object JSON.

    Use this after malcolm_saved_objects — the only tool here that lists the
    ids this takes — to read how a shipped dashboard is built. It resolves
    ids as DASHBOARDS ONLY: given a visualization, saved-search or
    index-pattern id it answers with a normal body carrying an embedded 404
    at objects[0].error.statusCode instead of failing, so read the body
    rather than treating a returned object as success. For those three types
    use malcolm_saved_object_detail, which resolves them and hands back the
    query already parsed; for network traffic rather than the Dashboards
    catalogue use malcolm_search. Returns the export JSON — objects[] plus
    an export version — panel layout included, which is what no other tool
    here returns and why an export is large. Size follows panel count, so
    it spans an order of magnitude across Malcolm's shipped dashboards.
    Budget for the largest, not the typical one.

Input Schema

NameRequiredDescriptionDefault
dashboard_idYesSaved-object id of a DASHBOARD, as carried by a malcolm_saved_objects row whose type is "dashboard". An id of any other saved-object type is not rejected here — it comes back as an embedded 404 inside an otherwise normal response body.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.2
    • changedInput schema / properties / dashboard_id / description
      Previous value: -"The OpenSearch Dashboards saved-object id of the dashboard to export. Required (non-empty)."New value: +"Saved-object id of a DASHBOARD, as carried by a malcolm_saved_objects row whose type is \"dashboard\". An id of any other saved-object type is not rejected here — it comes back as an embedded 404 inside an otherwise normal response body."
  2. Addedv0.3.3
  3. Removedv0.3.2
  4. Addedv0.3.0
  5. Removedv0.2.0
  6. First observedv0.1.0

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, so the safety profile is covered. The description does add real behavioral context beyond them — the silent embedded 404 at objects[0].error.statusCode instead of a failure, the instruction to read the body rather than trust an object, and the panel-count-driven size variance. It stops short of noting auth needs or rate limits, so it is good but not exhaustive given annotations carry the safety load.

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-loads the core action in the first sentence before routing guidance, and each subsequent sentence carries distinct information. It runs long with some repetition of the embedded-404 behavior across description and schema, which keeps it out of the top band.

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 one-parameter read tool with an output schema and clear annotations, the description covers selection, failure semantics, and scale expectations. Return-value explanation is not required given the output schema, so nothing an agent needs is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the single dashboard_id parameter and its embedded-404 failure mode are already documented in the schema, and the description largely restates that. The 'DASHBOARDS ONLY' emphasis is useful reinforcement but adds no new syntax or format detail. Baseline 3 is correct.

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: 'Export one OpenSearch Dashboards dashboard as its full saved-object JSON.' It then explicitly distinguishes itself from the three relevant siblings (malcolm_saved_objects, malcolm_saved_object_detail, malcolm_search), so an agent can route correctly without opening any schema.

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 ('after malcolm_saved_objects'), when-not ('given a visualization, saved-search or index-pattern id'), and the named alternative for each case (malcolm_saved_object_detail for those types, malcolm_search for network traffic). Nothing is left to inference.

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