Skip to main content
Glama

List alerting monitors

malcolm_alerting_monitors
Read-only

List OpenSearch alerting monitors and their targets, with active alert counts, to verify standing detections are enabled and working.

Instructions

List OpenSearch alerting monitors, what each watches, and whether any have fired.

    Use this to find the standing detections someone already configured, and
    to check they are actually running — a disabled monitor is silent in
    exactly the way a healthy one is. It stops at what each monitor is and
    whether it is enabled: the query and trigger condition behind one need
    malcolm_alerting_monitor_detail, and what has actually fired needs
    malcolm_alerting_alerts. These are OpenSearch alerting rules, which are
    a different thing from Suricata's IDS alerts: for those use
    malcolm_alerts. To record a new finding rather than read a rule, use
    malcolm_create_alert (needs the alerting write class).

    Returns JSON {"total", "showing", "active_alerts", "monitors"};
    per-monitor fields are in the output schema. `active_alerts` counts only
    alerts in the ACTIVE state, not the COMPLETED history the API returns by
    default. When every monitor is disabled the response says so, and
    whether that covers all of them or only the page returned.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax monitors to return.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses important nuances: 'a disabled monitor is silent in exactly the way a healthy one is,' the active_alerts count only includes ACTIVE state rather than COMPLETED history, and the response behavior when all monitors are disabled. This adds significant behavioral context.

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 organized into two paragraphs, front-loaded with a clear purpose. Each subsequent sentence serves to differentiate from siblings, explain usage, or disclose behavior. There is no fluff or redundancy, and the length is justified by the need to navigate the many related tools.

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 covers the tool's scope (what it returns, what it does not), identifies related tools for complementary needs, and clarifies edge cases like active_alerts state filtering and pagination. It references the output schema and offers enough context for an agent to decide when to invoke it. Nothing critical 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 coverage is 100% with a single parameter 'limit' that is self-descriptive ('Max monitors to return'). The description adds only peripheral mention of 'the page returned,' which implies pagination but does not directly elaborate on the parameter's behavior. Baseline 3 is appropriate.

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 first sentence clearly states the action and object: 'List OpenSearch alerting monitors, what each watches, and whether any have fired.' It explicitly distinguishes itself from siblings by noting what it stops at and pointing to malcolm_alerting_monitor_detail and malcolm_alerting_alerts for deeper details.

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 usage context: 'Use this to find the standing detections someone already configured, and to check they are actually running.' It also gives clear alternatives for related purposes: monitor_detail, alerting_alerts, malcolm_alerts, and malcolm_create_alert, each with a rationale.

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