Skip to main content
Glama

Read one alerting monitor's query and triggers

malcolm_alerting_monitor_detail
Read-only

Read one alerting monitor's complete query and trigger conditions to decide if its silence means anything. Use the monitor ID from the monitor listing.

Instructions

Read one alerting monitor in full: the query it runs and the conditions that fire it.

    Use this to decide whether a monitor's SILENCE means anything.
    malcolm_alerting_monitors says a monitor exists and whether it is
    enabled, but cannot show the query or the trigger condition, so it
    cannot separate a monitor that watches the right traffic from one whose
    condition no traffic can satisfy — measured on Malcolm v26.07.1, the shipped
    loopback monitor fires on `ctx.results[0].hits.total.value > 999999999`.
    Take the id from malcolm_alerting_monitors; for the alerts a monitor has
    raised use malcolm_alerting_alerts with monitor_id.

    Field names are in the output schema; what it cannot show is what sits
    inside `inputs` and `triggers` — each search input's whole OpenSearch
    query as the monitor stores it, mustache placeholders such as
    {{period_end}} left intact, and each trigger's severity, firing
    condition and action names. Watch for the `note` key: it marks a monitor
    that cannot fire at all, disabled or trigger-less. Raises if no monitor
    has that id.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
monitor_idYesThe monitor's OpenSearch document id, returned as `id` by malcolm_alerting_monitors (e.g. "NYUZsZ8Bao8axaN3ef1f"). Not the monitor name.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint, but the description adds significant behavioral context beyond that: it warns about the 'note' key indicating a monitor cannot fire, discloses that 'Raises if no monitor has that id', and describes internal details like mustache placeholders. This goes well beyond the annotation safety profile and covers 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 longer than two sentences but is well-structured and front-loaded: the first sentence gives the core purpose, followed by usage context and detailed behavioral notes. Every paragraph adds value (the loopback monitor example illustrates the query format), but it is somewhat verbose and could be tightened without losing critical information.

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 tool's complexity (nested inputs/triggers, the 'note' key, error behavior), the description covers all essential aspects: what is returned, what is intentionally not described in the output schema, how to interpret the note key, and error conditions. The output schema exists, so return value details are not needed, and the description fills all remaining contextual gaps.

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?

The input schema already provides full coverage (100%) with a clear description, example value, and disambiguation ('Not the monitor name'). The tool description only repeats 'Take the id from malcolm_alerting_monitors' without adding new semantic meaning, so it meets the baseline but does not exceed the schema.

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: 'Read one alerting monitor in full: the query it runs and the conditions that fire it.' It clearly distinguishes itself from sibling tools by explicitly contrasting with malcolm_alerting_monitors and malcolm_alerting_alerts, making the tool's unique purpose obvious.

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 states exactly when to use this tool ('Use this to decide whether a monitor's SILENCE means anything') and explains why alternatives are insufficient (malcolm_alerting_monitors cannot show query/triggers). It also provides workflow guidance: 'Take the id from malcolm_alerting_monitors' and directs users to malcolm_alerting_alerts for raised alerts, explicitly covering alternatives.

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