Skip to main content
Glama
rrvrs

jira-alerts-mcp

by rrvrs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Add a responder to a JSM alert

jsm_add_alert_responder
Idempotent

Add a user, team, escalation, or schedule as a responder to an existing JSM alert to notify and hold them accountable. Responders are additive.

Instructions

Add a responder (user, team, escalation or schedule) to an existing JSM alert so they are notified and become accountable for it.

Use this to pull in another team once triage shows the alert belongs elsewhere. Responders are additive — this does not remove the existing ones.

Args:

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

  • responder_id (string): id of the user/team/escalation/schedule to add

  • responder_type ('user' | 'team' | 'escalation' | 'schedule'): what responder_id refers to

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

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

Examples:

  • "Page the database team on this" -> responder_id=, responder_type="team"

Error handling:

  • HTTP 422 or a failed request status usually means responder_id doesn't exist or its type is wrong. Team and schedule ids can be found with jsm_list_schedules or the JSM UI.

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.
responder_idYesId of the user, team, escalation or schedule to add as a responder.
responder_typeYesWhat kind of entity responder_id refers to.

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. Changed3 schema fields changedv2.0.0
    • removedInput schema / properties / note
      Removed value: -{
-  "description": "Optional note recorded with the change.",
-  "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"
-}
  3. First observedv1.1.1

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare non-destructive, idempotent, open-world behavior, and the description goes further by disclosing that the operation is asynchronous, that the returned requestId must be verified via jsm_get_request_status, and what HTTP 422 implies. The 'responders are additive' note reinforces the non-destructive annotation rather than contradicting it.

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 structured into args, returns, async warning, example, and error handling sections. Slightly repetitive of the schema in the Args block, but every section carries information an agent needs.

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?

With an output schema present, the description need not explain return values, yet it still summarizes them and adds the critical async-verification step. Error handling and id-discovery guidance (jsm_list_schedules) round out a definition complete enough to call the tool correctly on the first try.

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%, so all three parameters and the enum are already documented in the schema, including the alert_id-vs-tinyId warning. The description largely restates these and adds only a worked example mapping a natural-language request to responder_type='team', which is marginal added meaning over the schema.

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 (add) and resource (responder) plus the accepted responder kinds, and scopes it to an existing JSM alert. It is distinguishable from adjacent siblings such as jsm_assign_alert and jsm_escalate_alert because it names the responder categories explicitly.

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 a concrete usage trigger ('pull in another team once triage shows the alert belongs elsewhere') and states the key constraint that responders are additive rather than replacing existing ones. It does not explicitly contrast itself with jsm_assign_alert or jsm_escalate_alert, which would be needed for a 5.

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

Deploy Server

Other Tools