MCPulse

Update an alert

update_alert

Admin or owner. Omitted fields are left alone, so silencing a rule is a one-field call: { alert_id, enabled: false }. Prefer that over deleting — the history survives and it can be switched back on.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	A new name. Renaming does not rewrite the rule's firing history — each firing froze the name it had at the time.
`metric`	No	Watch a different metric. The threshold is in the metric's own unit, so changing one usually means changing both.
`enabled`	No	False silences the rule while keeping it and its history. Prefer this over deleting — it can be switched back on.
`alert_id`	Yes	Which rule to change. From list_alerts.
`channels`	No	Replaces the rule's channels outright rather than merging. Delivery is still the intersection of these and each person's own accepted channels.
`min_calls`	No	The noise floor: a day with fewer calls than this in scope is skipped rather than judged.
`threshold`	No	In the metric's own unit, as `list_alerts` reports it: a rate is a fraction, so 0.6 means 60% — not 60. A rate threshold above 1 can never be crossed and the rule would never fire.
`tool_name`	No	Re-scope to one tool. Null widens it back to every tool. Omit for every tool / every client. Narrowing to both is where the value is: one model can fail on a tool another handles fine, and the server-wide average is what hides it.
`comparator`	No	Which side of the threshold trips the rule. Follow the metric's own `direction` from list_alerts.
`client_name`	No	Re-scope to one client. Null widens it back to every client. Omit for every tool / every client. Narrowing to both is where the value is: one model can fail on a tool another handles fine, and the server-wide average is what hides it.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes
`name`	Yes
`mcp_id`	Yes
`metric`	Yes
`enabled`	Yes
`summary`	Yes	The rule as a sentence, rendered here so the inbox, an email and this tool all read the same words.
`channels`	Yes
`min_calls`	Yes	The noise floor. Two empties out of three calls is 67% and means nothing.
`threshold`	Yes	In the metric's own unit: a rate is a fraction, so 0.6 is 60%.
`tool_name`	Yes	Null means every tool.
`comparator`	Yes
`created_at`	Yes
`client_name`	Yes	Null means every client.
`fired_count`	Yes
`last_fired_at`	Yes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 8, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With readOnlyHint=false and destructiveHint=false already present, the description adds valuable behavior beyond the annotations: omitted fields are left untouched, disabling preserves history and allows re-enabling, and this is a non-destructive alternative to deletion. This gives the agent an accurate mental model of side effects.

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 compact and front-loaded: permission, partial-update behavior, a concrete example, and the deletion trade-off are all in three sentences. Every sentence earns its place and there is no redundant filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the very rich input schema, output schema, and annotations, the description is sufficient for an agent to select and invoke the tool correctly. It covers the key behavioral nuance (partial update), permission, and the main alternative. It intentionally leaves parameter-level details to the schema, which is appropriate here.

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?

The schema already provides 100% parameter coverage with rich descriptions, so the baseline is 3. The description adds meaning beyond the schema by explaining the PATCH-like semantics: omitted fields are left alone, and a single-field call like { alert_id, enabled: false } is sufficient. This directly informs how parameters should be provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description makes clear that this tool modifies an existing alert/rule, highlighting the partial-update behavior and the specific silencing use case. It distinguishes itself from delete_alert by noting history survives. It does not restate the full range of updatable fields, but the title and example are unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states the permission prerequisite ('Admin or owner') and gives explicit guidance to prefer this tool over deleting when history preservation matters. It also shows how to perform a minimal one-field update. It does not explicitly contrast with create_alert, but the naming and context make that distinction obvious.

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

All MCPulse tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?