Skip to main content
Glama
rrvrs

jira-alerts-mcp

Check JSM async request status

jsm_get_request_status
Read-onlyIdempotent

Verify asynchronous Jira alert actions by request ID, confirming whether writes like acknowledge, close, or snooze succeeded before proceeding.

Instructions

Check whether an asynchronous alert action actually succeeded.

Every JSM alert write (acknowledge, close, add note, assign, snooze) returns immediately with a requestId and does NOT apply the change synchronously. Pass that requestId here to confirm the action landed — this is the correct way to verify a write, rather than immediately re-reading the alert and finding it unchanged.

Args:

  • request_id (string): the requestId returned by a write tool

  • response_format ('markdown' | 'json'): default 'markdown'

Returns (json format): { "action": string, // e.g. "Acknowledge" "isSuccess": boolean, "status": string, // human-readable outcome, e.g. "Alert acknowledged" "processedAt": string, // ISO 8601 "alertId": string, "alias": string }

Examples:

  • After jsm_acknowledge_alert returns requestId "d383c6e9-..." -> request_id="d383c6e9-..."

Error handling:

  • HTTP 404 shortly after a write usually means the request is still queued; wait a second and retry.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
request_idYesThe requestId returned by any alert write tool (acknowledge, close, note, assign, snooze).
response_formatNoOutput format. 'markdown' is compact and human-readable (default); 'json' returns every field for programmatic use.markdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
requestYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv1.1.1

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already indicate readOnly/idempotent/non-destructive, and the description adds important async behavior: writes return immediately and do not apply synchronously, so this endpoint is necessary to confirm the action landed. The 404-usually-queued error note is additional behavioral context beyond what annotations provide.

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 front-loaded with the core purpose and then efficiently covers rationale, arguments, return shape, example, and error handling in clearly labeled sections. No sentence is filler; the length is justified by the non-obvious async behavior.

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 status-check tool with simple parameters, annotations covering safety, an output shape, a runnable example, and retry guidance, the description fully equips an agent to select and invoke the tool correctly. The async verification context closes the main completeness gap.

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?

Input schema coverage is 100%, so the schema already documents both parameters. The description still adds value by showing a concrete request_id example and giving the exact flow (write tool returns requestId -> pass as request_id), though its Args section largely restates the schema's parameter 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?

The description opens with a specific verb and object: 'Check whether an asynchronous alert action actually succeeded.' It also explains the requestId verification mechanism and distinguishes this tool from immediately re-reading the alert, so an agent can tell it apart from jsm_get_alert and jsm_list_alerts without inspecting the 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?

It explicitly states when to use this tool: after any JSM alert write returns a requestId, and it tells the agent not to use immediate re-reads as verification. It also provides an example ('After jsm_acknowledge_alert returns requestId...') and error-handling guidance for the queued case, so usage context is unambiguous.

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