Skip to main content
Glama

cancel_alert

Destructive

Cancel an active alert permanently. Preview without change by default; confirm with confirmed=True to close.

Instructions

[WRITE] Cancel (dismiss) an active alert. This WRITE operation permanently closes the alert.

Use acknowledge_alert if you only want to mark it as seen. Cancelled alerts will not re-trigger unless the underlying condition recurs. Default confirmed=False returns a preview without making any change.

Args: alert_id: The alert UUID to cancel. confirmed: Must be True to actually cancel. Default False = preview only. target: Optional Aria Operations target name from config. Uses default if omitted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
alert_idYes
confirmedNo
targetNo
Behavior5/5

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

Annotations already indicate destructiveHint=true. Description adds that the operation permanently closes the alert and that it won't re-trigger unless condition recurs. No contradiction; adds valuable 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?

Well-structured with a clear main line, a sibling comparison, and a bulleted Args section. Every sentence is informative; no waste.

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 no output schema, description fully covers behavior: permanent close, preview mode, re-trigger condition, and parameter details. Complete for a cancel 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?

Description provides full semantics for all three parameters: alert_id is the UUID, confirmed must be True to actually cancel (default False = preview), and target is optional Aria Operations name. This is far beyond the schema's minimal type/title info.

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?

Clearly states it cancels/dismisses an active alert, specifies it's a WRITE operation that permanently closes the alert, and distinguishes it from acknowledge_alert.

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 instructs to use acknowledge_alert for merely marking as seen, and explains that cancelled alerts will not re-trigger unless underlying condition recurs. Also documents the confirmed parameter's preview vs. actual behavior.

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/zw008/VMware-Aria'

If you have feedback or need assistance with the MCP directory API, please join our Discord server