Skip to main content
Glama

Snowflake Suspend Alert

snowflake_suspend_alert
Idempotent

Suspend an active alert by name, optionally scoping it to a database and schema.

Instructions

Suspend an active alert.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
databaseNo
alert_nameYes
schema_nameNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.2.0
    • addedInput schema / additionalProperties
      Added value: +false
    • removedInput schema / properties / alert_name / title
      Removed value: -"Alert Name"
    • removedInput schema / properties / database / title
      Removed value: -"Database"
    • removedInput schema / properties / schema_name / title
      Removed value: -"Schema Name"
    • removedInput schema / title
      Removed value: -"snowflake_suspend_alertArguments"
    • removedOutput schema / title
      Removed value: -"snowflake_suspend_alertDictOutput"
  2. First observedv0.1.0

TDQS

C2.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered externally. The description adds only the modest precondition that the alert must be active to be suspended; it omits effects (paused schedule, loss of firing), permission requirements, and whether the change is reversible.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One short sentence with no filler, but it is terse to the point of under-specification for a mutation tool with three parameters.

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

Completeness2/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 no explanation, but for a mutating tool with three undocumented parameters and no prerequisites or side-effect disclosure, the description leaves substantial gaps.

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

Parameters2/5

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

Schema description coverage is 0% for all three parameters (alert_name required; database and schema_name optional and nullable). The description gives no hint about name format, whether fully qualified names are accepted, or how the optional database/schema are used, so it fails to compensate for the coverage gap.

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?

States a specific verb and resource ('Suspend an active alert'), so an agent knows the operation. It does not differentiate from close siblings like snowflake_resume_alert, snowflake_drop_alert, or snowflake_suspend_task, which share the same suspend/resume/drop pattern.

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

Usage Guidelines2/5

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

There is no guidance on when to suspend vs drop or resume an alert, nor any precondition beyond the word 'active'. The agent must infer everything from the name.

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

Deploy Server

Other Tools