Skip to main content
Glama
rrvrs

jira-alerts-mcp

Search JSM alerts

jsm_list_alerts
Read-onlyIdempotent

Search and list Jira Service Management Operations alerts to find open or unacknowledged issues, filter by priority, team, or tag, and convert a short tinyId into the full alert id.

Instructions

Search and list alerts in Jira Service Management Operations.

This is the entry point for almost every alert workflow: use it to find open or unacknowledged alerts, filter by priority/team/tag, and to resolve a short tinyId (as shown in the JSM UI) into the full alert id that every other alert tool requires. It reads only — it never creates or modifies alerts.

Args:

  • query (string, optional): field:value search, e.g. "status:open AND priority:P1"

  • limit (number): 1-100, default 20

  • offset (number): records to skip, default 0

  • sort (string): field to sort by, default "createdAt"

  • order ('asc' | 'desc'): default "desc"

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

Returns (json format): { "alerts": [ { "id": string, // full alert id — pass this to other tools "tinyId": string, // short id shown in the JSM UI "message": string, "status": "open" | "closed", "acknowledged": boolean, "priority": "P1".."P5", "count": number, // dedupe count "tags": string[], "owner": string, "createdAt": string, // ISO 8601 "lastOccurredAt": string } ], "pagination": { "count": number, "offset": number, "has_more": boolean, "next_offset": number } }

Examples:

  • "What's on fire right now?" -> query="status:open AND acknowledged:false", sort="createdAt"

  • "Show P1s from the Payments team" -> query="priority:P1 AND teams:Payments"

  • "Find the alert about Redis latency" -> query="message:Redis"

Constraints and errors:

  • offset + limit must stay below 20000; the API refuses to page deeper.

  • A malformed query returns HTTP 400 — field names are case-sensitive.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNoField to sort by (default 'createdAt'). These four are the only values the API accepts.createdAt
limitNoMaximum number of records to return (1-100, default 20).
orderNoSort direction (default 'desc', i.e. newest first).desc
queryNoJSM alert search query. Field:value syntax, combinable with AND/OR/NOT. Examples: "status:open", "status:open AND priority:P1", "acknowledged:false AND createdAt > 1704067200000", "tag:database AND status:open", "teams:Payments". Omit to return the most recent alerts unfiltered.
offsetNoNumber of records to skip, for paging. Use the 'next_offset' from a previous response.
response_formatNoOutput format. 'markdown' is compact and human-readable (default); 'json' returns every field for programmatic use.markdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
alertsYes
paginationYes

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. First observedv1.1.1

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover readOnly, idempotent, openWorld, and non-destructive. The description adds valuable operational behavior: offset+limit cannot exceed 20000 and malformed queries return HTTP 400 with case-sensitive field names. That is 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.

Conciseness4/5

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

Front-loaded with purpose and role, then breaks into args, returns, examples, and constraints. It is somewhat long and the returns block duplicates the existing output schema, but the structure is clean and every section has some practical value.

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?

Complete for a search/list tool with six optional parameters and a high schema coverage. It covers when to use it, input syntax, output shape, pagination limits, error behavior, and examples, so an agent has everything needed to invoke 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 description coverage is 100%, so baseline is 3. The description adds a cross-parameter constraint ('offset + limit must stay below 20000') and clarifies query error semantics, which the schema does not cover. It mostly repeats schema defaults and enums otherwise.

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 ('Search and list alerts') and scope ('in Jira Service Management Operations'). It distinguishes itself from sibling tools by declaring itself the entry point for alert workflows and the resolver of tinyId to full alert id.

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

Usage Guidelines4/5

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

Gives clear context: entry point for alert workflows, use to find open/unacknowledged alerts, filter by priority/team/tag, resolve tinyId. It excludes mutation ('reads only — never creates or modifies') but does not name specific alternative siblings (e.g., jsm_get_alert, jsm_create_alert) for particular cases.

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