Pod

Yes, this is on purpose. Pod is built for agents, so the default page is plain HTML.
Human? View the normal website.
Agent? You probably prefer /mcp/jira-cloud/issues.md or /mcp/jira-cloud/issues.json, or Pod over MCP.

Reported issues for Jira Cloud

Pod holds 16 of 16 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to Jira Cloud.

Most discussed

manage_jira_issue update: customFields write path can't set fields editable in UI but absent from Edit screen (e.g. Tempo Account)

Summary

When a custom field is editable in the Jira UI's issue view (right side panel, inline edit) but is not on the configured Edit Issue screen for that issue type, manage_jira_issue update with customFields returns Field 'X' cannot be set. It is not on the appropriate screen, or unknown. — even when the field exists, has a known name, and is the same field the user can edit through the UI.

The write path therefore can't reach a class of custom fields that are commonly inline-e

Read the thread · 2026-05-08 · closed · 2 comments

manage_jira_project should expose related boards and sprints

Summary

There's no path from a project to its scrum/kanban boards or active sprints in the current tool surface. An agent that knows "this issue lives in project X and needs to go into Sprint 5" has to guess-and-probe board IDs to find the right one — which often fails entirely when manage_jira_board list doesn't return the target board.

Current state

manage_jira_project get returns: project name, issue types, issue summary counts. No boards, no sprints, no board IDs.

To find a

Read the thread · 2026-04-09 · open · 2 comments

Custom field visibility gaps: no read-expand on get, JQL swallows "field not found" errors, cube dimensions exclude custom fields

Summary

Three related gaps make custom fields effectively invisible to agents, even when specific field names are known. Each is individually small; together they close off every read path for custom field state. Discovered while working around #43 (the jira://custom-fields 403 bug).

Gap 1: manage_jira_issue get has no expand option for custom field values

Current expand enum: comments, transitions, attachments, related_issues, history. None return custom field values.

Read the thread · 2026-04-09 · open · 2 comments

Align CI/release process with groupware MCP server standard

Context

All four groupware MCP servers (jira-cloud, slack-mcp, confluence-cloud, google-workspace-mcp) negotiated and agreed on a common CI/release pattern to ensure consistency across projects. This issue documents the consensus and jira-cloud's specific path to convergence.

Agreed Standard

  1. ci.yml — lint/test/build on PRs + feature branch pushes, Node 22
  2. release.yml — triggers on v* tag → creates GitHub Release + builds and uploads .mcpb bundle
  3. npm-publish.yml

Read the thread · 2026-04-11 · open · 1 comment

Field error messages conflate distinct failure modes (missing, not-on-screen, not-writable, hidden-by-scheme)

Summary

When manage_jira_issue update fails on a custom field, Jira returns an error that the MCP propagates verbatim:

Field 'Sprint' cannot be set. It is not on the appropriate screen, or unknown.

This message conflates at least four distinct failure modes into one string, and an agent has no way to tell them apart. Each requires a different recovery action.

The failure modes this message covers

  1. Field doesn't exist on the instance at all
  2. **Field exists but isn't o

Read the thread · 2026-04-09 · closed · 1 comment

manage_jira_issue update success response doesn't echo what was written, blocking post-write verification

Summary

When manage_jira_issue update succeeds, the response confirms success but doesn't echo the field values that were actually written. To verify the write took effect, an agent has to issue a follow-up get call — which is slow, wastes tokens, and (for custom fields) may not even return the value due to separate visibility gaps (#44).

Observed

{
  "operation": "update",
  "issueKey": "ABC-123",
  "customFields": {"Story Points": 5, "Team": "Platform"}
}

Response (pa

Read the thread · 2026-04-09 · closed · 1 comment

analyze_jira_issues groupBy: sprint returns empty breakdown despite sprint being listed as a supported dimension

Summary

analyze_jira_issues advertises sprint as a valid groupBy dimension (it's in the enum, and cube_setup lists it), but using it returns a single (no sprint) row with all zeros — even when the JQL filter explicitly scopes to issues known to have sprints set.

Observed

{
  "jql": "project = ABC AND sprint is not EMPTY",
  "metrics": ["summary"],
  "groupBy": "sprint"
}

Response:

# Summary: project = ABC AND sprint is not EMPTY
As of Apr 9, 2026 — counts are exa

[Read the thread](https://github.com/aaronsb/jira-cloud/issues/46) · 2026-04-09 · open · 1 comment

### `jira://custom-fields` returns 403 for non-admin users, blocking all downstream field discovery

## Summary

The `jira://custom-fields` resource returns `403` from the upstream Jira API when accessed by a user who isn't a site/project admin. The project-scoped fallback `jira://custom-fields/{projectKey}/{issueType}` depends on the master catalog and returns `catalogReady: false`, so it's equally unusable. Net effect: a regular user connecting the MCP to a Jira Cloud instance gets zero custom field discovery.

## Observed

Resource: jira://custom-fields Response: { "status": "loading",

Read the thread · 2026-04-09 · closed · 1 comment

Most recent

Publish to npm by trusted publishing (OIDC) instead of a long-lived NPM_TOKEN

@aaronsb/jira-cloud-mcp publishes from a long-lived NPM_TOKEN. google-workspace-mcp used to as well, and that token expired silently. This describes the OIDC path that replaced it, so this repo can follow the same convention.

This repo's current state: npm-publish.yml and release-mcpb.yml, publishing with NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}. It already sets id-token: write and passes --provenance, so the change is small — the identity just stops coming from the token.

`

Read the thread · 2026-08-17 · closed · 0 comments

Tempo Account write via Account alias fails though capabilities says resolves:true; raw customfield_11266 + numeric id works

Summary

Writing the Tempo Account field through manage_jira_issue fails when the field is addressed by its alias ("Account", by name or numeric id), even though jira://capabilities advertises resolves: true for it. Addressing the field by its raw id customfield_11266 with the bare numeric option id succeeds. So the alias/resolution layer is broken while the raw passthrough works — and capabilities over-promises.

Environment

Read the thread · 2026-07-01 · open · 0 comments

manage_jira_issue worklog: no read path, and worklogDate JQL silently returns 0 results

Summary

manage_jira_issue can write worklogs but cannot read them, and date-scoped worklog discovery via JQL silently returns zero. Per-period worklog reconciliation ("how much did I log in May, by issue?") is therefore impossible through the MCP — even though the underlying Jira REST API supports it fully. This is the worklog analog of #44.

Observed (MCP)

  1. worklogDate JQL silently returns 0 in every form, while worklogAuthor alone works:
    • `worklogAuthor = curren

Read the thread · 2026-06-02 · open · 0 comments

manage_jira_issue efficiency tip is noisy and hard-codes assumptions about agent workflow

Summary

Every third consecutive manage_jira_issue call appends this to the response:

---
**💡 Efficiency tip:** You've made 3 consecutive `manage_jira_issue` calls. Consider using `queue_jira_operations` to batch multiple issue operations into a single call — it's faster and uses less context.

Well-intended, but as an agent consuming the tool I found it actively unhelpful for a few reasons:

Problems

1. Serial calls are often intentional, not accidental

Many of my "consec

Read the thread · 2026-04-09 · open · 0 comments

Issue type discovery: surface allowed types to prevent create failures

Problem

LLMs frequently fail when creating issues because they guess the issue type (Task, Story, Bug) without knowing what the target project actually allows. Different projects have different issue type schemes — some use Feature instead of Story, some have custom types like Test Execution or ISO.

This was observed in live agent usage: an agent struggled to create an issue because it had no way to discover valid issue types for the project.

Current state

Read the thread · 2026-03-19 · closed · 1 comment

Replace hardcoded custom field defaults with well-known field discovery

Context

PR #33 added WELL_KNOWN_FIELDS detection in field discovery — locked Jira fields (Sprint, Story Points, Start Date, Target Date) are now identified by their schema custom type at startup.

Currently only sprint is wired from discovery back to the client. storyPoints and startDate still use hardcoded defaults (customfield_10015, customfield_10016).

Proposal

  1. Wire all discovered well-known field IDs to JiraClient.customFields after discovery completes (not just sprin

Read the thread · 2026-03-19 · closed · 0 comments

Make a supporting api improvement for mcp

Do the thing

Read the thread · 2025-04-02 · closed · 1 comment

Develop an MCP server for x y z

Do a thing for stuff because reasons and requirements.

Read the thread · 2025-04-02 · closed · 1 comment

The remaining reports are on the project's issue tracker.