Jira MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| JIRA_PAT | Yes | Required nonempty PAT; sent as Authorization: Bearer … | |
| LOG_LEVEL | No | error, warn, info (default), or debug | info |
| JIRA_BASE_URL | Yes | Required Jira root URL, including a context path such as https://jira.example.com/jira | |
| JIRA_MCP_ALLOWED_PATHS | No | Comma-separated absolute directories for file access; defaults to none (uploads and explicit download destinations denied; automatic temporary downloads allowed) | |
| JIRA_MCP_MAX_FILE_SIZE_MB | No | Positive number up to 1024; defaults to 20. Limits each file, total upload batch, and download size | 20 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| jira_search_issuesA | Read-only: search Jira Server/Data Center using JQL. Returns compact issue summaries and pagination. fields limits fields fetched; custom fields are not emitted in this version. |
| jira_get_issueA | Read-only: get a Jira issue by key, including description, comments, issue links (with relationships relative to this issue), and attachment metadata. Includes nonempty custom fields with IDs, names and original values (including acceptance criteria where available). Comments may be partial: use jira_get_comments from startAt=0 and follow nextStartAt to read the full discussion. Set includeCustomFields=false for compact output. Does not read or download attachment contents. |
| jira_create_issueA | WRITE: create one Jira issue. Requires project key, exact issue type name, and summary. Optional assignee is a Server username. Custom fields use raw IDs. Jira validates required fields and create-screen permissions. Never retry blindly after a timeout. |
| jira_update_issueA | WRITE: update supplied fields on an existing Jira issue. Omitted fields stay unchanged. Labels and components replace entire lists; [] clears them. Requires at least one field. Does not change workflow status. Assignee is a Server username; custom fields use raw IDs. |
| jira_add_commentA | WRITE: add a comment to a Jira issue using text/wiki markup. No additional visibility restriction is applied; users with access to the issue can read it. Never retry blindly after a timeout because duplicate comments may result. |
| jira_get_transitionsA | Read-only: list currently available workflow transitions for a Jira issue as IDs and names. Transition names may differ from destination status names. An empty list means no transitions are available to the current user. |
| jira_transition_issueA | WRITE: execute one workflow transition. Supply exactly one of transitionId or transitionName. Names match available transition names case-insensitively, not status names; ambiguous names require an ID. Does not fill transition-screen fields. Returns observed status when possible. Never retry blindly after timeout. |
| jira_list_attachmentsB | Read-only: list compact attachment metadata for a Jira issue; does not access local files. |
| jira_upload_attachmentA | WRITE: upload 1–10 local files to a Jira issue. filePaths must resolve inside JIRA_MCP_ALLOWED_PATHS. Rejects .. traversal and symlink escapes. The configured size limit applies per file and to the total batch. Relative paths use server working directory. Do not retry blindly after failure. |
| jira_download_attachmentA | LOCAL WRITE: download a Jira attachment. Omit destinationPath to create a private temporary directory automatically; returns savedTo, mimeType, size, cleanupPath and downloadId. Read savedTo with your local file/image tool; then call jira_cleanup_attachments with downloadIds instead of deleting through Bash. IDs are valid only in this server process. Each automatic download creates a new directory. Explicit destinations must be inside JIRA_MCP_ALLOWED_PATHS with an existing parent; overwrite must be true to replace a file. Rejects destination symlinks. Does not modify Jira. |
| jira_get_current_userA | Read-only: get the authenticated Jira Server/Data Center user for the configured PAT. Takes no arguments. Returns name (username for assignee), displayName, active, and timeZone. Use to check authentication or assign an issue to yourself. Does not return email or internal metadata. |
| jira_get_commentsA | Read-only: read one page of Jira issue comments in ascending creation order, including full bodies. To read the full discussion, start at 0 and repeat with nextStartAt until null. Only comments visible to the PAT user are returned. If hasMore is true but nextStartAt is null, Jira returned an empty intermediate page; refresh rather than assuming the discussion is complete. |
| jira_cleanup_attachmentsA | LOCAL DELETE: clean up automatic temporary downloads after reading them. Pass downloadIds returned by jira_download_attachment in this server process. Never accepts paths or deletes explicit destination files. Returns per-ID deleted, not_found (unknown/already cleaned/previous process), or failed. Inspect failed entries and retry if appropriate. Does not modify Jira. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Each tool maps to a distinct resource+action (search, get, create, update, comment, transition, attachment lifecycle), and the descriptions explicitly disambiguate the risky pairs like get_issue vs get_comments and update_issue vs transition_issue. Minor overlap remains: jira_get_issue already emits attachment metadata and partial comments, so an agent could plausibly skip jira_list_attachments or misuse get_issue for full discussions, but the docs steer correctly.
Every tool follows the same jira_<verb>_<noun> snake_case pattern (search_issues, get_issue, create_issue, add_comment, list_attachments, upload_attachment, cleanup_attachments). No camelCase or verb-style deviations; read vs write intent is further flagged in descriptions.
13 tools is squarely in the well-scoped range for a Jira integration and each one earns its place: the attachment trio (upload/download/cleanup) plus comment paging reflect real operational needs rather than bloat. Nothing appears redundant or filler.
Core issue lifecycle (search, get, create, update, comment, transition) and attachment handling are covered, but jira_create_issue demands an exact project key and issue type name while no tool lists projects, issue types, or creatable field metadata, which will cause trial-and-error failures. There is also no issue delete, no comment edit/delete, no issue-link or worklog operations, and no assignable-user lookup beyond get_current_user.