jira-delivery-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| JIRA_EMAIL | Yes | Atlassian account email | |
| JIRA_BASE_URL | Yes | Jira site URL, e.g. https://your-domain.atlassian.net | |
| JIRA_API_TOKEN | Yes | Jira API token | |
| JIRA_ENABLE_WRITES | No | Opt-in to write tools (jira_add_comment, jira_update_issue). Defaults to read-only unless set to true. | false |
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
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| jira_get_issueA | Fetch a Jira issue as a developer brief: description, acceptance criteria, comments and attachments. Use depth "full" for parent/epic/linked-issue context and includeConfluence for related documentation. Use this to read a ticket. To start work, check readiness, verify changes or write a report, call jira_prepare_work_brief or the delivery_* tool directly: they fetch the issue themselves. |
| jira_search_issuesA | List open Jira issues assigned to the authenticated user, optionally limited to one project. Use this to find what to work on next. Pass jql to search with your own filter instead (e.g. "type = Bug AND sprint in openSprints() ORDER BY priority DESC"); it is limited to projectKey when given, and to the allowed projects when the strict allowlist is on. When more results exist, data.nextPageToken is set: pass it back as pageToken for the next page. |
| jira_prepare_work_briefA | Turn a Jira issue into a ready-to-implement brief for a coding agent: goal, acceptance criteria, constraints and an implementation prompt. Use this when starting work on a ticket, or to check whether it is ready to start (readiness, blockers, missing acceptance criteria). Fetches the issue itself. |
| confluence_searchA | Find Confluence pages relevant to a Jira issue (specs, designs, runbooks), ranked by relevance and authority. |
| confluence_get_pageA | Read a Confluence page by ID and return a cleaned, size-bounded summary of its content. |
| delivery_check_changesA | Check work on a Jira issue: does the branch cover the acceptance criteria and meet the Definition of Done? alignment and dod compare the local diff with them — run them before opening a PR. impact predicts the affected areas and works before any code is written, so use checks ["impact"] when planning. Each check runs independently. Returns a verdict (ready_for_pr, needs_work, insufficient_evidence; not_applicable when only impact ran) and per-criterion coverage. Fetches the issue itself. |
| delivery_traceability_matrixA | Build a requirements traceability matrix: map each requirement and acceptance criterion of a Jira issue to the changed files that implement it, and flag gaps. Fetches the issue itself. For a ready-for-PR verdict use delivery_check_changes. |
| delivery_generateA | Generate a delivery artifact from a Jira issue and the local diff: test_strategy, reviewer_report (needs persona), qa_handoff, release_notes (audience) or task_report (combined sections). Use test_strategy to plan tests and reviewer_report to review a ticket from a persona's point of view. Fetches the issue itself. Returns Markdown; writes no files. |
| delivery_generate_agent_packA | Write reusable Jira delivery prompts/commands for a coding agent into the repository (claude: .claude/commands and .claude/skills, codex: .codex-prompts/, generic: .mcp-prompts/). |
| delivery_project_patternsA | Detect the repository’s conventions (framework, test layout, tooling) and store them so other delivery tools can tailor their output. scan = detect and store, get = read stored patterns, clear = delete them. Storing requires DELIVERY_PATTERN_MEMORY_ENABLED=true in the server environment. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| jira_implementation_prompt | Prepare a full implementation brief for a Jira task |
| jira_pr_review_prompt | Review the current branch against a Jira task |
| jira_qa_handoff_prompt | Generate a QA handoff for a Jira task |
| jira_definition_of_done_prompt | Verify the Definition of Done for a Jira task |
| jira_release_note_prompt | Generate release notes for a Jira task |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| configured-projects | Default project, allowed project keys and the issue-key format this server accepts. |
TDQS
Scored across 10 tools
Most tools target clearly different stages: read (jira_get_issue), brief (jira_prepare_work_brief), verify (delivery_check_changes, delivery_traceability_matrix), and generate artifacts. The main risk is overlap between check_changes and traceability_matrix and between get_issue and prepare_work_brief, but descriptions explicitly steer callers between them.
Consistent snake_case with meaningful domain prefixes (jira_, confluence_, delivery_), and most names are verb_noun. Minor deviations: delivery_project_patterns is a noun-only, multi-action tool (scan/get/clear) that breaks the pattern, and jira_prepare_work_brief sits under jira_ but is a workflow tool rather than a raw Jira verb.
10 tools is squarely in the well-scoped range, with each covering a distinct delivery workflow step (read, search, brief, verify, generate). Nothing appears redundant or padding.
The read/verify/generate side of the lifecycle is well covered, but there are no write-back operations to Jira: no commenting, status transitions, or issue updates, which limits closing the loop after work is verified. Confluence is read-only, which is reasonable, but the missing Jira mutations are a notable gap for a delivery workflow.