jira-alerts-mcp

Overview Schema Source Related Servers Discussions Admin

Acknowledge a JSM alert

jsm_acknowledge_alert

Idempotent

Acknowledge an open JSM alert to stop escalation notifications and signal that a human is handling it, without resolving the alert.

Instructions

Acknowledge an open JSM alert, stopping further escalation notifications for it.

Acknowledging signals that a human has picked the alert up. It does not resolve the alert — use jsm_close_alert for that. Acknowledging an already-acknowledged alert is a no-op.

Args:

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

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

IMPORTANT: this action is asynchronous. The response confirms the request was accepted, not that the alert changed. Verify with jsm_get_request_status using the returned requestId.

Examples:

"Ack the Redis latency alert, I'm on it" -> alert_id=, note="Investigating, RVS"

Input Schema

TableJSON Schema

Name	Required	Description	Default
`alert_id`	Yes	Full 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.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	No
`alert_id`	Yes
`requestId`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv2.1.0Sep 12, 2026

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"

Changed3 schema fields changedv2.0.0Sep 8, 2026

removedInput schema / properties / note

Removed value: -{
-  "description": "Optional note recorded alongside the acknowledgement.",
-  "maxLength": 25000,
-  "type": "string"
-}

removedInput schema / properties / source

Removed value: -{
-  "description": "Free-text source label shown in the alert activity log, e.g. 'claude-mcp'.",
-  "type": "string"
-}

removedInput schema / properties / user

Removed value: -{
-  "description": "Display name or email recorded as the actor for this action. Defaults to the owner of the API credentials.",
-  "type": "string"
-}

First observedv1.1.1Aug 30, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations carry the safety profile, and the description goes well beyond them: it discloses the asynchronous contract ('the response confirms the request was accepted, not that the alert changed'), the no-op idempotency behavior, and the exact return shape. The response-shape detail is partly redundant with the output schema, which keeps this from a 5.

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 the action and its effect, then prerequisites, args, return and async caveat, in a scannable order with no filler prose. The closing example is the weak point: it is over-formatted and invents a parameter, slightly muddying an otherwise tight definition.

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 one-parameter mutation with an output schema, everything needed to call and verify it is present: the id format requirement, the async acceptance semantics, the follow-up verification tool, and the non-resolving scope. Nothing an agent needs is missing.

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

Parameters3/5

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

Schema coverage is 100% and the schema already warns that alert_id is the full id, not the tinyId, so the description adds little on that front. Worse, the trailing example implies a 'note' argument ('note="Investigating, RVS"') that does not exist in the schema and would be rejected by additionalProperties:false — a misleading detail, but the schema itself remains authoritative.

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+resource ('acknowledge an open JSM alert') plus the immediate effect ('stopping further escalation notifications'). It explicitly distinguishes itself from the nearest sibling by name — jsm_close_alert resolves, this does not — so an agent can separate the two without opening either schema.

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?

Gives explicit when-to-use (a human has picked the alert up), an explicit when-not/alternative ('It does not resolve the alert — use jsm_close_alert for that'), and an edge-case rule ('Acknowledging an already-acknowledged alert is a no-op'). It also routes the agent to jsm_get_request_status for verification.

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