# 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](/mcp/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](https://github.com/aaronsb/jira-cloud/issues/52) · 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](https://github.com/aaronsb/jira-cloud/issues/45) · 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](https://github.com/aaronsb/jira-cloud/issues/44) · 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](https://github.com/aaronsb/jira-cloud/issues/50) · 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](https://github.com/aaronsb/jira-cloud/issues/49) · 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

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

Response (pa

[Read the thread](https://github.com/aaronsb/jira-cloud/issues/48) · 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](https://github.com/aaronsb/jira-cloud/issues/43) · 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](https://github.com/aaronsb/jira-cloud/issues/60) · 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

- Server: `jira-cloud` MCP
- Field: Tempo

[Read the thread](https://github.com/aaronsb/jira-cloud/issues/59) · 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](https://github.com/aaronsb/jira-cloud/issues/58) · 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](https://github.com/aaronsb/jira-cloud/issues/47) · 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

- `manage_jira_

[Read the thread](https://github.com/aaronsb/jira-cloud/issues/35) · 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](https://github.com/aaronsb/jira-cloud/issues/34) · 2026-03-19 · closed · 0 comments

### Make a supporting api improvement for mcp

Do the thing

[Read the thread](https://github.com/aaronsb/jira-cloud/issues/10) · 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](https://github.com/aaronsb/jira-cloud/issues/9) · 2025-04-02 · closed · 1 comment

The remaining reports are on [the project's issue tracker](https://github.com/aaronsb/jira-cloud/issues).