getJiraIssue ignores responseContentFormat: "adf" and always returns markdown

[cameron-bales-telus-health]

Problem

getJiraIssue returns rich-text fields (e.g. description) as a markdown string even when the call explicitly sets responseContentFormat: "adf". Per the parameter's own documentation — "Use 'adf' (Atlassian Document Format, JSON) for full programmatic fidelity" — an ADF JSON document is expected. Instead the field always comes back as markdown, with embedded images rendered as raw ![](blob:...) tokens. The adf request is silently downgraded to the markdown passthrough; there appears to be no way to obtain the true ADF tree for an issue's description through this tool.

This breaks any workflow that needs to make a surgical, structure-preserving edit: read the ADF tree, change one node, write it back. With no ADF available on read, the only option is to round-trip through markdown — which is lossy for media nodes, panels, layout, tables, and other ADF constructs — so any automated edit risks corrupting hand-authored content.

Steps to reproduce

Tool:  mcp.atlassian.com/v1/mcp  getJiraIssue
Args:  cloudId:                <your-cloud-id>
       issueIdOrKey:           <any-issue-key>
       fields:                 ["description"]
       responseContentFormat:  "adf"

Result: fields.description is a markdown string (e.g. "... a new one called **OPCC with form**."), not an ADF JSON object.

Verified on two issues:

• An issue whose description contains an embedded image — returned markdown with the image as a raw ![](blob:https://media.staging.atl-paas.net/?...) token.
• An issue with a plain text-only description (no media) — also returned markdown (**bold** inline).

Both returned in ~1–2 s with no hang, which distinguishes this from the media-heavy timeout in #145. The downgrade to markdown is unconditional — it does not depend on the presence of media nodes.

Expected vs actual

• Expected: With responseContentFormat: "adf", fields.description (and other rich-text fields) is returned as an ADF JSON document.
• Actual: The field is returned as a markdown string regardless of responseContentFormat. The "adf" value is effectively a no-op on getJiraIssue.

Root cause hypothesis

getJiraIssue appears to be wired to the markdown serialization path only, with responseContentFormat: "adf" not implemented (or falling through to markdown) for the issue-fields response. This is the read-side counterpart to the ADF↔markdown conversion gaps documented in #60 and #59 — but here the symptom is simply that the documented adf option is unavailable in practice on this tool.

Impact

• Any agent/automation that needs ADF fidelity to edit issues safely cannot get it. The only writeable path becomes markdown round-tripping, which silently drops or mangles media nodes, panels, layout, and other non-markdown ADF constructs (see Editing content via Rovo MCP causes the loss of all ADF-rich content #60).
• Tools that try to do a one-node edit and write back are forced to either (a) skip the edit entirely to avoid corruption, or (b) risk damaging hand-authored content. We chose (a), which means a class of automated edits is blocked.
• The failure is silent: the call succeeds and returns plausible-looking content, so a caller that assumed it asked for ADF has no signal that it received markdown instead.

Suggested fixes, in order of specificity

1. Honor responseContentFormat: "adf" on getJiraIssue and searchJiraIssuesUsingJql — return rich-text fields as ADF JSON when requested, matching the documented contract.
2. If full ADF resolution is expensive (cf. getJiraIssue / searchJiraIssuesUsingJql hang indefinitely on comment reads for issues with media-heavy ADF — no opt-out available #145), add an ADF passthrough mode that serializes the stored ADF with media references left as tokens (the blob: form already seen in the markdown output), rather than resolving every media node.
3. If adf is intentionally unsupported on this tool, update the parameter documentation to say so and point callers to whatever tool does return ADF, so automations can fail cleanly instead of silently receiving markdown.

Related issues

• getJiraIssue / searchJiraIssuesUsingJql hang indefinitely on comment reads for issues with media-heavy ADF — no opt-out available #145 — getJiraIssue hang on media-heavy ADF (different symptom: timeout vs. silent markdown downgrade)
• Editing content via Rovo MCP causes the loss of all ADF-rich content #60 — lossy ADF↔markdown pipeline on edits (the data loss this issue's markdown-only reads would feed into)
• updateConfluencePage times out on large markdown payloads #59 — write-side ADF/markdown conversion bottleneck
• Support storage format for Confluence pages #9 — proposes a storage/passthrough format for Confluence; an ADF passthrough on Jira reads is the analog

Environment

• MCP server: https://mcp.atlassian.com/v1/mcp (streamable HTTP)
• Client: Claude, via Remote MCP
• Target: Jira Cloud
• Reproducible on: every issue tested, with and without media nodes