Skip to main content
Glama
rrvrs

jira-alerts-mcp

Snooze a JSM alert until a given time

jsm_snooze_alert
Idempotent

Silence JSM alert notifications until a specific time, stopping paging without closing the alert. They resume automatically.

Instructions

Silence a JSM alert's notifications until a specific instant, after which it resumes as if untouched.

Snoozing is the right tool for "we know, and there is nothing to do until the maintenance window ends" — it stops the paging without pretending the alert is resolved. Closing it would remove it from the open queue and lose the fact that it is still an open problem.

Args:

  • alert_id (string): the full alert id (not the tinyId)

  • end_time (string): ISO 8601 instant with an offset, e.g. "2026-09-05T18:30:00Z"

Returns: { "requestId": string, "result": string, "alert_id": string }

IMPORTANT: this action is asynchronous. Verify with jsm_get_request_status using the returned requestId.

Time handling is the sharp edge here. end_time is an absolute instant, not a duration — "snooze for two hours" means computing the instant yourself from the current time. A past instant is accepted, and the alert un-snoozes immediately, which looks exactly like the call having failed. Send an explicit offset ('Z' or '+05:30') rather than a bare local time.

Examples:

  • "Snooze this until the deploy finishes at 6pm UTC" -> end_time="2026-09-05T18:00:00Z"

  • "Give it an hour" -> compute now + 1h as an ISO instant, then pass it

Constraints and errors:

  • Snoozing a closed alert has no useful effect; close is terminal for notification purposes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
alert_idYesFull alert id, e.g. '9b251e07-73c9-4907-9996-8cb53a6a20d0-1704440650350'. This is NOT the short tinyId shown in the JSM UI — get the full id from jsm_list_alerts first.
end_timeYesWhen the snooze ends, as an ISO 8601 instant with an offset, e.g. '2026-09-05T18:30:00Z'. Must be in the future — a past instant is accepted and the alert un-snoozes immediately.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultNo
alert_idYes
requestIdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.1.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Addedv2.0.0

TDQS

A4.6/5.0
Behavior4/5

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

Adds substantial behavior beyond annotations: asynchronous execution with a required follow-up verification call (jsm_get_request_status), reversal semantics (resumes as if untouched), and the past-instant trap that masquerades as a failure. Annotations cover safety/idempotency, but the async contract and time-handling sharp edge are genuinely new value. Output/return shape is documented.

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?

Front-loaded with purpose and rationale, then args, returns, and the time-handling warning. It is somewhat long but every section earns its place (the time-handling and async notes are high-value). Minor redundancy between description and schema on the past-instant caveat.

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?

For a 2-param async mutation tool with an output schema and full annotation coverage, this covers purpose, rationale, return contract, verification path, error case, and the tricky time semantics. An agent has everything needed to call it correctly.

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?

Schema coverage is 100% so the baseline is 3, but the description adds real meaning: it warns that alert_id is NOT the tinyId, explains end_time is an absolute instant rather than a duration, and that a bare local time should be avoided in favor of an explicit offset. That goes beyond the schema's field-level descriptions.

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 (snooze/silence) and resource (JSM alert notifications), with scope defined as 'until a specific instant, after which it resumes as if untouched.' It explicitly distinguishes itself from the closest sibling (close_alert) by explaining why closing is wrong here.

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 an explicit when-to-use scenario ('we know, and there is nothing to do until the maintenance window ends') and an explicit when-not-to ('Closing it would remove it from the open queue and lose the fact that it is still an open problem'). It also notes the closed-alert no-op case. This is unambiguous routing guidance.

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