Jirum
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| JIRA_SCOPES | No | Comma-separated list of OAuth scopes | |
| JIRUM_CONFIG_DIR | No | Directory for Jirum configuration files (default is ~/.config/jirum) | |
| JIRA_DEFAULT_SITE | No | Default Jira site to use | |
| ATLASSIAN_CLIENT_ID | Yes | Your Atlassian OAuth app client ID | |
| ATLASSIAN_CLIENT_SECRET | Yes | Your Atlassian OAuth app client secret | |
| JIRA_OAUTH_REDIRECT_URI | No | The OAuth redirect URI (default is http://localhost:8787/oauth/callback) |
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_auth_statusA | Shows whether Jira is connected, which Atlassian account is in use, the accessible sites and which one is selected. Call this first if any other tool reports NOT_CONNECTED. |
| jira_connectA | Starts the Atlassian OAuth 2.0 login: opens the system browser for consent and returns the authorization URL. Waits up to |
| jira_list_sitesA | Lists the Jira Cloud sites this account can use through this integration. Re-fetches from Atlassian. |
| jira_select_siteA | Chooses the default Jira site for all tools (by cloud id, name, or URL). Persists across restarts. |
| jira_disconnectA | Deletes the stored tokens so this machine is no longer authorized. Revoke the app at https://id.atlassian.com/manage-profile/apps to fully revoke access. |
| jira_myselfA | Returns the Atlassian account the integration acts as (accountId, name, email). |
| jira_list_projectsA | Lists Jira projects on the site, optionally filtered by a name/key substring. |
| jira_get_projectA | Project details including its issue types (with hierarchy level and whether each is a sub-task type). Call before creating issues in an unfamiliar project. |
| jira_get_issue_typesA | Issue types available in a project (Epic, Feature, Story, Task, Bug, Sub-task...). hierarchyLevel: 1 = epic level, 0 = standard, -1 = sub-task. |
| jira_get_create_fieldsA | Lists the fields (required and optional, with allowed values) for creating an issue of a given type in a project. Use when a create fails because of a missing required field, or to find custom field ids. |
| jira_get_fieldsA | All fields on the site (system and custom) with ids, plus the detected Sprint / Story Points field ids. Filter with |
| jira_get_link_typesA | Issue link types (e.g. Blocks: 'blocks' / 'is blocked by'). Use the phrases with jira_link_issues. |
| jira_get_prioritiesB | Priority names available on the site. |
| jira_search_usersA | Finds Jira users by name or email. Pass projectKey to restrict to users assignable in that project. Returns accountIds for use as assignee. |
| jira_search_issuesA | Runs a JQL query and returns a compact list. Examples: 'project = THEOS AND statusCategory != Done ORDER BY updated DESC', 'assignee = currentUser() AND sprint in openSprints()', 'text ~ "vite migration"'. Use nextPageToken to continue. |
| jira_count_issuesA | Approximate count of issues matching a JQL query, without fetching them. |
| jira_get_issueA | Full details of one issue: fields, description (as Markdown), parent, sub-tasks, links, and optionally recent comments. |
| jira_create_issueA | Creates an issue of any type. For hierarchy use parentKey: stories/features/tasks under an Epic, or sub-tasks under a standard issue (jira_create_subtask picks the sub-task type for you). Description is Markdown. Returns the new key and URL. |
| jira_update_issueA | Updates fields on an issue. Only provided fields change. |
| jira_assign_issueA | Assigns an issue to a user ('me', accountId, email or display name). Omit assignee or pass null/'unassigned' to unassign. |
| jira_get_transitionsA | Workflow transitions currently available for an issue (name, target status, required fields). Use before jira_transition_issue if unsure of the names. |
| jira_transition_issueA | Moves an issue through its workflow. |
| jira_add_commentB | Adds a comment (Markdown) to an issue as the connected user. |
| jira_get_commentsB | Latest comments on an issue, newest first, as Markdown. |
| jira_link_issuesA | Creates a link between two issues. Read it as ' ', e.g. fromKey=THEOS-10, linkType='blocks', toKey=THEOS-12, or linkType='is blocked by', 'relates to', 'duplicates', 'is caused by'. Use jira_get_link_types for the site's phrases. |
| jira_delete_issueA | Permanently deletes an issue. Irreversible; confirm with the user first. |
| jira_create_epicB | Creates an Epic (the project's epic-level issue type is detected automatically). Then use jira_create_child_issue to add features/stories under it. |
| jira_create_child_issueA | Creates a Feature, Story, Task or Bug under a parent Epic (parentKey). The project is taken from the parent. Use issueType='Feature' where the project has that type; call jira_get_issue_types if unsure. |
| jira_create_subtaskB | Creates a sub-task under a standard issue (Feature, Story, Task, Bug). The sub-task issue type is detected automatically. |
| jira_create_epic_with_childrenA | Creates an Epic and a batch of child issues (features/stories/tasks) under it, optionally with sub-tasks under each child, in one call. Fails fast on the first error and reports what was created. |
| jira_get_childrenA | Lists the direct children of an Epic (its features/stories/tasks) or the sub-tasks of a standard issue, with status and assignee. |
| jira_get_boardsB | Scrum/Kanban boards, optionally filtered by project key or name. Board ids are needed for sprint lookups. |
| jira_get_sprintsA | Sprints for a board (by boardId) or for a project's scrum boards (by projectKey). Default state filter: active and future. |
| jira_get_sprint_issuesA | Issues in a sprint. |
| jira_add_to_sprintA | Moves up to 50 issues into a sprint. |
| jira_search_my_ticketsA | Issues assigned to the connected user, newest activity first. Defaults to open issues only. Filter by project, status category, or recent updates. |
| jira_find_duplicate_ticketA | Before creating a ticket, searches a project for existing issues matching a summary/keywords (text search on summary, description and comments). Returns likely duplicates so the user can decide whether to create a new one. |
| jira_create_ticket_from_contextA | Creates a well-structured ticket from what was discussed: problem statement, context, reproduction steps, expected/actual behaviour, acceptance criteria, technical notes and links. Builds a consistently formatted description. Use jira_find_duplicate_ticket first when appropriate. |
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 38 tools
The read/lookup tools are well separated, but the create surface has heavy overlap: jira_create_issue can do anything jira_create_epic, jira_create_child_issue, jira_create_subtask, and jira_create_ticket_from_context do, and jira_get_fields / jira_get_create_fields / jira_get_issue_types all answer 'what fields do I need?'. Descriptions do explain when to prefer each, which keeps this from being worse than moderate ambiguity.
Nearly everything follows a jira_verb_noun snake_case pattern (jira_get_issue, jira_list_projects, jira_add_to_sprint), making the set easy to scan. A few stragglers drop the noun or use noun-only forms (jira_myself, jira_connect, jira_disconnect, jira_auth_status), but they are few and readable.
38 tools is heavy even for Jira's breadth, and several are convenience composites that duplicate existing primitives (jira_create_epic_with_children, jira_create_ticket_from_context, jira_find_duplicate_ticket, jira_count_issues). The surface could be trimmed substantially without losing capability.
Core workflows are well covered: JQL search, issue CRUD, hierarchy creation, transitions, assignment, links, comments (create/read), boards, sprints, and sprint membership. Gaps remain around attachments, worklogs, watchers, changelog, and deleting/updating comments or links, which agents cannot work around for those tasks.