Skip to main content
Glama

Update Alert Rule

update_alert_rule
DestructiveIdempotent

Reconfigure or toggle one alert rule, predefined or custom.

ref decides which: a kind name (consistent_error_pattern, silent_failure, tool_loop) addresses the predefined rule of that kind; a uuid addresses a custom rule. Get either from list_alert_rules.

Only what you pass changes. Turning a rule off stops detection, not just notification — gaps in history are permanent and nothing backfills them.

The two rule shapes take DIFFERENT settings, and mixing them is refused with a message naming the right one:

  • a predefined rule has named integer knobs -> pass config

  • a custom rule has metric thresholds -> pass rules (+ window_minutes)

ref: the rule's kind or uuid. enabled: turn detection on or off. rca_enabled: turn root-cause analysis on or off for this rule. name: rename a custom rule (predefined rules take their name from their kind). config: for a PREDEFINED rule only — its named knobs, e.g. {"min_errored_spans": 10}. consistent_error_pattern takes window_minutes, min_errored_spans, min_distinct_traces; silent_failure takes window_minutes; tool_loop takes window_minutes, min_identical_calls. Call describe_alert_catalog for the bounds. rules: for a CUSTOM rule only — replace its thresholds. Replaces the whole list, so pass window_minutes with it. window_minutes: the window. For a custom rule it is part of the replaced config, so pass rules too; for a predefined rule put it in config. filters: for a CUSTOM rule only — replace its filters. Replaces the whole list. Same shape and the same verbatim-value rule as create_alert_rule. channel_ids: change where the rule delivers. Needs channels:manage. An empty list does NOT silence the rule — it re-points it at the region's default webhook. To stop notifications, set enabled to false. workspace: optional workspace id, name, or org-name/workspace-name when the same name occurs in two of your orgs (defaults to your default).

Example:

Turn off the tool loop alert.

{ "name": "update_alert_rule", "arguments": { "ref": "tool_loop", "enabled": false } }

Example:

Make the error pattern alert less noisy — 10 errors, not 3.

{ "name": "update_alert_rule", "arguments": {
    "ref": "consistent_error_pattern",
    "config": { "min_errored_spans": 10 }
} }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
refYes
nameNo
rulesNo
configNo
enabledNo
filtersNo
workspaceNo
channel_idsNo
rca_enabledNo
window_minutesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds substantial context beyond that: disabling stops detection with permanently unfilled history gaps, mixed rule shapes are refused with a corrective message, and an empty channel_ids list re-points delivery to the default webhook rather than silencing. These are exactly the non-obvious behaviors the annotations cannot express.

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?

It is long but justified by ten parameters and zero schema coverage, and it is well front-loaded: the core action, then `ref` resolution, then the destructive warning, then per-parameter detail. There is minor redundancy where the bullet list restates points already made in prose (e.g. `ref`, `window_minutes`), which keeps it from a 5.

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?

An output schema exists, so return values need not be described, and everything else an agent needs is present: the destructive permanence warning, the two config shapes, delivery re-pointing semantics, permission requirements, and workspace disambiguation. Nothing material is left uncovered for a 10-param mutation tool.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the entire burden, and it documents all ten parameters with real semantics: `ref` format, the predefined-vs-custom split for `config`/`rules`, the full-replace semantics of `rules` and `filters`, `window_minutes` placement rules, and the channels:manage requirement for `channel_ids`. This is maximal compensation for a documentation-free 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?

States a specific verb+resource ("Reconfigure or toggle one alert rule") and immediately scopes it to "predefined or custom," distinguishing it from create_alert_rule and delete_alert_rule. It names the sibling it depends on (list_alert_rules) and the catalog tool (describe_alert_catalog), so an agent can tell exactly which tool to reach for.

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?

Explicitly tells the agent where to obtain `ref` (list_alert_rules) and where to find bounds (describe_alert_catalog), and prescribes which config shape applies to which rule type. It also states the failure mode when shapes are mixed, giving clear when-to-use-which guidance rather than leaving it to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources