Skip to main content
Glama
rrvrs

jira-alerts-mcp

Snooze a JSM alert until a given time

jsm_snooze_alert
Idempotent

Pause notifications for a JSM alert until a specified end time, keeping the alert open and unresolved; notifications resume automatically at that time.

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. Dates show when Glama detected each change.

  1. Addedv2.0.0

TDQS

A5/5.0
Behavior5/5

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

The annotations already indicate this is a mutating, non-destructive, idempotent action, but the description adds important behavioral detail beyond that: the action is asynchronous and returns a requestId that must be checked via jsm_get_request_status. It also reveals edge behavior like past end_time instants causing immediate un-snoozing and snoozing a closed alert having no effect.

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 longer than average, but it is tightly organized into purpose, usage, arguments, async warning, time handling, examples, and constraints. Every paragraph earns its place by addressing a distinct operational risk, with the most critical caveats (async execution and absolute-time semantics) appearing early.

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 the tool's non-obvious async behavior, time-format sharp edges, and terminal behavior for closed alerts, the description is complete. It covers how to invoke the tool, how to verify the result, what errors or misleading outcomes to expect, and what the return payload looks like, while the output schema covers the exact returned shape.

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 coverage is 100%, so the baseline is 3, but the description goes well beyond the schema. It warns that alert_id is the full id and not the tinyId, clarifies that end_time is an absolute instant rather than a duration, gives concrete ISO 8601 examples, and tells the agent how to handle a relative request like 'give it an hour'. The only blemish is the schema's contradictory 'Must be in the future — a past instant is accepted' phrasing, which the description resolves correctly.

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?

The description uses a specific verb ('Silence ... notifications') and resource ('a JSM alert') and clarifies that it is a temporary pause which resumes later. It distinguishes the action from closing an alert, so an agent can immediately tell it apart from the sibling jsm_close_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?

It explicitly frames snoozing as the right choice when there is 'nothing to do until the maintenance window ends' and explains why closing would be wrong because it removes the alert from the open queue and loses the open-problem state. This gives clear when-to-use and when-not-to-use guidance against a relevant alternative.

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

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/rrvrs/jira-alerts-mcp'

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